Ok to store password hash in session data?

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: Ok to store password hash in session data?

Post by VladSun »

flying_circus wrote:c93de8b56e3881113d23ac5d1efa568344b56d680d99a2e5c8b78f50f78bf596

What would one do with it short of spinning their wheels trying to brute force it?
Wiki:
SHA-2 consists of a set of four hash functions with digests that are 224, 256, 384 or 512 bits.
http://ldn.linuxfoundation.org/blog-ent ... -kernelorg
“Small” is relative; git’s hash function produces 160-bit numbers, which are quite big by normal standards - it is roughly equal to the number of atoms in the Earth.
There are 10 types of people in this world, those who understand binary and those who don't
User avatar
Mordred
DevNet Resident
Posts: 1579
Joined: Sun Sep 03, 2006 5:19 am
Location: Sofia, Bulgaria

Re: Ok to store password hash in session data?

Post by Mordred »

flying_circus wrote:Mordred, I appreciate your thoughts. If I may:
Mordred wrote:The crucial difference is in the data lifetime, since one is more volatile than the other.
I will have to think some more about this. I first glossed over it, thinking "so what, sessions are disposable. The value stored here has no merit other than it does or doesn't match." Though, it would be an interesting predicament in a weak hashing scenario to change your password and still pass the comparative validation due to a collision. Almost impossible, but I suppose that's the trouble with almost.
The point is that the difference between the two is what you would keep in each of these storages, since they have different lifetimes. Ultimately noone but your code has access to them (assuming no vulnerability is present; read on for that case). So you CAN keep password hashes in the session, it's just that you SHOULDN'T need to, since it's already in the database.
flying_circus wrote:
Mordred wrote:I might add that in my experience you are much more likely to have a vulnerability exposing database data than session data (think of how often you output data coming from one and the other source; in addition with vulnerable database access you can use timing attacks to extract info even without actual HTML output.
This is opposite of what I expected to hear. When I posted this topic, I expected every one to say "No, You'd be a fool to do that." Your reply hints that the medium in which you store your sessions plays a greater role in security, than actually storing the value in the session. It would not be difficult to argue that as long as your user credentials are stored in the database, and your sessions are stored in the database, you'd be equally secure/vulnerable, just effectively doubling your exposure?
If we assume there's a security problem, it's much more likely that it would expose database data than session data. One should be extra creative to invent a situation where you would expose session data (having already excluded the case with misconfigured shared hosting, which is a separate issue). Assigning and reading from $_SESSION doesn't have the side effects mysql_query() has (even if you keep your sessions in the database, you may have a problem with the session->database functions, but then it's just an SQL injection). This is why I argue that you should be more worried about the hashes kept in the database, rather than those kept in the session.
flying_circus wrote:
Mordred wrote:2. That said, I don't see why you would need such thing at all.
I'm interested in alternative solutions not yet suggested.
Alternative: Do not keep the bloody hash in the bloody session. Get it from the database if you need it. You shouldn't need it btw, except when you check the login credentials. Then you read it, and store a "login proof" in the session - might be as simple as storing the user id to determine if the user is logged, or even a $_SESSION['is_logged'] boolean.

Returning to your original post:
flying_circus wrote:When a user authenticates, I want to store the user id and password hash in the session. On each page request, I would check for the existance of user id and then compare the password hash with what is on file in the database. If the password hash does not match, this means the user password was changed and to kill the session.
Basically it would boot anyone who was logged in under your account.
This is useless. It serves no (funtional) purpose. What is, in your head, the attack scenario that makes this necessary? Who will change the password and why? What follows?
flying_circus wrote: Edit: Also, as a side note. I thought the main reason for using SHA2 algorithms is that they have (so far) been proven cryptographically secure. Provided I am using best practice when hashing, if I posted the password to my user in plain sight:

c93de8b56e3881113d23ac5d1efa568344b56d680d99a2e5c8b78f50f78bf596

What would one do with it short of spinning their wheels trying to brute force it?

That's unrelated (I think -- since you won't be actually presenting the hashes to the public), but I here's an answer anyway.
With not very well sorted hashes, bruteforce attacks (or, ok, optimizations thereof) are effective. Precomputed tables (of which the "rainbow tables" attack is the most popular) for unsalted hashes and dictionary attacks for unpeppered hashes work well enough. This is the problem with hashed passwords.
Hash collisions (as mentioned previously in the thread) do not play any role whatsoever, nor does hash algo/size (the only difference is the factor of speed, larger hashes tend to be slower, so the bruteforce would take longer, but only by a constant).
Post Reply