Bezpieczne przechowywanie haseł i odzyskiwanie danych uwierzytelniających

Storing passwords in plaintext or with weak encoding means a single database breach exposes every user. Passwords must be stored as salted hashes using a slow, purpose-built algorithm.

This lesson covers correct hashing and secure recovery flows.

Passwords should be hashed, not encrypted. Encryption is reversible; if the key leaks, all passwords are exposed. Hashing is one-way: you verify by hashing the input and comparing.

• Never use reversible encryption for passwords
• Never use fast hashes like MD5 or SHA-1 alone

A salt is a unique random value added to each password before hashing. Salts ensure two users with the same password get different hashes, defeating precomputed rainbow tables.

Modern algorithms generate and store the salt for you.

Use a deliberately slow, memory-hard algorithm: Argon2 (preferred), bcrypt, or scrypt. Their cost factor makes brute-force attacks expensive even with stolen hashes.

Here is a conceptual hashing and verification flow using a bcrypt-style API.

The cost factor (rounds) controls how slow hashing is. Set it so a single hash takes around 100-300ms on your hardware: slow enough to deter attackers, fast enough for login. Re-tune it as hardware improves.

Attackers reuse leaked credentials across sites. Defend with rate limiting, account lockout with backoff, and checks against known-breached password lists.

• Throttle failed logins per account and per IP
• Reject passwords found in breach corpuses
• Alert users of logins from new devices

Comparing secrets must take the same time regardless of how many characters match, or attackers can infer values via timing. Hashing libraries provide constant-time verify functions; use them instead of plain equality.

Reset flows are a frequent weak point. Generate a high-entropy random token, store only its hash, set a short expiry, and invalidate it after one use.

Reset and login responses should not reveal whether an email exists. Return the same message regardless, and send the reset email only if the account exists. This prevents attackers from harvesting valid accounts.

When you upgrade algorithms or cost factors, rehash a user's password on their next successful login using the new parameters. This migrates your store gradually without forcing resets.

You learned to hash with salt using Argon2 or bcrypt, tune the cost factor, defend against credential stuffing with rate limiting, compare in constant time, and build single-use expiring reset tokens that avoid account enumeration. Proper credential handling protects users even when the database is breached.