Best practices · Security
Authentication Best Practices
Opens with creditsA practical guide to authentication for developers who build their own sign-in or need to review one. It covers password rules and storage, the login flow and brute force protection, multi-factor authentication, passkeys, session handling, and account recovery, following NIST SP 800-63B-4 and the OWASP cheat sheets.
Written by Tauseef Fayyaz6 chapters, 25 practicesAbout 22 min23 quiz questionsReviewed 13 October 2026What you will learn
6 chapters · about 22 min
1Password rules and storageWhat passwords to accept, what to reject, and how to store them so a database leak does not hand out working credentials.4 practices · 4 min
2The login flow and brute force protectionHow the sign-in endpoint should respond, how to slow down guessing without locking real users out, and what to record.4 practices · 4 min
- Multi-factor authenticationWhich second factors to offer, how to stop attackers getting around them, and how recovery and factor changes should work.5 practices · 4 minOpens with credits
- Passkeys and WebAuthnPasskeys replace passwords with a key pair bound to your site. The browser does the hard cryptography, but your server still has checks to get right.3 practices · 3 minOpens with credits
- Sessions and cookiesAfter sign-in, the session token is the credential. These practices keep it unguessable, out of reach of scripts, and short-lived.5 practices · 4 minOpens with credits
- Account recovery and sensitive actionsPassword reset and account changes are second ways into every account. They need the same care as the login itself.4 practices · 3 minOpens with credits
About this guide
Authentication is how your app decides that a request really comes from the person who owns an account. It is also where most account takeovers start: a reused password that nobody blocked, a login form that tells an attacker which emails are registered, a reset link that never expires, or a session cookie that a script can read. Good authentication best practices close each of those doors without making sign-in painful for real users.
The guidance changed a lot in recent years. NIST SP 800-63B-4, finalized in 2025, drops forced complexity rules and periodic password changes, asks for longer passwords instead, requires services at its middle assurance level to offer a phishing-resistant option, and covers synced passkeys. OWASP's cheat sheets and the Application Security Verification Standard (ASVS 5.0) translate that into concrete settings: Argon2id parameters, cookie attributes, session timeouts and reset token rules.
This guide follows those sources chapter by chapter. It starts with passwords (what to accept and how to store them), moves through the login flow and brute force protection, multi-factor authentication and passkeys, then sessions and account recovery. Each practice says what to do, what to avoid, and how to check your own app. If you use a hosted identity provider, the same chapters work as a review list for how you configured it.
Common questions
What is the minimum password length recommended by NIST?
NIST SP 800-63B-4 requires at least 15 characters when a password is the only authentication factor, and at least 8 when it is used as part of multi-factor authentication. Verifiers should accept at least 64 characters and must not impose composition rules such as mixed character types.
Should I force users to change their passwords regularly?
No. NIST says verifiers must not require periodic password changes, but must force a change when there is evidence a password has been compromised. Checking new passwords against a breached password list does more good than rotation.
What is the best way to hash passwords?
OWASP recommends Argon2id with at least 19 MiB of memory, 2 iterations and a parallelism of 1. Use scrypt if Argon2id is not available, bcrypt only for legacy systems, and PBKDF2 with 600,000 iterations of HMAC-SHA256 when FIPS-140 compliance is required.
Is SMS two-factor authentication safe?
It is better than no second factor, but NIST treats SMS and voice codes as a restricted authenticator, and OWASP lists SIM swapping and phishing among its weaknesses. Offer passkeys, security keys or an authenticator app first, and keep SMS as a fallback with rate limits.
Where should I store session tokens in a web app?
In a cookie with Secure, HttpOnly and SameSite set, ideally with the __Host- prefix. OWASP advises against localStorage and sessionStorage, because any script running on the page can read them.
Are passkeys more secure than passwords?
Yes, mainly because they are phishing resistant: the key pair is bound to your site, so a look-alike domain cannot use it, and there is no shared secret on your server to leak. Your server still has to verify the challenge, origin, RP ID and user verification flag on every ceremony.
Sources (8)
Checked against these, last on 13 October 2026.
- NIST SP 800-63B-4: Authentication and Authenticator Management, NISTpages.nist.gov/800-63-4/sp800-63b.html
- OWASP Application Security Verification Standard, OWASPgithub.com/OWASP/ASVS
- Authentication Cheat Sheet, OWASPcheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
- Password Storage Cheat Sheet, OWASPcheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
- Multifactor Authentication Cheat Sheet, OWASPcheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html
- Passkey Security Cheat Sheet, OWASPcheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html
- Session Management Cheat Sheet, OWASPcheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
- Forgot Password Cheat Sheet, OWASPcheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html
Related on Sefism
Picked from the other libraries by shared topics.
Roadmaps
See allCheat sheets
See allBest practices
See all- Authorization Best PracticesGet access control right: deny by default, object-level checks against IDOR, RBAC vs ABAC vs ReBAC, tenant isolation with row-level security, audits and tests.
- Secure Coding Best PracticesWrite code that resists attack: untrusted input, validation, parameterized queries, output encoding, safe parsing, uploads, SSRF and errors that fail closed.
- Browser Security Best PracticesSecure the front end and HTTP layer: XSS and Trusted Types, Content Security Policy, CORS, cookies, CSRF, framing, security headers, third-party scripts and postMessage.
Checklists
See all- Web Application Security ChecklistA practical web application security checklist built on the OWASP Top 10:2025 and ASVS 5.0, with a severity and a way to verify every check.
- API Security ChecklistCheck your REST or GraphQL API against the OWASP API Security Top 10: authentication, object authorization, rate limits, input validation, SSRF, CORS and logging.
- Linux Server Hardening ChecklistHarden an Ubuntu, Debian or RHEL server step by step: accounts and sudo, SSH, updates, firewall and open ports, permissions, logging and CIS benchmark scans.
Project structures
See all- Firebase (Cloud Functions and security rules) project structureFor students building an app on Firebase who need a real backend: Cloud Functions (2nd gen) in TypeScript, Firestore and Storage security rules with tests, and the Local Emulator Suite. The tree starts from
firebase initand grows into feature folders of callables, triggers and scheduled jobs, then adds CI deploys, environments, contract tests and runbooks. - AI agent with an MCP server project structureFor developers who want to give AI assistants safe access to their own data or API. A TypeScript MCP server built on the official SDK, organised by feature (tasks, projects) with each feature owning its tools, resources and prompts, served over stdio for local hosts and Streamable HTTP with OAuth for remote ones, plus a small agent and the evals that prove a model can use it.
- Terraform project structureAn infrastructure repository for a small app on AWS: reusable modules, one folder per environment with its own remote state, pinned providers, tests and security scans, with plan on every pull request and apply from CI. For students who have finished the Terraform tutorials and want to know how a real team lays out the files. The same layout works unchanged with OpenTofu.
Career questions
See all- How do I get into AI security as a student or junior engineer?Build a normal security or software foundation first, then learn how LLM apps fail using the OWASP Top 10 for LLM Applications and MITRE ATLAS, and prove it by building, testing and hardening a small LLM app of your own. Most people reach AI security through AppSec, security engineering or ML engineering, not straight from university.
- Where do I start if I want a career in cybersecurity or IT operations?Start with the foundations both fields share: networking, Linux, and how systems fail. Then choose an entry role such as SOC analyst, IT support or junior cloud operations, and prove it with hands-on labs and one documented project rather than a stack of certificates.
- Can I use AI coding tools at my internship, and what should I never paste into them?Usually yes, but only the tools your company has approved, on the code and data they allow, and in the way they allow. Ask in your first week. Never paste secrets, customer data or code you are not permitted to share, and review everything the tool writes as if your name is on it, because it is.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com