authentication
7 articles with this tag
Password reset design flaws — harden login all you like, this is the way in
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 craft is separating what the guidance requires from the numbers it leaves to you.
Rate limiting and abuse control — counting requests stops neither brute force nor a runaway bill
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 last line for financial damage.
Added a login and called it secure? — authentication vs authorization
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 an open registration scaffold and a stranger can sign up and walk 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? Passwordless login with nothing to steal
A passkey is a login with no shared secret. Your device signs with a private key plus biometrics and the server stores only the matching public key. So a leak can't be abused, and the signature is bound to the domain — it won't complete on a fake site, making it structurally phishing-resistant. Safer than password + SMS code; migrate important accounts first.
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 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.
What is a JWT (JSON Web Token)? How the signed pass works and how to use it safely
A JWT is a tamper-proof 'pass' a server issues by signing it. 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.