6

A user logs in and is given a session token. This token is also stored in a database on the server. The user includes this secret token with each request, and the server will pull it from the DB to authenticate the user.

This scheme is vulnerable to someone (an angry DBA perhaps) sniffing the token out of the DB and hijacking the user's session. Keeping the session token store in memory increases the difficulty of sniffing the key, but it is still not impossible.

What is the generally accepted way of securely storing session tokens?

Allen Kross
  • 61
  • 2

3 Answers3

6

I'd say that for most cases it's generally considered that once an attacker has DBA level access to your system it's compromised, therefore mitigating this attack would more likely be done via policy/change management/activity monitoring etc.

If you think about the damage an angry DBA can do to a system, sniffing one users session token is likely quite far down the scale...

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
3

An angry Database Administrator could inject JavaScript in database-provided contents and perform pristant XSS attacks against your users, which will enable him to steal the session identifiers right form the user's browser, making any place in which you store the identifiers on the server as good as storing in the database.

So the method you're proposing isn't really insecure, I'd just prefer using built-in session management such as PHP's $_SESSION[] and .Net's Session[].

Adi
  • 43,808
  • 16
  • 135
  • 167
  • ... so what about SQL injection? – rook Jun 18 '13 at 21:01
  • @Rook What about them? Actually, what about Local File Inclusions? What about _Remote_ File Inclusions? What about using weak root password? What about XSS vulnerabilities? Using this argument makes everything 100% insecure because _something_ could go wrong. I'm actually quite surprised this coming from you, Rook. You have incredible answers and questions all over the SE network regarding security, yet you'd think about this like that. – Adi Jun 18 '13 at 21:26
  • defense in depth, plan on failure. Hash authentication credentials. – rook Jun 18 '13 at 21:52
  • @Rook Oh come on! You downvoted me just because you _thought_ I downvoted you? Not that it's a big deal, but I didn't downvote you. If have, I'd explicitly say "-1". – Adi Jun 19 '13 at 19:16
  • I down-voted this because its just wrong... why are you talking about XSS, when SQLi is the obvious attack vector? XSS should always be managed by the view... trusting the DB for this is type of input will always lead to failure because you do not know the proper escape function to use, it can also lead to 2nd order injection. Also they should be using HTTPONly cookies, which was not mentioned. So yes, there is a lot wrong with this post. Even with HTTPONly cookies, SQLi would lead to an immediate compromise of **every** session... **bad news**! and easy to prevent. – rook Jun 19 '13 at 19:28
  • @Rook I'm sorry, but I still disagree with you. Using your logic we shouldn't use normal sessions because an attacker might using an LFI vulnerability and get access to the session files (in PHP, for example). Using the same logic you shouldn't use a login system at all because a user could use a weak password. Actually, why store usernames and passwords in the first place? They could be dumped using SQL Injection!! Oh please, look at what you're saying! – Adi Jun 19 '13 at 19:35
  • OAuth is better then storing usernames and passwords, and if you have an OAuth RFC-complaint system you will not be storing OAuth tokens in plaintext... for the exact same reason. I hack into secure systems for a living and I am very good at my job. Some of my success is because of faulty designs such this, which are very common. – rook Jun 20 '13 at 00:21
  • Also, side note. Don't trust any data source, not even your database. This is the cause of 2nd order code injection, which is a very interesting attack pattern that I recommend that you study. – rook Jun 20 '13 at 00:50
1

The reason why we hash passwords is when an attacker has access to the database (using sql injection), then he must spend time and resources to crack the password hash before it is useful.

Storing the session token in the database is a shortcut, you now are storing authentication credentials in the database that can be used immediately. It is as if you are storing passwords in plaintext.

Password Reset Tokens, Session Identifiers, and Passwords must all be hashed when this data is persisted.

rook
  • 46,916
  • 10
  • 92
  • 181
  • 2
    I strongly disagree. That's not why we hash passwords. We don't hash passwords to prevent access to the account on the compromised system itself; an attacker with a database dump already has access to all of the account's information. We hash passwords to make access _to the passwords_ more difficult, to prevent subsequent attacks of accounts using the same passwords on another systems (belonging to the same entity or totally different entity). So, **no**, leaving a session identifier unhashed isn't the same as leaving the password in plaintext. – Adi Jun 18 '13 at 21:24
  • @Adnan Hmm, this comment strongly lacks the attacker mind set. All I see is exploit code that dump password hashes, all I see is dataleaks of username password hashes. All of these hashes are meaningless if you give the attacker a short cut. Perhaps you should try writing an exploit sometime. – rook Jun 18 '13 at 21:51
  • 1
    @Adnan, for an example of why there is concern of storing the hash, see this article on (ab)using them: http://www.offensive-security.com/metasploit-unleashed/PSExec_Pass_The_Hash – John Deters Jun 19 '13 at 01:56
  • @John Deters that is a great example of an attacker breaking into a system. This is exactly why we hash passwords... and why Microsoft is foolish for not using key stretching. – rook Jun 19 '13 at 19:14
  • 1
    @Rook I disagree with your answer as well. It's certainly understandable from a pen-tester's perspective that you would want every security measure possible to be utilized, but when you look at it holistically, from a risk management perspective, there's much that can be done to secure a session state management database without requiring the overhead of hashing. Is it as absolutely secure? For some vectors, no, of course not. In the greater scheme is it a good trade-off? Yes, and this is why virtually every system on earth makes it. – Xander Jun 19 '13 at 19:49
  • @Xander Oah so I take it you store your passwords in plaintext. From a functional preservative there is no difference. You are storing a secret key in a readily available format. – rook Jun 20 '13 at 00:20
  • 1
    @Rook No, of course not, and from a functional perspective, there are very big differences. Here are two: 1) Duration of validity, and 2) Frequency of use. A password is valid on the site potentially forever. A session id is valid for a very short time. Second, the idea that you should hash session identifiers on every single HTTP request, just in order to deal with a very limited and easy to contain threat doesn't sound like a particularly plausible architecture option to me. – Xander Jun 20 '13 at 00:30
  • @Xander Ok i have a SQL injection vulnerability in your web application. I am going to dump your database, and i can dump your database as many times as i want. My goal is to access administrative account. How do you propose that you stop this from happening? I want you to come up with a real solution, that is all I am going to listen to. I want real solutions to this real world problem, because I'm a hacker and I'm going to look for anyway i can to make you bleed. – rook Jun 20 '13 at 00:45
  • @Rook Sure, so typically, you're not going to do session management in the same database that your web app uses for content/users/general app data, so you've got a level of isolation there. Then, because you have basically two state management method calls (get session and put session) (typical that are abstracted from you and maintained in a session management library, you have a database that has very limited surface area and can be far more easily locked down than the web app as a whole. – Xander Jun 20 '13 at 00:53
  • @Xander Boom! Now we are talking the same language! What other authentication tokens are stored in the database? Password reset tokens? OAuth tokens? CSRF Tokens? Now this starts becoming an expanding attack surface... – rook Jun 20 '13 at 01:48
  • @Rook I completely agree that each of those items has its own unique set of architectural and security concerns, however, they're also off-topic for this question which is quite specifically about session state management. – Xander Jun 20 '13 at 20:56