Which hash to use? [SOLVED]
Moderator: General Moderators
Which hash to use? [SOLVED]
I'm trying to organise my thoughs on my sites authentication/security system and so I am looking around to see a few different approaches. Alot of it is conflicting, and most of it biased or incomplete.
As time goes on and the more that I look the more confused I am about hashing values for cookie storage. Most examples use md5, but I've stumbled across references that say md5 is no longer secure.
So I think, thats fine, I'll use sha1, only to look around and find mention that it is no longer secure either.
So now I'm at a loss. Are these security issues overblown, or it it searously worth considering? And how does one sha-256?
Cheers.
As time goes on and the more that I look the more confused I am about hashing values for cookie storage. Most examples use md5, but I've stumbled across references that say md5 is no longer secure.
So I think, thats fine, I'll use sha1, only to look around and find mention that it is no longer secure either.
So now I'm at a loss. Are these security issues overblown, or it it searously worth considering? And how does one sha-256?
Cheers.
Last edited by Stryks on Fri Jun 24, 2005 12:49 am, edited 1 time in total.
read this viewtopic.php?t=32334 by feyd as his is probably the master at security on this site.
Re: Which hash to use?
Correct. Its a recent finding (within the last two years), so many people haven't updated their articles to reflect the new realities. Also, there haven't been many solid sha256 implementations, so most people didn't know what to refer to.Stryks wrote: As time goes on and the more that I look the more confused I am about hashing values for cookie storage. Most examples use md5, but I've stumbled across references that say md5 is no longer secure.
That is correct.Stryks wrote: So I think, thats fine, I'll use sha1, only to look around and find mention that it is no longer secure either.
The security issues aren't overblown, but may not be serious enough for you to want to switch.Stryks wrote: So now I'm at a loss. Are these security issues overblown, or it it searously worth considering? And how does one sha-256?
In a nutshell, the findings for both md5 and sha1 have centered around duplicate messages. The idea is you send out a value - lets say for example, the latest CD image for Fedora Core 4. I want to trick someone into running my I_Owned_You_Hard CD instead. However, that someone is going to check the md5sum to ensure its complete, correct, and the same as what Fedora produced.
It is now possible to create just that - a second image with different content but with the SAME checksum. Different input, same output.
For things like CD verification and filesystem checksumming, thats pretty much "completely broken". But what about logins?
On the login side, most people use the hash as a way to transmit data without it being cleartext. So, you are sending an input into the hash (password), taking the output (hash) and transmitting that instead.
Notice there is no difference - its still a check of input v. output, and you can still produce a different input and match the output. However, and this *is* a difference that matters - the CD verification process has the hash out in the open. Its a known value. In logins, it is not.
As a result, the most fair statement is that the impact for login systems is lower than for content verification systems, but not much.
There is essentially no reason to continue using a system you know to be broken, which brings us full circle back to sha256.
Feyd's sha256 library is fantastic, and I use it in multiple apps now. "How" you use it depends on what you want to accomplish. Be specific about your goals, and I can give specific advice on how to implement it.
Wow .... Thats about all I can say about that SHA256 class. I've been looking everywhere ... I should have known that if it was going to be done and done well, it would have been someone like feyd who would have done it.
That makes the whole hashing problem go away really.
I'm still not entirely sure about the way it needs to be implemented. I'm still trying to absorb the info I have been collecting about login systems.
The hashing part comes into it when I want the site to remember a logged in user. I want to set a cookie with a user identifier (not the user's ID, a hashed unique random number) with a hashed password+expiry+fingerprint value to be compared to stored values whenever the user views a page without a current session.
The fingerprint is pretty much just a hash of the HTTP_USER_AGENT and HTTP_USER_AGENT and HTTP_ACCEPT_CHARSET values. Pretty vague, I know, but it should stop a cookie being switched to another browser. I also use the fingerprint in the session to try and catch out any hijacked sessions. I wanted to use IP's, but there are too many scenarios where this would adversley impact users, or so it would appear.
I'm a little unsure about the expiry. I guess I will need to save the expiry date in the database somewhere for comparison when the cookie is used, along with the fingerprint. I could just store the hashed full value, but that won't help me to ensure the cookie crumbles every 90 days or so.
I've read some info about one time padding, but I'm not entirely sure why this is considered a good thing. I mean, the value is used and then sent back and I can see that this proves I am talking to the person I assume I am, but I dont see how this prevents someone from stealing the cookie once it is made.
Also, I'm going to have to look into using cookies in ssl and non-ssl environments. My logins will happen in SSL, and I suppose that if the cookie is to be used, it can be redirected to an SSL page for processing if need be. Of course, I dont know if it needs to be, so I guess I'll figure that out when I come to it.
Yes, I realise I'm waffling here ... I think I may have just read too much for my own good, but I figure that if I am going for security, I might as well try to take as much into consideration as possible.
Would love to hear any feedback anyone has.
Cheers.
That makes the whole hashing problem go away really.
I'm still not entirely sure about the way it needs to be implemented. I'm still trying to absorb the info I have been collecting about login systems.
The hashing part comes into it when I want the site to remember a logged in user. I want to set a cookie with a user identifier (not the user's ID, a hashed unique random number) with a hashed password+expiry+fingerprint value to be compared to stored values whenever the user views a page without a current session.
The fingerprint is pretty much just a hash of the HTTP_USER_AGENT and HTTP_USER_AGENT and HTTP_ACCEPT_CHARSET values. Pretty vague, I know, but it should stop a cookie being switched to another browser. I also use the fingerprint in the session to try and catch out any hijacked sessions. I wanted to use IP's, but there are too many scenarios where this would adversley impact users, or so it would appear.
I'm a little unsure about the expiry. I guess I will need to save the expiry date in the database somewhere for comparison when the cookie is used, along with the fingerprint. I could just store the hashed full value, but that won't help me to ensure the cookie crumbles every 90 days or so.
I've read some info about one time padding, but I'm not entirely sure why this is considered a good thing. I mean, the value is used and then sent back and I can see that this proves I am talking to the person I assume I am, but I dont see how this prevents someone from stealing the cookie once it is made.
Also, I'm going to have to look into using cookies in ssl and non-ssl environments. My logins will happen in SSL, and I suppose that if the cookie is to be used, it can be redirected to an SSL page for processing if need be. Of course, I dont know if it needs to be, so I guess I'll figure that out when I come to it.
Yes, I realise I'm waffling here ... I think I may have just read too much for my own good, but I figure that if I am going for security, I might as well try to take as much into consideration as possible.
Would love to hear any feedback anyone has.
Cheers.
Well, no, it delays things. Researchers are saying that the problems with SHA and MD5 may also apply to other hashes by extension.. so one day even sha256 may not be secure.Stryks wrote:That makes the whole hashing problem go away really.
But for the time being, its a really solid choice.
Simple rule: If you want to be able to remember a logged in user, you are choosing to accept the risk of a session replay attack. Its a binary choice: Either its secure against replays, OR, you can remember the user.Stryks wrote:The hashing part comes into it when I want the site to remember a logged in user.
Not at all - both can be modified by the user (read: Attacker).Stryks wrote:but it should stop a cookie being switched to another browser.
Thats the one-time part that you are missing.Stryks wrote: I've read some info about one time padding, but I'm not entirely sure why this is considered a good thing. I mean, the value is used and then sent back and I can see that this proves I am talking to the person I assume I am, but I dont see how this prevents someone from stealing the cookie once it is made.
The server says (once and once only) "here is a secret code". The user responds with a secret he and the server knows - his password - HASHED with that secret code.
Because the secret code is only usable *that one time*, if a hijacker gets that session token (the hash of password + one-time pad), and replays it later, the server says "Go away". Because it doesn't match - by the time the attacker tries the replay attack, the secret code has changed.
It's nice to see that approach once in a while.Stryks wrote: Yes, I realise I'm waffling here ... I think I may have just read too much for my own good, but I figure that if I am going for security, I might as well try to take as much into consideration as possible.
Thanks for the reply, you raise some interesting points.
Now that you put the one-time-pad in perspective like that, I do get more of an idea of what it is trying to achieve. I'm not entirely sure I know how to implement it though, but I'm just about to start reading again ... maybe I'll get lucky.
I just dont get the idea of the client hashing the value and sending it back. What I mean I guess is, how does it do it. I'm sort of picturing the pad being embedded in a form, and then having javascript generate the hashed password+pad value and sending it as the password, where the server can compare it to it's own version to make sure the password was correct.
Ok, thats fine ... I can see that I have just managed to not send the password in cleartext, and the server also knows how to match it appropriately. But how does this make my session or cookie more secure. It really doesnt leave me with any means of verifying that this person is the same person who logged in originally.
I dont know really. Any expansion on a method for one-time padding would be great.
Thanks again
Now that you put the one-time-pad in perspective like that, I do get more of an idea of what it is trying to achieve. I'm not entirely sure I know how to implement it though, but I'm just about to start reading again ... maybe I'll get lucky.
I just dont get the idea of the client hashing the value and sending it back. What I mean I guess is, how does it do it. I'm sort of picturing the pad being embedded in a form, and then having javascript generate the hashed password+pad value and sending it as the password, where the server can compare it to it's own version to make sure the password was correct.
Ok, thats fine ... I can see that I have just managed to not send the password in cleartext, and the server also knows how to match it appropriately. But how does this make my session or cookie more secure. It really doesnt leave me with any means of verifying that this person is the same person who logged in originally.
I dont know really. Any expansion on a method for one-time padding would be great.
Thanks again
Thats exactly it!Stryks wrote: I just dont get the idea of the client hashing the value and sending it back. What I mean I guess is, how does it do it. I'm sort of picturing the pad being embedded in a form, and then having javascript generate the hashed password+pad value and sending it as the password, where the server can compare it to it's own version to make sure the password was correct.
On the server side (easier to express), its essentially:
Code: Select all
$one_time = mt_rand(0,100);
$combined = md5($password . $one_time);
if ($_POST['combined'] != $combined)
{
// Reject login
}Obviously you want a longer one_time hash with more randomness, but you get the idea.. Trying to be concise here.
On the client side its a bit more muddled, but yes, you send the client the $one_time, and the client sends that same combined password + one_time pad, hashed, back to the server. That requires javascript.
Which is why I said in the last reply that you have a binary choice to make between a "remember me" cookie and a secure login. If you do a one-time pad, and time-limit the sessions (say 15 minutes of inactivity), then you don't verify that this person is the same person who logged in previously - their authenticity has a (fairly) short window - it lasts for maybe an hour or so per login.Stryks wrote: But how does this make my session or cookie more secure. It really doesnt leave me with any means of verifying that this person is the same person who logged in originally.
With a remember me cookie, however, you lose most of the security. You can't reliably check again if the user is the same person who logged in previously. IP's change. User agents can be manipulated. So can accept codes. The concept behind a one-time pad is simply put "Lets limit the window for an attacker". Remember me cookies, by design, say the opposite: "Lets let a user (or attacker) stay logged in for a longtime".
If you choose to allow remember-me cookies, you choose lower security. Period. There are no reliable ways around that, as far as I know.
Okay ... I can see your point about the 'remember me' cookie. I suppose there are things that could be done to mix it up a little, but at the end of the day it's still a long term auth token which can still open up doors for whoever is determined enough to do it.
In the long run, it's probrably better to have them type their password for each login anyhow. I have accounts where I haven't typed a password for years, and I have no idea what the passwords actually are now. On the other hand, I can recall the ones I need to use often.
Still, I'm thinking that I might have a 'remember' cookie to just remember the username they used, and leave the password up to them. I suppose I could also do what I read somewhere and have a check on cookie logins where secondary authentication is required to access anything private, but really ... what is the point if the user needs to re-enter their password.
In regards to the session, do you think the one-time padding is necessary if the login occurs on an SSL secured page? I mean, it wouldnt be transmitted as cleartext under that circumstance, and I wouldn't then have to rely on javascript to do client side work.
I'm generally hesitant to make my site reliant on javascript. I do use alot of javascript, but as a rule I try to make the site usable without it.
I realise that going the SSL may be a bit on the extreme side, but as it turns out, I need the SSL area anyhow, so it's no big deal to task it for logins.
Any thoughts?
In the long run, it's probrably better to have them type their password for each login anyhow. I have accounts where I haven't typed a password for years, and I have no idea what the passwords actually are now. On the other hand, I can recall the ones I need to use often.
Still, I'm thinking that I might have a 'remember' cookie to just remember the username they used, and leave the password up to them. I suppose I could also do what I read somewhere and have a check on cookie logins where secondary authentication is required to access anything private, but really ... what is the point if the user needs to re-enter their password.
In regards to the session, do you think the one-time padding is necessary if the login occurs on an SSL secured page? I mean, it wouldnt be transmitted as cleartext under that circumstance, and I wouldn't then have to rely on javascript to do client side work.
I'm generally hesitant to make my site reliant on javascript. I do use alot of javascript, but as a rule I try to make the site usable without it.
I realise that going the SSL may be a bit on the extreme side, but as it turns out, I need the SSL area anyhow, so it's no big deal to task it for logins.
Any thoughts?
You got it.Stryks wrote:Okay ... I can see your point about the 'remember me' cookie. I suppose there are things that could be done to mix it up a little, but at the end of the day it's still a long term auth token which can still open up doors for whoever is determined enough to do it.
The important question is: What level of security do you need for the solution you are providing?Stryks wrote:In the long run, it's probrably better to have them type their password for each login anyhow. I have accounts where I haven't typed a password for years, and I have no idea what the passwords actually are now. On the other hand, I can recall the ones I need to use often.
A forum, for example, probably doesn't need to be as secure as a bank. Are you working on something commerce related, where there is a high risk, or an online forum for chatting, where the risk is low?
Both IE and Firefox 'remember' usernames if the field is correctly labeled as such. In the latest IE, it shows up as a YELLOW highlighted field.Stryks wrote:Still, I'm thinking that I might have a 'remember' cookie to just remember the username they used, and leave the password up to them.
Exactly.Stryks wrote: I suppose I could also do what I read somewhere and have a check on cookie logins where secondary authentication is required to access anything private, but really ... what is the point if the user needs to re-enter their password.
It depends on where you think the compromise will occur. If an attacker gets on my PC, for example, and sniffs my traffic, or uses a keylogger.. then SSL means nothing. (Of course, at that point, he has other avenues for attack as well)Stryks wrote:In regards to the session, do you think the one-time padding is necessary if the login occurs on an SSL secured page? I mean, it wouldnt be transmitted as cleartext under that circumstance, and I wouldn't then have to rely on javascript to do client side work.
If however, he's sitting between the server and my client - he see's nothing in SSL.
It all depends on how secure you want things to be. To me, its simple: Network is a different layer. I work on the application layer, and secure *it*. If the network layer is more secure, all the better. If not, I'm still covered.
Sounds like you have thought about the risk, and determined that SSL is sufficient for your security needs. You've chosen not to force users to use javascript, and not risk their data despite that choice. Its a logical, reasonable, and intelligent choice.Stryks wrote: I'm generally hesitant to make my site reliant on javascript. I do use alot of javascript, but as a rule I try to make the site usable without it.
I realise that going the SSL may be a bit on the extreme side, but as it turns out, I need the SSL area anyhow, so it's no big deal to task it for logins.
Any thoughts?
Every site has different needs.