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
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.
Separate the authentication solution used for internal purposes from the one used for unsecured access (public access or DMZ).
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.
Refer to the Forgot Password Cheat Sheet for detailed guidance on implementing this feature securely.
Consult the Password Storage Cheat Sheet for comprehensive information on securely storing passwords.
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.
Implement current password verification to confirm the legitimate user is changing the password. This prevents unauthorized access on public computers and maintains account security.
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.
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.
Applications should respond to errors in a generic manner to avoid revealing specific information about the nature of the error.
Defenses such as Multi-Factor Authentication (MFA), login throttling, CAPTCHA challenges, and security questions can be used in combination to protect against these attacks.
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.