authentication
7 articles with this tag
Password reset design flaws: 5 ways accounts get taken over despite strong login, and how to fix them
A reset flow is a mechanism for letting someone who does not know the password set a new one — which makes it an authentication path in its own right. Harden the login all you like: if reset is weak, reset is your real authentication strength. Five failure shapes: guessable tokens, tokens that never expire, links that live on in a mailbox, links whose destination can be set from outside (Host header), and responses that reveal whether an account exists. The key implementation step is separating what the guidance requires from the numbers it leaves to you.
Rate limiting and abuse control: designing limits that stop brute force and runaway costs
Rate limiting usually fails not because the limit was too loose but because the wrong question was asked. Three questions: who you count (IP can be forged and is shared by real users, so identity comes first), what you count (requests alone miss expensive single operations — cost, size, record counts), and what happens at the ceiling (blunt lockout is a denial of service against legitimate users). NIST caps consecutive failures at 100 and asks for delays and CAPTCHA instead of shutting people out; OWASP includes third-party spending limits, the final control against financial damage.
Authentication vs authorization: a login alone doesn't protect other users' data
Authentication = verifying who someone is; authorization = deciding what they may do. They're different, and adding a login is not authorization. Without owner (user_id) scoping on data, 'logged in = sees all data' — the top-ranked OWASP Broken Access Control. Add a scaffold with registration left open and a stranger can sign up and get in. Defenses: scope every query to the owner, close unneeded registration, defense-in-depth, audit/access logs before an incident, detect new sign-ups.
What is a passkey? Public-key login, phishing resistance and sync
A passkey authenticates with a private-key signature, while the login service holds the public key. Synced passkeys can transfer encrypted credentials between devices; device-bound passkeys do not sync. MFA depends on required user verification, and device, sync-account and recovery protections still matter.
What is password hashing? Storing passwords safely with a one-way transform
Password hashing means storing a password as a one-way, non-reversible transform. Never store plaintext. Unlike encryption you can't decrypt it back — that's the point. But plain MD5/SHA-256 falls to rainbow tables and brute force. The fix: a per-user salt plus a deliberately slow hash (bcrypt/Argon2/scrypt). Don't roll your own — use the standard function.
How to store passwords safely: the right way to hash and salt
A practical guide to storing passwords safely on the server. Understand why plaintext, encryption, and raw hashes all fail, then converge on one answer: a per-user salt plus a deliberately slow hash (Argon2id recommended, bcrypt/scrypt as alternatives). Don't roll your own — use the standard function, raise the cost over time, and migrate weak hashes by re-hashing on login.
What is a JWT (JSON Web Token)? How signed tokens work and how to use them safely
A JWT is a token a server signs and issues so that tampering can be detected. It has three parts — header.payload.signature — and the server verifies the signature to confirm authenticity. Watch out for: (1) always verify the signature and pin the expected alg (reject alg:none); (2) anyone can read the contents, so put no secrets in it; (3) keep expiry short and have a revocation strategy. Decoding (reading) and verifying (checking authenticity) are different things.