Flawed authentication and session management are the second most critical vulnerability in web applications nowadays.
Authentication is the process whereby users prove that they are who they say they are; this is usually done through usernames and passwords. Some common flaws in this area are permissive password policies and security through obscurity (lack of authentication in supposedly hidden resources).
Session management is the handling of session identifiers of logged users; in Web servers this is done by implementing session cookies and tokens. These identifiers can be implanted, stolen, or "hijacked" by attackers by social engineering, cross-site scripting or CSRF, and so on. Hence, a developer must pay special attention to how this information is managed.
In this recipe, we will cover some of the best practices when implementing username/password authentication and to manage the session identifiers of logged users.
- If there is a page, form, or any piece of information in the application that should be viewed only by authorized users, make sure that a proper authentication is done before showing it.
- Make sure usernames, IDs, passwords, and all other authentication data are case-sensitive and unique for each user.
- Establish a strong password policy that forces the users to create passwords that fulfill, at least, the following requirements:
- More than 8 characters, preferably 10.
- Use of upper-case and lower-case letters.
- Use of at least one numeric character (0-9).
- Use of at least one special character (space, !, &, #, %, and so on).
- Forbid the username, site name, company name, or their variations (changed case, l33t, fragments of them) to be used as passwords.
- Forbid the use of passwords in the "Most common passwords" list: https://www.teamsid.com/worst-passwords-2015/.
- Never specify in an error message if a user exists or not or if the information has the correct format. Use the same generic message for incorrect login attempts, non-existent users, names or passwords not matching the pattern, and all other possible login errors. Such a message could be:
Login data is incorrect.
Invalid username or password.
Access denied.
- Passwords must not be stored in clear-text format in the database; use a strong hashing algorithm, such as SHA-2, scrypt, or bcrypt, which is especially made to be hard to crack with GPUs.
- When comparing a user input against the password for login, hash the user input and then compare both hashing strings. Never decrypt the passwords for comparison with a clear text user input.
- Avoid Basic HTML authentication.
- When possible, use multi-factor authentication (MFA), which means using more than one authentication factor to login:
- Something you know (account details or passwords)
- Something you have (tokens or mobile phones)
- Something you are (biometrics)
- Implement the use of certificates, pre-shared keys, or other passwordless authentication protocols (OAuth2, OpenID, SAML, or FIDO) when possible.
- When it comes to session management, it is recommended that you use the language's built-in session management system, Java, ASP.NET, and PHP. They are not perfect, but surely provide a well designed and widely tested mechanism and they are easier to implement than any homemade version a development team, worried by release dates, could make.
- Always use HTTPS for login and logged in pages—obviously, by avoiding the use of SSL and only accepting TLS v1.1, or later, connections.
- To ensure the use of HTTPS, HTTP Strict Transport Security (HSTS) can be used. It is an opt-in security feature specified by the web application through the use of the Strict-Transport-Security header; it redirects to the secure option when
http://is used in the URL and prevents the overriding of the "invalid certificate" message, for example, the one that shows when using Burp Suite. For more information, you could check: https://www.owasp.org/index.php/HTTP_Strict_Transport_Security. - Always set HTTPOnly and Secure cookies' attributes.
- Set reduced, but realistic session expiration times. Not so long that an attacker may be able to reuse a session when the legitimate user leaves, and not so short that the user doesn't have the opportunity to perform the tasks the application is intended to perform.
Authentication mechanisms in Web applications are very often reduced to a username/password login page. Although not the most secure option, it is the easiest for users and developers; and when dealing with passwords, their most important aspect is their strength.
As we have seen throughout this book, the strength of a password is given by how hard it is to break, be it by brute force, dictionary, or guessing. The first tips in this recipe are meant to make passwords harder to brute-force by establishing a minimum length and using mixed character sets, harder to guess by eliminating the more intuitive choices (user name, most common passwords, company name); and harder to break if leaked, by using strong hashing or encryption when storing them.
As for session management: the expiration times, uniqueness, and strength of session ID (already implemented in the language's in-built mechanisms), and security in cookie settings are the key considerations.
The most important aspect when talking about authentication security probably, is that no security configuration or control or strong password is secure enough if it can be intercepted and read through a man in the middle attack; so, the use of a properly configured encrypted communication channel, such as TLS, is vital to keep our users' authentication data secure.