The cheat sheet below condenses insights extracted from the OWASP article about security best practices for authentication. This table aims to offer a concise and user-friendly overview that can be swiftly referenced for a quick grasp of key points. For further information, please visit OWASP – Authentication.

Topic
User IDs
Email Address as a User ID
Authentication Solution and Sensitive Accounts
Implement Proper Password Strength Controls
Implement Secure Password Recovery Mechanism
Store Passwords in a Secure Fashion
Compare Password Hashes Using Safe Functions
Change Password Feature
Transmit Passwords Only Over TLS or Other Strong Transport
Require Re-authentication for Sensitive Features
Consider Strong Transaction Authentication
TLS Client Authentication
Authentication and Error Messages
Protect Against Automated Attacks
Error Codes and URLs
Conclusion
Key Points
Ensure usernames/user IDs are case-insensitive and unique.
For example, 'smith' and 'Smith' should be considered the same user.
In high-security applications, consider using secret and assigned usernames instead of allowing user-defined public data.
To ensure proper validation of email addresses, refer to the input validation cheatsheet's email discussion section.
Avoid allowing logins with sensitive accounts (internal accounts used for backend, middleware, or database) to any front-end user interface to prevent potential security breaches.
Separate the authentication solution used for internal purposes from the one used for unsecured access (public access or DMZ).
Password strength is a crucial factor in authentication security. A strong password policy makes it difficult for attackers to guess passwords through manual or automated means.
Key characteristics of strong passwords include adequate length, allowing all types of characters (including unicode and whitespace), and the absence of restrictive password composition rules.
Many applications offer a password recovery mechanism to help users regain access to their accounts.
Refer to the Forgot Password Cheat Sheet for detailed guidance on implementing this feature securely.
Storing passwords using the right cryptographic techniques is critical to prevent unauthorized access to sensitive user data.
Consult the Password Storage Cheat Sheet for comprehensive information on securely storing passwords.
When verifying passwords, always use secure password comparison functions provided by the language or framework.
Ensure these functions have maximum input length restrictions, set variable types explicitly to avoid type confusion attacks, and return in constant time to protect against timing attacks.
When implementing a change password feature, ensure active user authentication with an active session.
Implement current password verification to confirm the legitimate user is changing the password. This prevents unauthorized access on public computers and maintains account security.
The login page and all subsequent authenticated pages must be exclusively accessed over a secure transport layer (TLS or other strong transport).
Failing to use TLS for the login page can lead to attackers modifying the login form action and compromising user credentials.
Requiring users to provide their current credentials before making changes to sensitive account information (password, email, etc.) or performing sensitive transactions adds an extra layer of security against CSRF and session hijacking attacks.
Some applications benefit from using a second factor of authentication to authorize sensitive operations, adding an extra layer of security to critical actions.
TLS Client Authentication, also known as two-way TLS authentication, involves both the browser and server exchanging their TLS certificates during the handshake process.
This approach is suitable when users access the website from a single computer or browser, or when extra security measures are required, such as in an intranet environment.
Properly implemented error messages in authentication processes are crucial. Incorrectly implemented error messages can be exploited for user ID and password enumeration.
Applications should respond to errors in a generic manner to avoid revealing specific information about the nature of the error.
Various types of automated attacks, including brute-force attacks, pose risks to user accounts.
Defenses such as Multi-Factor Authentication (MFA), login throttling, CAPTCHA challenges, and security questions can be used in combination to protect against these attacks.
Applications may return different HTTP error codes based on the outcome of authentication attempts. These codes can inadvertently leak information about account validity.
Consider error handling and disclosure in your application to prevent such leaks.
By adhering to these authentication guidelines and implementing a combination of security measures, applications can significantly enhance their defenses against a variety of attacks and potential vulnerabilities.