DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Last call! Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Understanding IEEE 802.11(Wi-Fi) Encryption and Authentication: Write Your Own Custom Packet Sniffer
  • Power BI Embedded Analytics — Part 2: Power BI Embedded Overview
  • Simplify Authorization in Ruby on Rails With the Power of Pundit Gem
  • Understanding the Identity Bridge Framework

Trending

  • Power BI Embedded Analytics — Part 2: Power BI Embedded Overview
  • Java Virtual Threads and Scaling
  • Contextual AI Integration for Agile Product Teams
  • How to Format Articles for DZone

User Authentication Best Practices Checklist

All sites now have the ability to provide authentication. Yet, it's still pretty tricky for devs to implement. Read on for best practices when developing authentication.

By 
Bozhidar Bozhanov user avatar
Bozhidar Bozhanov
·
Apr. 18, 18 · Analysis
Likes (8)
Comment
Save
Tweet
Share
34.5K Views

Join the DZone community and get the full member experience.

Join For Free

User authentication is a functionality that every web application shares. We should have perfected that a long time ago, having implemented it so many times. And yet there are so many mistakes made all the time.

Part of the reason for that is that the list of things that can go wrong is long. You can store passwords incorrectly, you can have a vulnerable password reset functionality, you can expose your session to a CSRF attack, your session can be hijacked, etc. So I'll try to compile a list of best practices regarding user authentication. The OWASP Top 10 is always something you should read, every year. But that might not be enough.

So, let's start. I'll try to be concise, but I'll include as much of the related pitfalls as I can cover - e.g. what could go wrong with the user session after they log in:

  • Store passwords with bcrypt/scrypt/PBKDF2. No MD5 or SHA, as they are not good for password storing. Long salt (per user) is mandatory (the aforementioned algorithms have it built in). If you don't and someone gets hold of your database, they'll be able to extract the passwords of all your users. And then try these passwords on other websites.
  • Use HTTPS. Period (otherwise, user credentials can leak through unprotected networks). Force HTTPS if the user opens a plain-text version. And make sure you use only the latest protocol (TLS 1.2 at the moment; TLS 1.1 doesn't seem to have vulnerabilities, so it can also be supported). You can do a Qualys Scan to check whether your supported protocol versions are OK.
  • Mark cookies as secure. Makes cookie theft harder.
  • Use CSRF protection (e.g. CSRF one-time tokens that are verified with each request). Frameworks have such functionality built-in.
  • Disallow framing (X-Frame-Options: DENY). Otherwise, your website may be included in another website in a hidden iframe and "abused" through JavaScript.
  • Have a same-origin policy.
  • Logout - Let your users log out by deleting all cookies and invalidating the session. This makes the use of shared computers safer (yes, users should ideally use private browsing sessions, but not all of them are that savvy).
  • Session expiry - Don't have forever-lasting sessions. If the user closes your website, their session should expire after a while. "A while" may still be a big number depending on the service provided. For Ajax-heavy websites, you can have regular Ajax-polling that keeps the session alive while the page stays open.
  • Remember me - Implementing "remember me" (on this machine) functionality is actually hard due to the risks of a stolen persistent cookie. Spring-security uses this approach, which I think should be followed if you wish to implement more persistent logins.
  • Forgotten password flow - The forgotten password flow should rely on sending a one-time (or expiring) link to the user and asking for a new password when it's opened. 0Auth explain it in this post and Postmark gives some best practices. How the link is formed is a separate discussion and there are several approaches. Store a password-reset token in the user profile table and then send it as a parameter in the link. Or do not store anything in the database, but send a few params: userId:expiresTimestamp:hmac(userId+expiresTimestamp). That way you have expiring links (rather than one-time links). The HMAC relies on a secret key, so the links can't be spoofed. It seems, however, that there's no consensus on this topic, as the OWASP guide has a bit of a different approach.
  • One-time login links - This is an option used by Slack, which sends one-time login links instead of asking users for passwords. It relies on the fact that your email is well guarded and you have access to it all the time. If your service is not accessed too often, you can have that approach instead of (rather than in addition to) passwords.
  • Limit login attempts - Brute-force through a web UI should not be possible; therefore you should block login attempts if too many occur. One approach is to just block them based on the IP. The other one is to block them based on the account attempting to log in. (Spring example here). Which one is better? I don't know. Both can actually be combined. Instead of fully blocking the attempts, you may add a captcha after, say, the 5th attempt. But don't add the captcha for the first attempt - it is bad user experience.
  • Don't leak information through error messages - you shouldn't allow attackers to figure out if an email is registered or not. If an email is not found, upon login, just report "Incorrect credentials." On password resets, it may be something like "If your email is registered, you should have received a password reset email." This is often at odds with usability - people don't often remember the email they used to register, and the ability to check a number of them before getting in might be important. So this rule is not absolute, though it's desirable, especially for more critical systems.
  • Make sure you use JWT only if it's really necessary and be careful of the pitfalls.
  • Consider using a 3rd party authentication - OpenID Connect, OAuth by Google/Facebook/Twitter (but be careful with OAuth flaws as well). There's an associated risk with relying on a 3rd party identity provider, and you still have to manage cookies, log out, etc., but some of the authentication aspects are simplified.
  • For high-risk or sensitive applications use 2-factor authentication. There's a caveat with Google Authenticator though - if you lose your phone, you lose your accounts (unless there's a manual process to restore it). That's why Authy seems like a good solution for storing 2FA keys.

I'm sure I'm missing something. And you see it's complicated. Sadly we're still at the point where the most common functionality - authenticating users - is so tricky and cumbersome, that you almost always get at least some of it wrong.

authentication

Published at DZone with permission of Bozhidar Bozhanov, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Understanding IEEE 802.11(Wi-Fi) Encryption and Authentication: Write Your Own Custom Packet Sniffer
  • Power BI Embedded Analytics — Part 2: Power BI Embedded Overview
  • Simplify Authorization in Ruby on Rails With the Power of Pundit Gem
  • Understanding the Identity Bridge Framework

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!