Password & Secret Generator
Generate secure passwords, API keys, and tokens with customizable options.
Options
Generated Password
What Makes a Password Secure?
A secure password is one that is difficult for attackers to guess or crack through brute-force attacks. The security of a password depends on several factors:
- Length: Longer passwords are exponentially harder to crack
- Complexity: Using diverse character sets increases possible combinations
- Randomness: Truly random passwords are unpredictable
- Uniqueness: Each account should have a unique password
- Entropy: The measure of password unpredictability
Why Password Security Matters
- Account protection: Prevents unauthorized access to your accounts
- Data security: Protects sensitive information from breaches
- Identity theft prevention: Reduces risk of identity theft
- Compliance: Many regulations require strong password policies
- Cloud security: Essential for securing cloud infrastructure and APIs
Understanding Password Entropy
Entropy measures the unpredictability or randomness of a password. It's measured in bits and represents how many guesses an attacker would need, on average, to crack the password.
Entropy Formula
Entropy (bits) = log₂(character_set_size) × password_length
Character Set Sizes
| Character Set | Size | Characters |
|---|---|---|
| Lowercase | 26 | a-z |
| Uppercase | 26 | A-Z |
| Numbers | 10 | 0-9 |
| Symbols | ~30 | Special characters (!@#$%^&* etc.) |
| Alphanumeric | 62 | A-Z, a-z, 0-9 |
| Full set | ~92 | All of the above |
Entropy Examples
8-character password:
- Lowercase only:
log₂(26) × 8 = 37.6 bits - Alphanumeric:
log₂(62) × 8 = 47.6 bits - Full set:
log₂(92) × 8 = 52.4 bits
16-character password:
- Lowercase only:
log₂(26) × 16 = 75.2 bits - Alphanumeric:
log₂(62) × 16 = 95.2 bits - Full set:
log₂(92) × 16 = 104.8 bits
Password Strength Levels
| Entropy | Strength | Time to Crack* | Description |
|---|---|---|---|
| < 40 bits | Weak | Seconds to minutes | Easily cracked |
| 40-64 bits | Medium | Hours to days | Moderate security |
| 64-128 bits | Strong | Years to decades | Good security |
| > 128 bits | Very Strong | Centuries+ | Excellent security |
*Assuming 1 billion guesses per second (modern GPU)
Password vs API Key vs Token
Passwords
Purpose: User authentication Characteristics:
- Human-readable (sometimes)
- Can include symbols
- Often memorized by users
- Used for login credentials
Example: MyP@ssw0rd!2024
Best Practices:
- Minimum 12-16 characters
- Mix of uppercase, lowercase, numbers, symbols
- Unique for each account
- Use password manager
API Keys
Purpose: Application-to-application authentication Characteristics:
- Alphanumeric only (no symbols)
- Longer (typically 32-64 characters)
- Not human-memorable
- Stored in configuration files or environment variables
Example: aB3dE5fG7hI9jK1lM3nO5pQ7rS9tU1vW3xY5zA7bC9dE1fG3hI5jK7lM9nO1pQ3
Best Practices:
- Minimum 32 characters
- Alphanumeric (A-Z, a-z, 0-9)
- Rotate regularly
- Store securely (never commit to git)
- Use environment variables or secrets management
Tokens (Hexadecimal)
Purpose: Session tokens, CSRF tokens, one-time codes Characteristics:
- Hexadecimal (0-9, a-f)
- Compact representation
- Often shorter (16-32 characters)
- Used for temporary authentication
Example: a1b2c3d4e5f678901234567890abcdef
Best Practices:
- Minimum 32 characters (16 bytes = 32 hex chars)
- Cryptographically random
- Short expiration time
- Single-use when possible
Password Generation Methods
Cryptographically Secure Random Number Generation
Critical: Always use cryptographically secure random number generators (CSPRNG) for password generation.
JavaScript (Web Crypto API):
// Secure random generation
const array = new Uint32Array(length);
crypto.getRandomValues(array);Python:
import secrets
# Generate secure random password
password = ''.join(secrets.choice(charset) for _ in range(length))Node.js:
const crypto = require('crypto');
// Generate secure random bytes
const randomBytes = crypto.randomBytes(length);Never use:
Math.random()- Not cryptographically secure- Predictable patterns
- Sequential numbers
- Dictionary words
Character Set Selection
Including diverse character sets increases entropy:
const charset = {
uppercase: 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', // 26 chars
lowercase: 'abcdefghijklmnopqrstuvwxyz', // 26 chars
numbers: '0123456789', // 10 chars
symbols: '!@#$%^&*()_+-=[]{}|;:,.<>?' // ~30 chars
};
// Full set: 26 + 26 + 10 + 30 = 92 characters
// Entropy per character: log₂(92) ≈ 6.52 bitsExcluding Ambiguous Characters
Some characters can be confused:
0(zero) vsO(letter O)1(one) vsl(lowercase L) vsI(uppercase i)
When to exclude:
- User-typed passwords (reduces errors)
- Printed passwords (easier to read)
- Voice communication (less confusion)
When to include:
- Machine-generated passwords (no human interaction)
- API keys (stored, not typed)
- Higher entropy needed
Password Length Recommendations
Minimum Lengths by Use Case
| Use Case | Minimum Length | Recommended Length |
|---|---|---|
| User passwords | 12 characters | 16-20 characters |
| API keys | 32 characters | 32-64 characters |
| Session tokens | 32 characters (hex) | 32-64 characters |
| Database passwords | 16 characters | 20-32 characters |
| SSH keys | N/A (key-based) | 2048+ bits RSA |
| Encryption keys | 256 bits | 256-512 bits |
Length vs Complexity Trade-off
Longer passwords are better than complex short passwords:
P@ssw0rd!(10 chars, complex) = ~65 bits entropycorrect horse battery staple(28 chars, simple) = ~44 bits entropycorrect horse battery staple!(29 chars, simple + symbol) = ~48 bits entropy
However, for machine-generated passwords, complexity + length is best:
Kx9#mP2$vL8@nQ4!(16 chars, complex) = ~105 bits entropy
Common Use Cases
1. User Account Passwords
Requirements:
- Minimum 12-16 characters
- Mix of character types
- Unique per account
- Stored hashed (never plaintext)
Example:
Length: 16
Character sets: Uppercase, Lowercase, Numbers, Symbols
Result: Kx9#mP2$vL8@nQ4!
Entropy: ~105 bits (Very Strong)
2. API Keys for Cloud Services
AWS Access Keys:
Format: AKIAIOSFODNN7EXAMPLE (20 chars)
Type: Alphanumeric, uppercase
GitHub Personal Access Token:
Format: ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (40+ chars)
Type: Alphanumeric
Best Practices:
- Store in environment variables
- Use secrets management (AWS Secrets Manager, HashiCorp Vault)
- Rotate regularly (every 90 days)
- Never commit to version control
3. Database Passwords
PostgreSQL/MySQL:
Length: 20-32 characters
Character sets: Alphanumeric + symbols
Example: DbP@ssw0rd!2024#Secure$Key
MongoDB Connection String:
mongodb://username:password@host:port/database
4. Kubernetes Secrets
Creating secrets:
# Generate password
PASSWORD=$(openssl rand -base64 32)
# Create Kubernetes secret
kubectl create secret generic db-password \
--from-literal=password=$PASSWORDYAML format:
apiVersion: v1
kind: Secret
metadata:
name: db-password
type: Opaque
data:
password: <base64-encoded-password>5. Docker Secrets
Docker Compose:
services:
app:
secrets:
- db_password
secrets:
db_password:
external: trueCreate secret:
echo "MySecurePassword123!" | docker secret create db_password -6. Environment Variables
.env file (never commit!):
DATABASE_PASSWORD=Kx9#mP2$vL8@nQ4!
API_KEY=aB3dE5fG7hI9jK1lM3nO5pQ7rS9tU1vW3xY5zA7bC9dE1fG3hI5jK7lM9nO1pQ3
JWT_SECRET=your-secret-key-hereAccess in code:
const dbPassword = process.env.DATABASE_PASSWORD;
const apiKey = process.env.API_KEY;7. CI/CD Pipeline Secrets
GitHub Actions:
env:
DATABASE_PASSWORD: ${{ secrets.DATABASE_PASSWORD }}
API_KEY: ${{ secrets.API_KEY }}GitLab CI:
variables:
DATABASE_PASSWORD: $DATABASE_PASSWORDPassword Storage Best Practices
Never Store Plaintext Passwords
Wrong:
// NEVER DO THIS
const users = {
'admin': 'MyPassword123!'
};Correct:
// Hash passwords using bcrypt, Argon2, or similar
const bcrypt = require('bcrypt');
const hashedPassword = await bcrypt.hash('MyPassword123!', 10);Hashing Algorithms
Recommended:
- Argon2: Winner of Password Hashing Competition (2015)
- bcrypt: Widely used, battle-tested
- scrypt: Memory-hard function
- PBKDF2: NIST recommended (with sufficient iterations)
Never use:
- MD5
- SHA-1
- SHA-256 (for passwords - too fast)
- Plaintext
Example: Hashing Passwords
Node.js (bcrypt):
const bcrypt = require('bcrypt');
// Hash password
const saltRounds = 10;
const hashedPassword = await bcrypt.hash('MyPassword123!', saltRounds);
// Verify password
const isValid = await bcrypt.compare('MyPassword123!', hashedPassword);Python (bcrypt):
import bcrypt
# Hash password
password = b'MyPassword123!'
hashed = bcrypt.hashpw(password, bcrypt.gensalt())
# Verify password
is_valid = bcrypt.checkpw(password, hashed)Common Mistakes to Avoid
1. Using Weak Passwords
Weak passwords:
password12345678qwertyadminPassword123
Why they're weak:
- Common dictionary words
- Sequential patterns
- Low entropy
- Easily guessed
2. Reusing Passwords
Problem: If one account is compromised, all accounts are at risk.
Solution: Use unique passwords for each account. Use a password manager.
3. Storing Passwords in Code
Wrong:
// NEVER commit passwords to git
const API_KEY = 'sk_live_1234567890abcdef';Correct:
// Use environment variables
const API_KEY = process.env.API_KEY;4. Using Predictable Patterns
Wrong:
// Predictable pattern
'Password' + year // Password2024
'Company' + '123' // Company123Correct:
// Use cryptographically secure random generation
crypto.getRandomValues(array);5. Insufficient Length
Wrong:
- 8-character passwords (minimum in many systems, but weak)
- Short API keys (< 32 characters)
Correct:
- 16+ character passwords
- 32+ character API keys
6. Not Rotating Credentials
Problem: Long-lived credentials increase risk if compromised.
Solution: Rotate passwords and API keys regularly:
- User passwords: Every 90 days (or use MFA)
- API keys: Every 90-180 days
- Database passwords: Every 90 days
- Service accounts: Every 180 days
7. Sharing Credentials
Wrong:
- Sharing passwords via email, Slack, etc.
- Using shared accounts
- Hardcoding in documentation
Correct:
- Use password managers for sharing
- Individual accounts for each user
- Secrets management systems
Password Policies
Recommended Policy
Minimum Requirements:
- Length: 12-16 characters
- Character sets: At least 3 of 4 (uppercase, lowercase, numbers, symbols)
- No dictionary words
- No personal information
- No common patterns
Additional Security:
- Multi-factor authentication (MFA)
- Password expiration (90 days)
- Account lockout after failed attempts
- Password history (prevent reuse)
NIST Guidelines (2020)
Modern recommendations:
- No complexity requirements (length is more important)
- No password expiration (unless compromised)
- Allow paste (password managers)
- Screen against common passwords
- Enforce MFA
Rationale: Long, unique passwords are better than complex, frequently changed passwords.
Real-World Examples
Example 1: Generating Database Password
# Generate secure password
openssl rand -base64 32
# Output: Kx9#mP2$vL8@nQ4!aB3dE5fG7hI9jK1lM3nO5pQ7rS9tU1vW3xY5zA7bC9dE1fG3hI5jK7lM9nO1pQ3
# Store in Kubernetes secret
kubectl create secret generic postgres-password \
--from-literal=password=$(openssl rand -base64 32)Example 2: API Key for Cloud Service
// Generate API key
function generateApiKey(length = 32) {
const charset = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';
const array = new Uint32Array(length);
crypto.getRandomValues(array);
return Array.from(array, x => charset[x % charset.length]).join('');
}
const apiKey = generateApiKey(32);
// Store in AWS Secrets Manager or environment variableExample 3: Session Token
// Generate session token (hex)
function generateSessionToken(length = 32) {
const array = new Uint8Array(length);
crypto.getRandomValues(array);
return Array.from(array, byte => byte.toString(16).padStart(2, '0')).join('');
}
const sessionToken = generateSessionToken();
// Store in database with expiration timeExample 4: Docker Secret
# Generate password
PASSWORD=$(openssl rand -base64 24)
# Create Docker secret
echo $PASSWORD | docker secret create db_password -
# Use in docker-compose.yml
services:
app:
secrets:
- db_passwordPassword Managers
Why Use a Password Manager?
- Generate strong passwords: Creates random, unique passwords
- Store securely: Encrypted storage
- Auto-fill: Convenient login
- Sync across devices: Access from anywhere
- Share securely: Share credentials with team
Popular Password Managers
- 1Password: Business and personal use
- LastPass: Free and paid tiers
- Bitwarden: Open source, self-hostable
- Dashlane: User-friendly interface
- KeePass: Open source, local storage
For Teams
- 1Password Business: Team password sharing
- Bitwarden Organizations: Self-hosted option
- HashiCorp Vault: Enterprise secrets management
- AWS Secrets Manager: Cloud-native solution
Frequently Asked Questions
How long should my password be?
Minimum: 12 characters for user passwords, 32 characters for API keys.
Recommended: 16-20 characters for passwords, 32-64 characters for API keys.
Should I use symbols in passwords?
For user passwords: Yes, if the system allows. Symbols increase entropy.
For API keys: Usually no. API keys are typically alphanumeric only.
How often should I change my password?
Modern guidance (NIST): Only change if compromised. However, many organizations still require periodic changes (every 90 days).
Best practice: Use long, unique passwords and enable MFA instead of frequent changes.
What's the difference between a password and an API key?
- Password: User authentication, can include symbols, often memorized
- API key: Application authentication, usually alphanumeric, stored in config
Can I use the same password for multiple accounts?
No. If one account is compromised, all accounts become vulnerable. Use unique passwords for each account.
How do I store passwords securely?
- Never store plaintext
- Use hashing (bcrypt, Argon2)
- Add salt (handled by modern hashing libraries)
- Use environment variables or secrets management
- Never commit to version control
What is password entropy?
Entropy measures password unpredictability in bits. Higher entropy = stronger password. Calculated as: log₂(character_set_size) × length.
Should I exclude ambiguous characters?
For user-typed passwords: Yes, reduces errors (0 vs O, 1 vs l).
For machine-generated: Usually no, unless readability is important.
How do I generate passwords programmatically?
Use cryptographically secure random number generators:
- JavaScript:
crypto.getRandomValues() - Python:
secretsmodule - Node.js:
crypto.randomBytes()
Never use: Math.random() or other non-cryptographic generators.
What makes a password "strong"?
- Length: 16+ characters
- Complexity: Multiple character sets
- Randomness: Cryptographically random
- Uniqueness: Not reused
- High entropy: 64+ bits
Additional Resources
- NIST Password Guidelines (2020)
- OWASP Password Storage Cheat Sheet
- OWASP Authentication Cheat Sheet
- Have I Been Pwned - Check if your password has been compromised
- Web Crypto API
- Python secrets module
- HashiCorp Vault
- AWS Secrets Manager