Do Websites Store My Passwords? What Really Happens on the Backend

Introduction

Ever wondered what happens to your password after you click "Sign Up"? Understanding how websites store (or should store) passwords is crucial for evaluating their security. This plain-English guide explains what really happens on the backend.

The Short Answer

Properly secured websites:

• Never see your actual password
• Store a cryptographic hash
• Use salt and slow hashing algorithms
• Cannot recover your original password

Poorly secured websites:

• Store passwords in plain text (dangerous)
• Use weak hashing (MD5, SHA-1)
• No salt (vulnerable to rainbow tables)
• Can see and recover your password

How Password Storage Should Work

Step 1: You Enter Password

You type: K9#mL2$pQ7@nR4!v
Browser sends: K9#mL2$pQ7@nR4!v (over HTTPS)

HTTPS encryption: Protects password in transit

Step 2: Server Receives Password

Server receives: K9#mL2$pQ7@nR4!v
Server processes: Hash + Salt
Server stores: $2b$12$KIXxLVq8ZG0qN7mH.Qx9ue...

Never stored in plain text

Step 3: Password is Hashed

Hashing process:

Password: K9#mL2$pQ7@nR4!v
+ Salt: random_string_xyz123
= Hash: $2b$12$KIXxLVq8ZG0qN7mH.Qx9ue...

Stored in database: Only the hash

Step 4: Login Verification

You enter: K9#mL2$pQ7@nR4!v
Server hashes: K9#mL2$pQ7@nR4!v + salt
Compares: New hash vs Stored hash
Match? → Login successful

Server never sees original password again

Hashing Algorithms

Good Algorithms (Use These)

bcrypt (Recommended):

$2b$12$KIXxLVq8ZG0qN7mH.Qx9ue...

• Slow by design
• Adjustable cost factor
• Built-in salt
• Industry standard

scrypt:

• Memory-hard
• Resistant to hardware attacks
• Good for high-security applications

Argon2:

• Winner of Password Hashing Competition
• Memory-hard
• Resistant to GPU attacks
• Best for new applications

Bad Algorithms (Don't Use)

MD5 (Broken):

5f4dcc3b5aa765d61d8327deb882cf99

• Fast (bad for passwords)
• No salt
• Rainbow table attacks
• Cracked in seconds

SHA-1 (Weak):

5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8

• Fast (bad for passwords)
• Collision attacks
• Not designed for passwords

SHA-256 (Not Ideal):

e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

• Too fast for passwords
• Vulnerable to GPU attacks
• Better than MD5/SHA-1, but not ideal

Plain Text (Never Use)

user@email.com | K9#mL2$pQ7@nR4!v

• Instant compromise if breached
• Employees can see passwords
• Regulatory violations
• Unacceptable

Salt: Why It Matters

Without Salt (Vulnerable)

Database:

user1@email.com | 5f4dcc3b5aa765d61d8327deb882cf99
user2@email.com | 5f4dcc3b5aa765d61d8327deb882cf99

Problem: Same password = same hash

Attack: Rainbow table lookup

5f4dcc3b5aa765d61d8327deb882cf99 = "password"

Result: Both accounts compromised instantly

With Salt (Secure)

Database:

user1@email.com | $2b$12$KIXxLVq8ZG0qN7mH.Qx9ue...
user2@email.com | $2b$12$LMNoPQRsTUvWxYz123456...

Even if same password: Different hashes

Attack: Must crack each hash individually

Result: Extremely time-consuming

Real-World Examples

Good: Modern Website

What they store:

CREATE TABLE users (
  email VARCHAR(255),
  password_hash VARCHAR(255),
  salt VARCHAR(255),
  created_at TIMESTAMP
);

INSERT INTO users VALUES (
  'user@email.com',
  '$2b$12$KIXxLVq8ZG0qN7mH.Qx9ue...',
  'random_salt_xyz123',
  '2024-01-01'
);

If breached: Passwords are safe (properly hashed)

Bad: Legacy Website

What they store:

CREATE TABLE users (
  email VARCHAR(255),
  password VARCHAR(255),
  created_at TIMESTAMP
);

INSERT INTO users VALUES (
  'user@email.com',
  'K9#mL2$pQ7@nR4!v',
  '2024-01-01'
);

If breached: All passwords exposed immediately

Ugly: Weak Hashing

What they store:

INSERT INTO users VALUES (
  'user@email.com',
  '5f4dcc3b5aa765d61d8327deb882cf99',
  '2024-01-01'
);

If breached: Passwords cracked in seconds/minutes

How to Tell If a Site Is Secure

Red Flags (Insecure)

❌ Password reset sends your actual password

"Your password is: K9#mL2$pQ7@nR4!v"

This means they store it in plain text!

❌ Customer service can tell you your password

❌ Password length limit < 16 characters

❌ No HTTPS (http:// instead of https://)

❌ Asks for password via email

Green Flags (Secure)

✅ Password reset sends a link, not password

"Click here to reset your password"

✅ Customer service cannot see your password

✅ Allows long passwords (64+ characters)

✅ Uses HTTPS everywhere

✅ Never asks for password via email

✅ Offers 2FA

Password Recovery vs Reset

Password Recovery (Bad)

Process:

1. Click "Forgot Password"
2. Receive email: "Your password is: xyz"

Means: Password stored in plain text or reversibly encrypted

Risk: Extremely insecure

Password Reset (Good)

Process:

1. Click "Forgot Password"
2. Receive email with temporary link
3. Create new password
4. Old password is replaced

Means: Password properly hashed

Security: Much better

What Happens in a Breach

Properly Secured Site

Attacker gets:

user@email.com | $2b$12$KIXxLVq8ZG0qN7mH.Qx9ue...

Attacker must:

• Crack each hash individually
• Use expensive hardware
• Spend days/weeks/years per password

Strong passwords: Effectively uncrackable

Weak passwords: May be cracked

Poorly Secured Site

Attacker gets:

user@email.com | password123

Attacker has:

• Instant access to all passwords
• Can try on other sites (credential stuffing)
• Complete compromise

All passwords: Exposed immediately

Database Encryption

Encryption at Rest

What it protects:

• Database files on disk
• Backups
• Physical theft

What it doesn't protect:

• Application-level access
• SQL injection
• Compromised credentials

Still need: Proper password hashing

Application-Level Encryption

Some sites add extra layer:

Password → Hash → Encrypt → Store

Benefits:

• Defense in depth
• Protects against some attacks

Still need: Strong hashing first

Password Transmission

HTTPS (Secure)

What happens:

Browser: K9#mL2$pQ7@nR4!v
  ↓ (encrypted)
Server: K9#mL2$pQ7@nR4!v

Protection: Encrypted in transit

Attackers see: Gibberish

HTTP (Insecure)

What happens:

Browser: K9#mL2$pQ7@nR4!v
  ↓ (plain text)
Server: K9#mL2$pQ7@nR4!v

Protection: None

Attackers see: Your actual password

Never use: HTTP sites for passwords

Best Practices for Websites

Minimum Requirements

Must have:

• bcrypt, scrypt, or Argon2
• Unique salt per password
• HTTPS everywhere
• No password length limits (up to 64+)
• Rate limiting on login attempts

Recommended

Should have:

• 2FA support
• Breach monitoring integration
• Security headers
• Password strength meter
• Breach notification plan

Advanced

Nice to have:

• Hardware security key support
• Passwordless authentication
• Risk-based authentication
• Behavioral analysis

What Users Should Do

1. Use Unique Passwords

Even if site is secure:

• Breaches happen
• Hashes can be cracked
• Never reuse passwords

2. Use Strong Passwords

Even with good hashing:

• Weak passwords can be cracked
• Use 16+ characters
• Use random generation

3. Enable 2FA

Even with strong password:

• Adds second layer
• Protects against credential stuffing
• Essential for critical accounts

4. Use Password Manager

Benefits:

• Unique password per site
• Strong passwords
• Encrypted storage
• Breach monitoring

Learn more: Password Managers: How to Choose

5. Monitor for Breaches

Tools:

• Have I Been Pwned
• Password manager alerts
• Site notifications

Action: Change password immediately if breached

Common Questions

"Can the website see my password?"

Properly secured: No, they only see the hash

Poorly secured: Yes, if stored in plain text

Test: If they can email you your password, they can see it

"What if I forget my password?"

Properly secured: Must reset (create new password)

Poorly secured: They can tell you (red flag!)

"Why do some sites limit password length?"

Bad reasons:

• Legacy systems
• Poor design
• Lazy developers

Good reason: None (should support 64+ characters)

"Is my password safe if the site is hacked?"

Depends on:

• Hashing algorithm used
• Your password strength
• Attacker resources

Strong password + good hashing: Very safe

Weak password + bad hashing: Compromised

"Should I change my password after a breach?"

Yes, immediately:

• Even if properly hashed
• Even if password is strong
• Change on all sites where reused

Regulatory Requirements

GDPR (Europe)

Requirements:

• Appropriate security measures
• Encryption where appropriate
• Breach notification (72 hours)
• Data protection by design

Penalties: Up to 4% of global revenue

CCPA (California)

Requirements:

• Reasonable security
• Breach notification
• Consumer rights

Penalties: Up to $7,500 per violation

PCI DSS (Payment Cards)

Requirements:

• Strong cryptography
• Secure transmission
• Access controls
• Regular testing

Penalties: Fines + loss of payment processing

Conclusion

How websites should store passwords:

✅ Hash with bcrypt/scrypt/Argon2
✅ Use unique salt per password
✅ Transmit over HTTPS only
✅ Never store plain text
✅ Support long passwords (64+)
✅ Offer 2FA

How to protect yourself:

✅ Use unique passwords per site
✅ Use strong passwords (16+ chars)
✅ Enable 2FA everywhere
✅ Use password manager
✅ Monitor for breaches
✅ Avoid sites with red flags

Red flags to watch for:

• Password sent in email
• Short password limits
• No HTTPS
• Customer service can see password

Ready to create strong passwords that stay secure even if websites are breached? Use our Strong Password Generator to generate secure passwords instantly.

Related Reading

• How Hackers Crack Weak Passwords (And How to Fight Back)
• Brute Force, Dictionary, and Credential Stuffing: A Plain-English Guide
• Secure Password Maker for Developers: CI/CD, .env, and Secrets