Authentication and Session Management

pomain buthi
7 min readJan 22, 2021

--

This is actually a quick note after reading the book 《白帽子讲web安全》.

For this part, the writer provide a basic introduction about common authentication methods and some security problems in this phase.

This note is aimed at the web service provider rather than the user. Although hackers will attack both at the same time, most of the time the web service provider should realize that the danger may exist and deal with it.

Basic Process

-Authentication phase

For most web systems that require user login, they will ask their user to set at least a password.

For some systems that relate to financial or political security, they will also enable multi-factor authentication, which might include: security verification issues, real-name authentication, mobile phone binding, mobile phone dynamic passwords, biometric information binding (fingerprint and face recognition), digital certificates, payment shields (an entity random password generator), third-party certificates (usually from banks or Government department).

-Session Phase

After identify the one trying to login is the user himself, a session would be created for this user at the server, and a sessionID would be sent to the user, which means the user no longer need to login but provide a sessionID for the following usage .

So, this is what happened when user access a web service:

Risk in the Authentication phase

-Take Good Care of the password saved in your database

When user setting their password, OWASP provide some suggestion to strength the password in case hacker guess them easily:

password length:
-for normal website, no less then 6 digits
-for important case, no less then 8 digits, consider multi-factor authentication
password complexity:
-password is case sensitive
-The password is a combination of more than two of uppercase letters, lowercase letters, numbers, and special symbols
-Don't have consecutive characters, like 1234abcd
-Try to avoid repeated characters, like 11111

You should also remind your user to avoid using some number that could be easily collected by social engineering(like phone number, birthday, name, company name). Some company would provide a weak password list, when user using password upon the list, they will be asked to set a new one.

You have to consider the risk of your database leaking, clear text storage is obviously a very risky behavior that is prone to litigation(a terrible example is CSDN). A general way for this part is using MD5 or SHA-1 to encrypt the password.

Attention, the encryption algorithm can only guarantee that the original text cannot be calculated through the ciphertext, but hacker still have some less efficient solutions. One popular way is Rainbow Table, it’s basically a giant dictionary contain collections of original and cipher text. To avoid such situation, a “salt” value is suggested, it can help to extend the complexity of original text, and reduce the readability of result from Rainbow Table.

cipher_text = MD5(username+password+salt)
salt value should be keep carefully in the config file as top secrets.

-Be aware of your user

As large companies gradually strengthen their own security protection, trying to break through from users has become a more common method for hackers. You cannot expect your user would never tell their password to someone unreliable. But you should always give your user another chance to avoid further loss, especially for some important case like bank system.

Multi-factor authentication was a kind of general solution for such situation. You can set a limit that only login from specific equipment can be allowed, you can also ask your user to check their phone for one time password(OTP), you can even record how fast your user type in their password, and point out some unusual operation.

-More password don’t always means safer, but always means less user

Security issues are essentially trust issues, and security issues are essentially budget issues. You should never using a $10M strongbox to protect $10. For some simple web application without too much secrets to keep, you shall not pay too much effort on security.

For multi-factor authentication case, even you ask your user set 100 different kind of password, you still can’t stop him from giving his life savings to a liar. On the contrary, too cumbersome verification steps during the login process will make users lose patient in you, most users are indeed attracted by the so-called super security, but too many verification steps will make them give up frequent access and use. You should always confirm the security strategy based on actual usage scenarios.

For example: when using a bank system, asking user input many different password would make them believe their money were protected; but when using a social media, asking user provide personal information for authentication too many times will make them believe this platform is too hard to use.

Risk in the Session phase

Session security is much more important then login authentication sometimes, because when hacker get user’s session id, they won’t need to login anymore, and since most of the request will need sessionID, it’s also much more easier to leak.

Unlike authentication part, session part we should try to conclude from current potential attack methods.

-Leak from url parameters

Such leak occurs from some special situation (since most web application would use cookie instead of parameters).

For example, on mobile operating systems, many mobile browsers did not support cookies in the early days, which caused some websites to configure query parameters for these browsers to pass sessionid. A typical attack is: sending someone a email with image quoted from outside(since open image need get request, then the request provided for outside server will take a Referer contains “http://www.originalserver/readmail?sid=XXX).

By the way, when generate sessionID, you must ensure strong enough randomness, and do not use user’s public information as seed(since hacker might guess your generation algorithm).

-Session Fixation Attack

Such attack aimed at sessionID leaked at url too, but will aim at user instead of service provider. Even some mail service abandoned open outside image, they still let their user have the chance to know the sessionID.

Fixation attack targeting on such system: when user access through one sessionID, even they login again, the server will continue using same sessionID(not same session). Which means, hacker could request a sessionID with his own account first, then provide target user with a edited url, after user login again, hacker can use same sessionID to access other user’s account.

A typical edited url can be:
http://bbs.xxxx.com/wap/index.php?action=forum&fid=72&sid=2iu2pf

To avoid above two attack, saving your sessinID into Cookie is a general solution, but Cookie is in fact a file saved at client or browser, which also means there will be more method to attacking it. Luckily, since it’s something important for user experience, we can have more budget for this part.

-Session Keep Attack

Sometimes hacker manage to get the sessionID from user, they will try to keep to session alive, which means they can control this user forever.

By sending request frequently, they can make the server believe the user is continue using it. For some server save session config at Cookie, they will edit the expire time of the Cookie and make it a third-party Cookie.

However, we don’t have a good enough method to fix this. One way to reduce lost is setting a force expire time for user, but sometimes it will cause big trouble to the user. Another way is provide only one session for one user, so user can ‘kick out’ the hacker once they login again. For the server that save session at user client, bind session with hardware information is a good idea, but such thing can also be faked by hacker.

Single Sign On(SSO)

Single sign on has became one of the most popular system designed for user experience. In fact, many so-called ‘giant company’ in web region already became a SSO provider. Remember many website provide ‘login with google’? That is a SSO.

The benefit of SSO in secure region is: we can gather security problems together and provide unlimited budget to defense. For the google example, some small website could take help from Google, and no longer need to fight alone.

The shortcomings of SSO are also obviously:
1. Once the SSO provider was defeated, all their customer would be in extremely danger, and they even don’t have much time to deal with it. The more serious problem is that in order to avoid the loss of their own stock prices, some service providers will cover up the truth of the breach, and it is not discovered until months or even a year after the attack that part of the data flows into the public domain.
2. The provider itself could also be a danger, in fact, as I read some article written by experienced hacker, they always have such view: For some strictly guarded systems, using social engineering methods to buy off traitors is often a simpler and more direct solution. Imagine what would happen if the leader of Google’s security department provide 0day to hackers.(Let’s avoid the topic about big brother and little brothers)
3. For some vary popular provider, there could be many discussion like ‘how to apply google SSO service’. However, some of the guidance may contain some trap even 0day, which means programmers who referred it would built some website under hacker’s control. So do refer to official document when you are trying to use such service.

That’s all my share about authentication and session management security problem. In fact, I read this book when I first entered this industry, but when I have some web development experience, I read this book again. After having practical experience, I was finally able to understand the author’s pragmatic attitude towards network security. I very much agree with one of the author’s points of view: Many web attack methods are indeed script kiddies’ tactics, but these tactics and their countermeasures also need to be recorded and adequately understood.

--

--

No responses yet