Back to Tools

Password & Secret Generator

Generate secure passwords, API keys, and tokens with customizable options.

Options

8128

Generated Password

Strength:
Medium
Entropy: 0.00 bits

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:

  1. Length: Longer passwords are exponentially harder to crack
  2. Complexity: Using diverse character sets increases possible combinations
  3. Randomness: Truly random passwords are unpredictable
  4. Uniqueness: Each account should have a unique password
  5. 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 SetSizeCharacters
Lowercase26a-z
Uppercase26A-Z
Numbers100-9
Symbols~30Special characters (!@#$%^&* etc.)
Alphanumeric62A-Z, a-z, 0-9
Full set~92All 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

EntropyStrengthTime to Crack*Description
< 40 bitsWeakSeconds to minutesEasily cracked
40-64 bitsMediumHours to daysModerate security
64-128 bitsStrongYears to decadesGood security
> 128 bitsVery StrongCenturies+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 bits

Excluding Ambiguous Characters

Some characters can be confused:

  • 0 (zero) vs O (letter O)
  • 1 (one) vs l (lowercase L) vs I (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 CaseMinimum LengthRecommended Length
User passwords12 characters16-20 characters
API keys32 characters32-64 characters
Session tokens32 characters (hex)32-64 characters
Database passwords16 characters20-32 characters
SSH keysN/A (key-based)2048+ bits RSA
Encryption keys256 bits256-512 bits

Length vs Complexity Trade-off

Longer passwords are better than complex short passwords:

  • P@ssw0rd! (10 chars, complex) = ~65 bits entropy
  • correct horse battery staple (28 chars, simple) = ~44 bits entropy
  • correct 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=$PASSWORD

YAML 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: true

Create 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-here

Access 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_PASSWORD

Password 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:

  • password
  • 12345678
  • qwerty
  • admin
  • Password123

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'  // Company123

Correct:

// 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 variable

Example 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 time

Example 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_password

Password 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?

  1. Never store plaintext
  2. Use hashing (bcrypt, Argon2)
  3. Add salt (handled by modern hashing libraries)
  4. Use environment variables or secrets management
  5. 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: secrets module
  • 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