Broken Authentication and Session Management

Broken Authentication and Session Management

In this type of attack, authentication or session management functions flaws are used by an attacker to impersonate other users. Application functions related to authentication and session management are often not implemented correctly, an attacker can easily get access to such sensitive user data as passwords, keys, or even hijack session tokens.

Most common user authentication ways are using of usernames and passwords. Since reliable mechanisms of authentication (for example, hardware and software based cryptographic), are expensive, most

Developers build custom authentication and session management schemes, but building such schemes correctly, is hard enough. As a result, a variety of account and session management flaws can cause the compromise of the user or even system administration accounts. So, it is important for developers to understand how complex is designing authentication and session management schemes that protect all areas (login, logout, password management, remember me, account update etc.) in all aspects.

Sessions, Cookies, and Authentication

To understand broken authentication and session management cookies first, we need to cover such concepts as session cookies and authentication.

Sessions and Cookies

HTTP (Hypertext Transfer Protocol) ,web applications work on, is a stateless protocol. In other words, a server cannot keep a memory of the users’ identity who connect to a website. When you log in to some website and want to update your bio info and since HTTP is stateless protocol, you must enter your credentials for the requests being sent to the server because the server doesn’t know who you are.

So, how servers can track users’ activity? It is obvious that users cannot enter their username and password each time when they make requests. In order to resolve this problem, servers generate a session for each connection with a unique session token ( session ID ). Since the server generated a session ID for the user, the client doesn’t need to provide their information for each subsequent request.

Cookies in contrast to sessions store the data on the user’s computer. The website uses cookies to keep track of your activity within the website. This allows you to continue your activity where you left off and remembers registered login.

When the user clicks on the Logout link, the cookie with the session ID will be deleted and the server will terminate the user’s activity.


authentication is a process of a user’s identity, ensuring and confirming. Web application carry out it in the form of a username and password verification.


1)bad identity management:

let’s consider such login page: the first field requires you to enter your phone number, the second requires your passwords and there is a hint which simply says that your password is last 4 digits of your phone number… Since the number is something that is public and anyone can easily acquire it, its example of a bad identity management

2) identity enumeration:

let’s consider you want to restore your password. You go to the special page for that and enter some email and click on the reset button. After that, you will get some notification message like this “There is no such email registered on our website” or message like “password reset was successful, visit your email” . So this simply means that a hacker using brute force (passing a lot of emails to form for the reset password) can get an access to a list of emails users registered on this page.

The solution to this problem is always giving the same response, whether an entered email exists in your database or not. In both cases,you should send email  to the entered email address. But with the different context: in one, you’ll be writing something related to password reset (if someone really registered with that email in your website). In the other email you will write something like this: “There is no  user in our website with this email.”

Protective Measures:

Session management

1) User sessions or authentication tokens should be timed out, in other words, they should be invalid after logout.

2) Passwords need protection. Your application should  protect them using hashing or encryption.

3) Session IDs should not be reflected in the URL. If someone else can access ids, he can use the user’s account

4)  You shouldn’t send such sensitive data as session IDs over unencrypted connections.

Broken authentication

1) Password length: Minimum password length is recommended to be eight characters long.

2)Password strength: Passwords shouldn’t just consist of letters or numbers. It should be a combination of letters, numbers and other symbols.

3) Username/Password Enumeration: if the user fails to enter valid credentials, the website should not tell the user which part of the authentication data was incorrect. So, instead of using “Invalid username” or “Invalid password” in case of failure, you should use “Invalid username and/or password” in both cases.