Ok to store password hash in session data?
Moderator: General Moderators
- flying_circus
- Forum Regular
- Posts: 732
- Joined: Wed Mar 05, 2008 10:23 pm
- Location: Sunriver, OR
Ok to store password hash in session data?
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.
Is there any reason not to store the password hash in the session? The thought seems wrong, but I can't figure out why.
Basically it would boot anyone who was logged in under your account.
Is there any reason not to store the password hash in the session? The thought seems wrong, but I can't figure out why.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Ok to store password hash in session data?
There are a couple reasons not to store the password in the session. The main one is security -- especially when you do not control access to the entire server hosting a site. On shared hosting it may be possible for someone to gain access to the session data and thereby discover passwords in it.
Probably the reason that it seems wrong to you is because of the mixing of Authentication and Access Control. Authentication is determining that the user is who they say they are. That is usually done by them supplying Credentials. One the other had, Access Control is determining what a user (Authenticated or not) is allowed to view on a website.
Probably the reason that it seems wrong to you is because of the mixing of Authentication and Access Control. Authentication is determining that the user is who they say they are. That is usually done by them supplying Credentials. One the other had, Access Control is determining what a user (Authenticated or not) is allowed to view on a website.
(#10850)
Re: Ok to store password hash in session data?
If you use proper hashing, that is a strong hashing algorithm (e.g. whirlpool or sha512) along with salt & pepper, nobody would be able to retrieve any useful information from your session data. Besides, the number of people who actually can and will access your session data, is really pretty small.
Nonetheless it couldn't hurt to put an extra hashing step on the session data. For example, what you could store in the session data is: hash(p.s.u) where "hash" is a strong hash algorithm, "p" is the password hash which is stored in your database, "s" is some salt string, and "u" is some user dependent data (for example their user ID).
Keep in mind that session hijacking is still a risk, and depends on client side security (i.e. your visitor's). This wouldn't mean someone could ever read the actual session data, let alone extract anything useful from it if you apply hashing, but someone could still steal the session ID and impersonate another visitor. Including the visitor's IP in the "u" string above may help against this (at the trade-off of forcing people to re-login if they change location).
Nonetheless it couldn't hurt to put an extra hashing step on the session data. For example, what you could store in the session data is: hash(p.s.u) where "hash" is a strong hash algorithm, "p" is the password hash which is stored in your database, "s" is some salt string, and "u" is some user dependent data (for example their user ID).
Keep in mind that session hijacking is still a risk, and depends on client side security (i.e. your visitor's). This wouldn't mean someone could ever read the actual session data, let alone extract anything useful from it if you apply hashing, but someone could still steal the session ID and impersonate another visitor. Including the visitor's IP in the "u" string above may help against this (at the trade-off of forcing people to re-login if they change location).
- flying_circus
- Forum Regular
- Posts: 732
- Joined: Wed Mar 05, 2008 10:23 pm
- Location: Sunriver, OR
Re: Ok to store password hash in session data?
You're probably right. Thanks for the outside perspective.Christopher wrote:Probably the reason that it seems wrong to you is because of the mixing of Authentication and Access Control. Authentication is determining that the user is who they say they are. That is usually done by them supplying Credentials. One the other had, Access Control is determining what a user (Authenticated or not) is allowed to view on a website.
This is my mindset. Passwords are hashed using sha256, along with a salt, pepper, and username as ingredients. Because not all of the pieces of the puzzle are stored in the session, it would still remain quite a feat to reconstruct the original password. Sessions are also stored in a database, they aren't written to the disk.Apollo wrote:If you use proper hashing, that is a strong hashing algorithm (e.g. whirlpool or sha512) along with salt & pepper, nobody would be able to retrieve any useful information from your session data. Besides, the number of people who actually can and will access your session data, is really pretty small.
Isn't this a poor security practice, double hashing? I was of the opinion that there was no security gain and I'd be reducing the entropy, not to mention making the cpu work harder, thoughts?Apollo wrote:Nonetheless it couldn't hurt to put an extra hashing step on the session data. For example, what you could store in the session data is: hash(p.s.u) where "hash" is a strong hash algorithm, "p" is the password hash which is stored in your database, "s" is some salt string, and "u" is some user dependent data (for example their user ID).
Sure, but that's not the problem I'm trying to solve.Apollo wrote:Keep in mind that session hijacking is still a risk, and depends on client side security (i.e. your visitor's). This wouldn't mean someone could ever read the actual session data, let alone extract anything useful from it if you apply hashing, but someone could still steal the session ID and impersonate another visitor. Including the visitor's IP in the "u" string above may help against this (at the trade-off of forcing people to re-login if they change location).
Let's say you create an account on my website, and it's a private youtube variant. You want to show your brother the new video of your cat but he groans about having to make an account. You trust him, so you give him your username and password to login. Now a week later, you find out that he is using your account to post his homemade *naughty* video's to your account. So you login and change your password.
In the example above, if my site doesn't check some sort of credentials with each page request, he still has all the time that is left within his authentication window to upload videos, because we'd only be checking that he is authenticated via user_id or some other true/false switch. What is the best way to verify that the account credentials have not changed between page requests, without storing them?
Thanks for your feedback so far!
Re: Ok to store password hash in session data?
There should be no reason to store the password in the session. If the entire reason is to be able to kill other logins as you, simply provide that functionality.
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
- flying_circus
- Forum Regular
- Posts: 732
- Joined: Wed Mar 05, 2008 10:23 pm
- Location: Sunriver, OR
Re: Ok to store password hash in session data?
The password will never be stored in the session, we are talking about the password hash, used only for comparative purposepickle wrote:There should be no reason to store the password in the session.
ex: if($_SESSION['password_hash'] === $password_hash_stored_in_database) { // Great Success! }
Can you finish this thought? I am interested in what you have to say.pickle wrote:If the entire reason is to be able to kill other logins as you, simply provide that functionality.
I am not looking for a code example, just a thought process on how you would handle this problem. It is inefficient to parse through every session stored on my server to determine if that session is tied to a specific user. who's password has just been reset. The light bulb above my head is still dim...
Re: Ok to store password hash in session data?
What you could do is store the most recent session ID with the username. When someone logs in, update that record with the person's session ID. Then, on each page load, check if the user's session ID matches the session stored with that username. If not, the user gets booted.
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
- flying_circus
- Forum Regular
- Posts: 732
- Joined: Wed Mar 05, 2008 10:23 pm
- Location: Sunriver, OR
Re: Ok to store password hash in session data?
Sure, but that means only 1 session can be logged in per user account, which may or may not be desirable.
In situations, like this message board, it is often helpful for me to type a reply in 1 window as I browse the thread in another. Right now I am logged in under both IE and Chrome. Other situations may be a joint account between husband and wife, or a generic "guest" account where you give the user basic credentials to access a semi-private area.
I could create a linkage table linking session id's to user id's, but then on password change, if I wiped the table, I would log out the user who just changed their password. It also seems a bit convoluted?
I understand the rule of thumb is not to store credentials in a session and I agree with it. However, why is it wrong to store the hash if the credentials/ingredients are not present?
In situations, like this message board, it is often helpful for me to type a reply in 1 window as I browse the thread in another. Right now I am logged in under both IE and Chrome. Other situations may be a joint account between husband and wife, or a generic "guest" account where you give the user basic credentials to access a semi-private area.
I could create a linkage table linking session id's to user id's, but then on password change, if I wiped the table, I would log out the user who just changed their password. It also seems a bit convoluted?
I understand the rule of thumb is not to store credentials in a session and I agree with it. However, why is it wrong to store the hash if the credentials/ingredients are not present?
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Ok to store password hash in session data?
I always store the session information under a key for each part of the app. That allows multiple logins per site. So $_SESSION['forum'] hold that login info, and $_SESSION['blog'] holds separate info.flying_circus wrote:Sure, but that means only 1 session can be logged in per user account, which may or may not be desirable.
(#10850)
- flying_circus
- Forum Regular
- Posts: 732
- Joined: Wed Mar 05, 2008 10:23 pm
- Location: Sunriver, OR
Re: Ok to store password hash in session data?
Hi Christopher,Christopher wrote:I always store the session information under a key for each part of the app. That allows multiple logins per site. So $_SESSION['forum'] hold that login info, and $_SESSION['blog'] holds separate info.flying_circus wrote:Sure, but that means only 1 session can be logged in per user account, which may or may not be desirable.
I've been thinking about it and I understand what you are saying (I think), but I'm having trouble connecting the dots. I too, like to organize my session data like you suggest.
I am talking about a user account system where there may legitimately 2 or more people logged in at the same time, overlap, using the same set of credentials. Are we talking about the same thing? Probably the best example would be the guest account that I talked about above.
Anyways, side-stepping the whole best design aspect, has there been a compelling argument on why you shouldnt store the password hash in the session data?
- getmizanur
- Forum Commoner
- Posts: 71
- Joined: Sun Sep 06, 2009 12:28 pm
Re: Ok to store password hash in session data?
why do you not use php acl classes such as zend_acl, tackle and phpgacl
- flying_circus
- Forum Regular
- Posts: 732
- Joined: Wed Mar 05, 2008 10:23 pm
- Location: Sunriver, OR
Re: Ok to store password hash in session data?
Hi,getmizanur wrote:why do you not use php acl classes such as zend_acl, tackle and phpgacl
Thanks for your reply. Can you please provide a brief synopsis of how zend_acl, tackle, or phpgacl would solve the problem I have asked about?
Re: Ok to store password hash in session data?
(Late reply)
In this case however, the original password isn't there in the first place (the original password should not be stored anywhere, ever). So the "p" in my post above is all you have at this point. Since you don't want to leak this "p" value, but you still want to be able to verify it, hashing it along with a salt + pepper seems to best way to go. It's not like anyone could spoof custom session data and brute force hash values or something, theoretically benefiting from the lesser entropy of double hashing (which is still completely insignificant if you use proper hashing and long salt + pepper).
Well, yes, double hashing is generally not to be recommended. At least not in the sense of hash(hash(something)) supposedly being more secure than hash(something), which it isn't.flying_circus wrote:Isn't this a poor security practice, double hashing? I was of the opinion that there was no security gain and I'd be reducing the entropy, not to mention making the cpu work harder, thoughts?Apollo wrote:Nonetheless it couldn't hurt to put an extra hashing step on the session data. For example, what you could store in the session data is: hash(p.s.u) where "hash" is a strong hash algorithm, "p" is the password hash which is stored in your database, "s" is some salt string, and "u" is some user dependent data (for example their user ID).
In this case however, the original password isn't there in the first place (the original password should not be stored anywhere, ever). So the "p" in my post above is all you have at this point. Since you don't want to leak this "p" value, but you still want to be able to verify it, hashing it along with a salt + pepper seems to best way to go. It's not like anyone could spoof custom session data and brute force hash values or something, theoretically benefiting from the lesser entropy of double hashing (which is still completely insignificant if you use proper hashing and long salt + pepper).
Well that's one thing that is taken care of by the hashing I described. You should have a function GenerateLoginHash or something which generates the hash(passwordhash.salt.pepper) thing. Upon a successful login (or password change), you store this in the user's session data. At every members-only page access, you call that same function and compare its result to the current value from the session data. If not equal, redirect to login.Let's say you create an account on my website, and it's a private youtube variant. You want to show your brother the new video of your cat but he groans about having to make an account. You trust him, so you give him your username and password to login. Now a week later, you find out that he is using your account to post his homemade *naughty* video's to your account. So you login and change your password.
In the example above, if my site doesn't check some sort of credentials with each page request, he still has all the time that is left within his authentication window to upload videos, because we'd only be checking that he is authenticated via user_id or some other true/false switch. What is the best way to verify that the account credentials have not changed between page requests, without storing them?
Re: Ok to store password hash in session data?
My thoughts briefly are:
1. Marginally session and database are the same thing from the point of how securely you can access them - both are (ideally) under your control only (bar theoretical issues with shared hosting which you either have or don't have so you know if it applies to you beforehand). The crucial difference is in the data lifetime, since one is more volatile than the other. 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.
2. That said, I don't see why you would need such thing at all.
1. Marginally session and database are the same thing from the point of how securely you can access them - both are (ideally) under your control only (bar theoretical issues with shared hosting which you either have or don't have so you know if it applies to you beforehand). The crucial difference is in the data lifetime, since one is more volatile than the other. 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.
2. That said, I don't see why you would need such thing at all.
- flying_circus
- Forum Regular
- Posts: 732
- Joined: Wed Mar 05, 2008 10:23 pm
- Location: Sunriver, OR
Re: Ok to store password hash in session data?
Mordred, I appreciate your thoughts. If I may:
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?
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.Mordred wrote:The crucial difference is in the data lifetime, since one is more volatile than the other.
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?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.
I'm interested in alternative solutions not yet suggested.Mordred wrote:2. That said, I don't see why you would need such thing at all.
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?