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).