Secure Config: Generate Passwords → Hash → Encode Base64
Build a secure configuration workflow: generate strong passwords, hash them for storage, then Base64-encode secrets for environment variables. Never store plaintext credentials again.
The Problem
You need to rotate credentials for a service: generate a new strong password, hash it for the database, and encode the raw value as Base64 for the environment variable. Doing this manually risks weak passwords, insecure storage, or misconfigured env vars.
Why This Matters
Credential management mistakes are the leading cause of data breaches. A systematic workflow — generate cryptographically strong values, hash for storage, encode for transport — implements security best practices without memorizing format requirements.
Step-by-Step Instructions
Generate a cryptographically strong password
Use the Password Generator to create a 32+ character password with uppercase, lowercase, numbers, and symbols. For API keys, generate 64 characters alphanumeric only. Enable all character types for maximum entropy.
Hash the password for database storage
Paste the generated password into the Hash Generator and compute SHA-256 for audit logs or API key verification. Note: For user passwords, use bcrypt/Argon2 in your application — SHA-256 alone is not sufficient for password hashing.
Base64-encode for environment variables
Paste the raw secret into the Base64 Encoder. The encoded value is safe to store in .env files, Kubernetes secrets, or CI/CD variables without special character escaping issues.
Try It Now — Password Generator
Open full page →All processing happens in your browser — no data is sent to any server.
Before & After Example
# .env file — DANGEROUS DB_PASSWORD=mypassword123 API_KEY=abc123 JWT_SECRET=secret # These are: # - Too short/weak # - Plaintext # - Guessable
# .env file — SECURE DB_PASSWORD=kX8mP2vQ9nR4sT7wY1zA3bC6dE0fG5hJ API_KEY=dGhpcyBpcyBhIHNhbXBsZSBrZXkgZm9yIGRlbW8gcHVycG9zZXMgb25seQ== JWT_SECRET=7d4b8f2e1a9c3e6f0b5d2a8c4e7f1b3d # Generated: 32+ chars, Base64-safe, SHA-256 hashable
Frequently Asked Questions
Why not just use SHA-256 for password hashing?
SHA-256 is too fast — modern GPUs can compute billions per second, making brute-force attacks feasible. Use bcrypt, scrypt, or Argon2 which are intentionally slow. Use SHA-256 for API keys and file integrity checks, not for passwords.
Should I commit .env files to git?
Never. Add .env to .gitignore immediately. Use .env.example with placeholder values for documentation. Store actual secrets in a secrets manager (Vault, AWS Secrets Manager, Doppler) or your CI/CD platform's secure variables.
How long should an API key be?
Minimum 32 characters (256 bits) for good security. 64 characters is better. Use a cryptographically secure random source — not Math.random(). The Password Generator uses crypto.getRandomValues() which is cryptographically secure.
Related Workflows
Try all 3 tools in this workflow
Each tool is free, runs in your browser, and requires no signup.