TechnologyApr 10, 2014

Top Ten Security Risks: Broken Authentication and Session Management (#2)

Micah Jones

The second most highly ranked web security risk, according to the Open Web Application Security Project (OWASP), is broken authentication and session management. That risk encompasses several security issues, all of them having to do with establishing and maintaining the identity of a user.

Defining the Problem

OWASP described broken authentication and session management as follows:

Vulnerabilities include the following:

1.  Storing user credentials without hashing or encrypting them__.__

Database security breaches are undesirable to begin with, but they are absolutely devastating when filled with plaintext passwords. Even if you force users to change their passwords after they are exposed, the tendency of many people to reuse passwords means you may have made them vulnerable on websites other than your own.

Solution: Protecting user passwords is critical. Normally it is best to use a strong hashing function with unique salts. See this article for more information.

2.  Easily guessed passwords.

In my graduate network security course, I was once assigned the task of cracking a series of hashed UNIX passwords. I used a tool called John the Ripper, with a custom 40 MB text file dictionary derived from several freely available online sources. Passwords not found in the dictionary were brute forced, which took long enough that I gave up. Passwords that were in the dictionary were cracked almost instantly. Thanks to large-scale database dumps like the RockYou breach in 2009, hackers have extremely powerful dictionary attacks at their disposal, such that any password that has ever been previously used may be at risk.

Solution: The term “dictionary attack” can be misleading, as it has to do with lists of common, known passwords, not merely human language dictionaries. In fact, solutions that thwart those lists can be surprising. It is extremely difficult to force the user to pick a good password, so the most common approach is to require a minimum length and usage of uppercase and lowercase letters, numbers, and symbols. However, it is good to provide education wherever possible. One good strategy for password selection is to use a sentence acronym. For example, the first half of the well-known Bible verse John 3:16 could become “FGsltw,tHgHobS,Jn3:16a”, which is long, extremely difficult to guess, and easy to remember if you know the verse itself.

3.  Poorly secured password change features.

If a user leaves a machine unattended while logged in, a nearby attacker may attempt to physically access the account and change the password. If the password change feature does not require re-authentication, this is an easy process.

Solution: When users try to change their password, always require them to re-authenticate themselves first. Ideally, they would be required to enter their old password and provide a secondary form of authentication, such as answering a security question.

4.  Poorly secured password recovery features.

Similarly, password recovery options sometimes lack strong authentication measures. A common practice is to ask security questions, but weak questions may be answerable by anyone who has some familiarity with the user. As one white paper puts it, “It’s amazing how many institutions believe that your date of birth and your mother’s maiden name are sufficiently obscure to protect your bank account.”

Solution: Password recovery is a challenging thing to secure. Many recovery features send users an email. In this case, never give the users their previous password, as you have no way of knowing how much you can trust users’ email accounts. Besides, if you’ve properly hashed the password, you shouldn’t be able to do that anyway. A preferable solution would be to provide a single-use link (or, alternately, a single-use temporary password) to a web page that lets the user create a new password. Ideally, secondary authentication would also be required. See this white paper for more information.

5.  Session IDs exposed in a URL.

For example, an airline website might use the following URL: Users may wish to share information about the sale on that page with their friends, so they email them the link. When the friends follow the link they are unknowingly gaining access to the entire authenticated session, complete with credit card info.

Solution: Never put the session ID in a URL. Use POST rather than GET.

6.  Session IDs are vulnerable to session fixation attacks.

Session fixation occurs whenever attackers control the issuing of a session ID to the user. In doing so, the attacker does not need to obtain the session ID at all, because they created it themselves. Suppose the airline in the previous example not only exposed a session ID in the URL, but that it did not require that ID to be generated from the server itself. Attackers could simply construct that link themselves without a session even being active, then email it to the user from an account claiming to be owned by the airline itself. The user would click the link, thus beginning a new session with an ID created by the attackers. The attackers follow the same link, gaining access to the session after the user authenticates.

Solution: Make certain that every session ID is generated on the server, and never let users set one themselves. See Section 5 of this white paper.

7.  Session IDs don’t reasonably timeout or sessions aren’t properly invalidated during logout.

Long or non-existent timeouts leave sessions vulnerable to reuse by people other than the user. For example, users at a public computer might close the browser, thinking that would automatically log them out, but an attacker might re-open the browser some time afterward, re-entering the same session. In another scenario, the user might actually “log out”, but the session ID would remain in existence, allowing an attacker with access to the ID to re-enter the session without re-authenticating. Session IDs exposed in URLs (see number 5 above) would be particularly vulnerable to such an attack.

Solution: Impose strict timeouts on session IDs, and rotate them on a regular basis if a user is actively using the session for an extended period of time. Ensure that session IDs are rejected by the server after logout.

8.  Session IDs aren’t rotated after a successful login.

In this case, the session ID exists in two different contexts: an authenticated state and a non-authenticated one. An attacker could start a session, continued through login by a legitimate user, and then re-use the same session to access the user’s account.

Solution: In addition to any regular session ID rotation, set a new ID every time there is a major transition, including authentication and switching to SSL.

9.  Passwords, session IDs, and other credentials are sent over unencrypted connections.

Unencrypted transmissions allow monitoring by anyone with access to the connection itself. Besides the possibility of someone stealing the credentials themselves, this opens up a number of other dangers, including man-in-the-middle and replay attacks.

Solution: Any credentials must be transmitted over a secure, encrypted connection, preferably SSL. Avoid homegrown security and encryption methods.

10.  Browser caching is enabled.

After a user logs out, an attacker can use the same machine and the browser’s history to go back to the login page and re-use the cached credentials.

Solution: Take measures to disable browser caching. Use no cache tags and disable autocomplete whenever possible.


Securing authentication and session management is a broad, complex area of security, but it is essential to preserving the identity and trust of the user. Always follow good practices to protect your users’ identity, including their passwords and session IDs. Hash passwords, encourage good password selection, require re-authentication to change passwords, force users to change their passwords when trying to recover accounts, never put a session ID in a URL, ensure all session IDs originate at the server, timeout and rotate session IDs at intervals and security context changes, use safe encrypted connections, and disable browser caching.

Educate both developers and users about good security practices whenever possible, and be quick to patch vulnerabilities as soon as you are made aware of them. It is vital that your users be able to trust you with their information.