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?

|improve this question
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...

|improve this answer
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[].

|improve this answer
  • ... 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
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.

|improve this answer
  • 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: offensive-security.com/metasploit-unleashed/… – John Deters Jun 19 '13 at 1:56
  • 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
  • 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 0:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.