Secure Development - Authentication

In the last two posts, we've talked about access control (authorization) and session management. Today we'll look at the final component that ties these two together into a coherent web application security approach: authentication. After all, it's nearly pointless to have strong access control and session management when there is insufficient authentication taking place to ensure users are who they claim to be.

Authentication is required for all non-public parts of an organization's website. In some cases it may only be used to make a simple yes/no decision: for example, many subscription services really only care that you're on the list of subscribers. In other cases, there may be complex application and/or business logic associated with the access rules and user roles within the application. Authentication is not only important for access control purposes, but also for logging and non-repudiation in the future.

First, a quick recap of the basics: there are three different types of authenticators, which can be used either alone or in combination (called multi-factor authentication):

1. Something you know - passphrases, passwords, PIN codes
2. Something you have - magnetic stripe or smart cards, tokens, physical keys
3. Something you are - biometrics: fingerprint, retinal scan, voice recognition, hand shape

The majority of web applications use single-factor password-based authentication, where a user is identified by a username, ID number, or e-mail address and authenticates himself by entering a secret password known only to the user and the system. In fact, the system does not even need to know or store the actual password--a hash that uniquely identifies the password is sufficient. This is true because the system does not care about the contents of the password; it only needs to make a yes/no decision when the user enters his password: if the hashes of the stored and entered password match, then access is granted.

Although relatively rare, some web applications add a second or third factor to the authentication process. Web applications face unique challenges when dealing with non-password based authenticators since they cannot directly read input from an attached device (such as a smartcard reader or fingerprint scanner). As a result, a popular way to add token-based authentication to web applications is actually very low-tech: manual data entry. The user gets a small device with a display, and he is then required to enter a dynamic code from this device in addition to his regular password.

This approach was first popularized by RSA's SecurID tokens and has since been adapted by many others. However, note that once the user enters the code being displayed on the token, it essentially becomes another "something you know" rather than "something you have." For example, a phisher could set up a site that looks identical to the login page of your application, prompting the user for his username, password, and current token code. As soon as the user enters his credentials (including the current token code), the attacker's program turns around and authenticates to the real application. Most token codes are valid for at least 30 seconds, and often up to several minutes, giving an attacker ample time to use the credentials before the token code expires. To keep the user at bay, the attacker could display a fake failure page stating that the system is currently down for maintenance and to try back in a few hours. During this time, the attacker has free run of the user's account without ever needing to have physical possession of the token.

In other words, even strong two-factor authentication is not foolproof. The need to educate your users about phishing and other social engineering tactics is ever-present, because even the best SSL certificate won't make your application any more secure if users are not paying attention to their URL bars before proceeding. However, the issue of under-educated users is somewhat separate from this discussion and spills over into almost all areas of IT security. In the remainder of this post, we will focus on techniques you can use to make your application's password-based authentication mechanisms more secure:

1. Password Policy: Require user passwords to meet certain minimum complexity requirements, such as being at least 8 characters long and needing to contain at least an uppercase letter, lowercase letter, and number. There are many sets of requirements out there, and the most appropriate ones will depend on the criticality and threat model of your particular application. Regardless of complexity requirements, passwords should also expire after a given number of days, users should not be able to re-use passwords within a certain number of cycles, and should not be allowed to quickly cycle through passwords to get back to their previous password. These measures reduce the likelihood of successful password guessing and brute-force attacks, but be aware that they may increase your users' inclination to write them down in insecure places (especially if you require password changes every 30-60 days)--so it is important to strike a balance.
2. Password Transmission and Storage: There are literally no legitimate reasons to transmit or store a password in plain text. Passwords should always be sent encrypted, even if they are only traversing your internal network. Passwords should never be stored unless they are hashed (or encrypted in some rare situations). Unless there is a need to recover the password's plaintext in the future, they should always be hashed, which is a one-way function that cannot be reversed. This prevents a malicious insider with access to the decryption key from discovering users' passwords--nobody can recover passwords in this case; they can only be reset. Secure storage of passwords also applies to logging and URL parameters: logged unsuccessful login attempts should never include the attempted password (it could be very similar to the real one) and passwords should never be part of the URL's GET parameters (even when an SSL connection is used) since it will probably be logged by the server in plain text and/or cached in the client browser's history.
3. Password Resets: Be very careful when implementing your "I forgot my password" mechanisms. never send an unencrypted password back to the user (see above). Instead, generate a new one-time password (never use the same password for all resets) and send it to the user's registered e-mail address or cell phone via SMS (never let them specify where to send it). This password should expire within a short time frame if unused; it should also require a password change immediately when the user logs in. Finally, be aware that most password reset mechanisms can be abused to enumerate user accounts: an attacker can keep trying likely account names until he sees a message that a password reset has been sent successfully. Luckily, this is not a very stealthy approach: the user will see the reset e-mail and become suspicious. However, it can be an effective denial-of-service/nuisance attack if all users' passwords have been reset.

Proper management of passwords is crucial to the integrity of your authentication process, especially if your web application is like most and relies on single-factor password authentication. In turn, the session management and access control components of your application rely on strong authentication to form a comprehensive application security layer.

Next time, we will talk more about insecure storage issues, building on today's discussion of proper password storage.