Page 1 of 2

updating stored md5()'d hashes

Posted: Thu Jun 01, 2006 12:33 am
by s.dot
So, my entire userbase is stored with md5()d passwords. I would like to update these to something a bit more secure; as I've read of recent vulnerabilities with md5.

Obviously, I would love to use feyd's SHA256 class. But I don't want to require everyone to log in again, as some people only check it like once every few months.. and that would be an inconvenience of someone comes to log in and their password not work. So, storing the sha256'd hash and then converting after a bunch of people have logged in would preferrably not be an option.

What i was thinking is something along the lines of this

Code: Select all

$salt = md5('abunchofgarglygoooooforasaltstring');

$newPass = $currentPass.$salt
This would give me a 64 character string for a password (same as sha256) that could easily be checked against. And would give me the option to change the salt string and update the database pretty easily

Code: Select all

$newSalt = md5('newsaltstring');
$currPass = substr($database['pass'],0,32);
$newPass = $currPass.$newSalt
What do you guys think of doing this? Do you suggest a better way?

Re: updating stored md5()'d hashes

Posted: Thu Jun 01, 2006 2:51 am
by someberry
The way which imediatly springs to mind is:

1) Create a column called 'is_sha'.
2) Let the users log in normally.
3) Check the users 'is_sha' is 1 or 0
4) if 1, then the user has sha'd their password, so do nothing more.
5)if 0, then overwrite their password with the sha'd version of their actual password, and then set the 'is_sha' column to 1.

Seems the most logical to me.

Posted: Thu Jun 01, 2006 3:08 pm
by s.dot
that is not a very bad idea, although it does use more system resources checking if they have the sha hash set, or the md5. that also leaves old md5()d hashed passwords vulnerable and an inbalanced login system.. I dont' really want to go the route of having two different validation methods.

I will go that route though if other users on this board think the security of it is better than the inconvenience of the extra overhead vs the method I mentioned.

I'm looking forward to more input

[PS: reading this topic over again makes me sound like i don't know english well :lol: I do, I promise. Just having a hard time explaining what's in my head!]

Posted: Thu Jun 01, 2006 3:10 pm
by hawleyjr

Posted: Thu Jun 01, 2006 3:33 pm
by Roja
scottayy wrote:that is not a very bad idea, although it does use more system resources checking if they have the sha hash set, or the md5.
That check (a single select, that in fact could be part of the select grabbing the username or password that already occurs) is simple, and should not add ANY noticable impact to your system resources.
scottayy wrote:that also leaves old md5()d hashed passwords vulnerable and an inbalanced login system.. I dont' really want to go the route of having two different validation methods.
Its a win and a loss. Its a win because the password hash isn't entirely predictable - it could be either md5 or sha, and in some ways, thats better. It increases the possibilities.

Its a loss because there are some accounts that are using weaker security. But guess what? You already use that weaker security for ALL accounts, so switching some users is a net improvement both during, and especially after.
scottayy wrote:I will go that route though if other users on this board think the security of it is better than the inconvenience of the extra overhead vs the method I mentioned.
The method you proposed is a bit misleading. You use the term salt, but salting requires that the salt is MIXED IN, during the hashing process. By appending text onto a password, its not a salt at all. Especially since its completely consistent, both across multiple accounts, and over time. Thats not adding randomness - its adding predictability, so its actually WEAKENING your security.

Use the suggested method to switch people to SHA256, and once they are all transitioned, then you can use a real salt system to make it even MORE secure. ie, do $superhash = SHA256( $hash . $salt);

Posted: Fri Jun 02, 2006 3:42 am
by Syranide
How about just thinking in terms of what is useful instead?
Is it useful to switch from MD5? ... No, not really.

Why you say? Well, if they get the MD5s (or whatever) you are screwed either way.
That's still the point of the MD5, it is secure as long as no one gets the MD5.
If someone gets the MD5, well they could spend a lot of time generating useless garbage with the same hash, and the fact still remains, if they got the MD5s, well, then they prolly got your entire site too and can do whatever they want.

The only real problem that arose with MD5 when it got "easier" to "break" is pretty much only signatures, or when MD5 hashes are sent over the public networks, as they could then be "reversed" to generate garbage with the same hash and it would look legit. But, hashing locally is not affected more than in the case of the entire database leaking, and then it doesn't matter, because whatever they do, your salted hashes are of no use to them, since they cannot used to get their real passwords. It would only apply to your site which has already been compromised.

Posted: Fri Jun 02, 2006 4:13 am
by Maugrim_The_Reaper
How about just thinking in terms of what is useful instead?
Is it useful to switch from MD5? ... No, not really.

Why you say? Well, if they get the MD5s (or whatever) you are screwed either way.
That's still the point of the MD5, it is secure as long as no one gets the MD5.
If someone gets the MD5, well they could spend a lot of time generating useless garbage with the same hash, and the fact still remains, if they got the MD5s, well, then they prolly got your entire site too and can do whatever they want.
You're thinking on too local a level. Users inevtiably restrict the number of passwords they remember to a handful - reusing each on multiple websites. If one password is cracked, then its cracked on many sites. We're protecting users here - not the local website. Also you ignore the risk of someone accessing the database without hacking the local server - could be a security exploit in the application, or an insecure database password, or a configuration file with liberal permissions, or...

Posted: Fri Jun 02, 2006 5:02 am
by Syranide
Maugrim_The_Reaper wrote:You're thinking on too local a level. Users inevtiably restrict the number of passwords they remember to a handful - reusing each on multiple websites. If one password is cracked, then its cracked on many sites. We're protecting users here - not the local website. Also you ignore the risk of someone accessing the database without hacking the local server - could be a security exploit in the application, or an insecure database password, or a configuration file with liberal permissions, or...
That's exactly what I'm not doing, you should always salt the hashes so such cannot happen, and then it becomes local, as the generated garbage hash would only be specific to your salt and not reusable for other sites.

Well of course, the httpserver might not be hacked too, but seeing that they can do enough damage anyway as they have access to the database, if the passwords are MD5 or not, "cracked" or not, doesn't matter, because obviously, to be safe all must enter new passwords.

I agree that there is no negative side to changing from MD5 to something "not-yet-cracked", but existing solutions for internal password verifications shouldn't care too much, except for adding something as stated above where all new passwords are SHA and the olds are kept.

Posted: Fri Jun 02, 2006 6:09 am
by Maugrim_The_Reaper
That's exactly what I'm not doing, you should always salt the hashes so such cannot happen, and then it becomes local, as the generated garbage hash would only be specific to your salt and not reusable for other sites.
You originally quoted "then they prolly got your entire site too and can do whatever they want.", in which case any salt is likely compromised... And the hashes are still following a predictable pattern to which the hacker has all the keys (and just needs an MD5 lookup library).

None of this is changing the fact that using SHA256 over SHA1 or MD5 is a large improvement in security terms.
I agree that there is no negative side to changing from MD5 to something "not-yet-cracked"
There's no negative side - it's a positive: a reduction in password security risk.

Posted: Fri Jun 02, 2006 6:51 am
by Syranide
Well, there is a negative side too if you force the conversion to the users, as he apparently doesn't want that, and I agree. I'm trying to look at it from a "solution" perspective, not the common "linux guru hacker" thinks that RSA512 is too weak as it can be cracked in a thousand years and it must be uncrackable, that would be great, but not neccesary nor very "development time-smart" either.

As far as you say, they follow a pattern, no they don't really, that's the point, and that is why it is still hard to crack them, it has just been made faster, it has not been cracked. MD5lookup library you say? 40^64 (or more) possible MD5-hashes.... well, doesn't sound very likely to me, not for the public. 2^32 rings a bell as being over 4 billion, and well, 40^64 is according to the unprecise calculator 3.4E102 ... which would mean well, over ~2E91 TB of MD5 records... something tells me that is more than all drives in the entire world summed up and squared. The only MD5 lookup libraries that exist to my knowledge only work for common words.

But regardless, no, even if they know the salt, it doesn't matter, because the salt is "disolved" when you hash, so "Hello|SaltA|World" and "Hello|SaltB|World" on two different sites cannot be used to hack the other if you know the salt and hash.

So cracking the hash is NOT equal to the password, it is only equal to garbage with the same hash = you don't get the password, and the garbage has the salt in it. Therefore, your password is not compromised, not even the access to the server is compromised as the password is already salted, and when you enter the garbage password, it will get salted again and fail the test. So even if you know the salt it doesn't matter, because you cannot "subtract" the salt from the garbage or hash.

I do not exclude the possibility of being able to generate garbage for a specific salt and hash that would generate the correct hash after being salted, but it still doesn't become a problem as the password is still protected for other servers, since their salt IN CASE OF THIS BEING POSSIBLE is not known, nor would the garbage likely pass being applied a salt on another server even if their salt was known.

Understand that I am not against changing to another algorithm, I'm merely trying to point out that there is no need to rush it, they cannot hack your site any easier now than before. If you want get real security, get a longer password for the database instead and run it on secure dedicated server.

Posted: Fri Jun 02, 2006 8:08 am
by Roja
Syranide wrote:Well, there is a negative side too if you force the conversion to the users, as he apparently doesn't want that, and I agree.
For the user, if implemented properly, its transparent. With md5, they enter their password, and they are granted access. During the transition, they enter their password, and they are granted access. After.. you get the idea. Its identical, and transparent to the user.
Syranide wrote:As far as you say, they follow a pattern, no they don't really, that's the point, and that is why it is still hard to crack them, it has just been made faster, it has not been cracked. MD5lookup library you say? 40^64 (or more) possible MD5-hashes.... well, doesn't sound very likely to me, not for the public. 2^32 rings a bell as being over 4 billion, and well, 40^64 is according to the unprecise calculator 3.4E102 ... which would mean well, over ~2E91 TB of MD5 records... something tells me that is more than all drives in the entire world summed up and squared. The only MD5 lookup libraries that exist to my knowledge only work for common words.
Wow, talk about a huge amount of inaccuracies.

1. There are massive md5 rainbow tables - and they are not at all only for common words. In fact L0phtcrack5 ships with a set of DVDs containing *every* 8-character alphanumeric combination (upper and lowercase!). That would cover the vast majority of passwords in active use on most websites. There are also multiple online versions with larger or comparable sized lookup tables. The lookup libraries are not limited to common words.

2. The breaks to MD5 are substantial, and serious. Instead of 4 billion+ possibilities, with the latest tunneling attack, you can find an MD5 hash in minutes on a 1ghz laptop. MD5 is no longer cryptographically secure against brute force attacks.
Syranide wrote:But regardless, no, even if they know the salt, it doesn't matter, because the salt is "disolved" when you hash, so "Hello|SaltA|World" and "Hello|SaltB|World" on two different sites cannot be used to hack the other if you know the salt and hash.
Thats more accurate, but still not "dead on". While the salt adds to the entropy, and as such isn't a correlated predictive function, it *can* reduce the attack time. The math required to show this is far beyond the scope of these forums, but having the salt, and multiple hashes can substantially decrease the time to attack.

(But yes, the salt is dissolved, and its value is arguably less than critical).
Syranide wrote:So cracking the hash is NOT equal to the password, it is only equal to garbage with the same hash = you don't get the password, and the garbage has the salt in it. Therefore, your password is not compromised, not even the access to the server is compromised as the password is already salted, and when you enter the garbage password, it will get salted again and fail the test. So even if you know the salt it doesn't matter, because you cannot "subtract" the salt from the garbage or hash.
Knowing the salt means you can once again use lookup tables (build your own, or otherwise). The purpose of salts is to prevent lookup tables, and to add entropy. If the salt is compromised, there is less entropy, period. Its more predictable.
Syranide wrote:I do not exclude the possibility of being able to generate garbage for a specific salt and hash that would generate the correct hash after being salted, but it still doesn't become a problem as the password is still protected for other servers, since their salt IN CASE OF THIS BEING POSSIBLE is not known, nor would the garbage likely pass being applied a salt on another server even if their salt was known.
Once you have the salt, and can use a rainbow table to do the lookup, then you compromise the underlying password. With the password, other sites using other salts wont matter - because you have the password, and they can add their salt, and you will gain access.
Syranide wrote:Understand that I am not against changing to another algorithm, I'm merely trying to point out that there is no need to rush it, they cannot hack your site any easier now than before. If you want get real security, get a longer password for the database instead and run it on secure dedicated server.
Actually, you DID argue that you don't agree with changing to another algoritm at the beginning of your post.

Further, you tried to support that argument by saying that md5 is no less secure than it was previously, which is provably false. It has suffered tremendous, crippling compromises, and the latest findings bring the time to compromise down to a laughably trivial amount of time on common hardware. Thats the definition of it being easier for them to hack your site easier now than before.

Before you continue on your repeated attacks, I highly suggest you read the latest papers on attacks on md5. You are misinformed, and you are confusing a simple issue.

Posted: Fri Jun 02, 2006 8:16 am
by Maugrim_The_Reaper
Well, there is a negative side too if you force the conversion to the users, as he apparently doesn't want that, and I agree. I'm trying to look at it from a "solution" perspective, not the common "linux guru hacker" thinks that RSA512 is too weak as it can be cracked in a thousand years and it must be uncrackable, that would be great, but not neccesary nor very "development time-smart" either.
There is no conversion "forced" on users - it's done transparently server side and the user is completely ignorant of any change... The "linux guru hacker" approach is used successfully all the time. It's also a worthless claim. MD5 is far less secure than SHA256, hence it's easier to create a collision, hence it creates a security risk, hence it's logical to find a more secure alternative. MD5 by itself is far less secure than a year or so ago. If we followed your thinking we'd all still be using MD4 or worse.
As far as you say, they follow a pattern, no they don't really, that's the point, and that is why it is still hard to crack them, it has just been made faster, it has not been cracked. MD5lookup library you say? 40^64 (or more) possible MD5-hashes.... well, doesn't sound very likely to me, not for the public. 2^32 rings a bell as being over 4 billion, and well, 40^64 is according to the unprecise calculator 3.4E102 ... which would mean well, over ~2E91 TB of MD5 records... something tells me that is more than all drives in the entire world summed up and squared. The only MD5 lookup libraries that exist to my knowledge only work for common words.
You can still look them up though, right? :) Hardly a ignorable risk...
But regardless, no, even if they know the salt, it doesn't matter, because the salt is "disolved" when you hash, so "Hello|SaltA|World" and "Hello|SaltB|World" on two different sites cannot be used to hack the other if you know the salt and hash.
I agree - but the discovered salt isn't a help to the local users since it's globally applied to all accounts... Salting, is of course a great practice to have if everyone used it.
So cracking the hash is NOT equal to the password, it is only equal to garbage with the same hash = you don't get the password, and the garbage has the salt in it.
With a salt, yes. Without a salt, no. Are we still arguing the same topic anymore?
Understand that I am not against changing to another algorithm, I'm merely trying to point out that there is no need to rush it, they cannot hack your site any easier now than before. If you want get real security, get a longer password for the database instead and run it on secure dedicated server.
Why not rush it? And bearing in mind I thought we were talking about hashes sans salts. Is there an implementation problem other than having to switch the stored password hashes on the database? Is there a performance hit? Will it drive off users? Where's the negative of the approach? I'm seeing a net gain overall - an improved security measure mitigating the application's security risk.

Re: updating stored md5()'d hashes

Posted: Fri Jun 02, 2006 12:55 pm
by RobertGonzalez
Sorry to seem like a twit here, but the original post didn't seem like an invitation to debate the MD5 vs. SHA256 issue. Scottayy was asking how he could go about updating his users passwords top a more secure version of the stored data.
scottayy wrote:So, my entire userbase is stored with md5()d passwords. I would like to update these to something a bit more secure; as I've read of recent vulnerabilities with md5.

Obviously, I would love to use feyd's SHA256 class. But I don't want to require everyone to log in again, as some people only check it like once every few months.. and that would be an inconvenience of someone comes to log in and their password not work. So, storing the sha256'd hash and then converting after a bunch of people have logged in would preferrably not be an option.

What i was thinking is something along the lines of this

Code: Select all

$salt = md5('abunchofgarglygoooooforasaltstring');

$newPass = $currentPass.$salt
This would give me a 64 character string for a password (same as sha256) that could easily be checked against. And would give me the option to change the salt string and update the database pretty easily

Code: Select all

$newSalt = md5('newsaltstring');
$currPass = substr($database['pass'],0,32);
$newPass = $currPass.$newSalt
What do you guys think of doing this? Do you suggest a better way?
Here's my suggestion...

Your current data is a 32 character string since it is an MD5 hash, correct? The new password data, using your method of hashing above, would be a 64 character string. Just do a str_len check to see if the user has updated their password, and if not, update it to the newer hash. They would never be any the wiser and the only check would take place using something you are using anyway when pulling their user_data from the database.

Just a thought....

Posted: Fri Jun 02, 2006 4:38 pm
by Maugrim_The_Reaper
Sorry to seem like a twit here, but the original post didn't seem like an invitation to debate the MD5 vs. SHA256 issue. Scottayy was asking how he could go about updating his users passwords top a more secure version of the stored data.
Not seeming like a twit...:). I helped hijack the thread unfortunately...

Your solution knocks out any additional database changes other than increasing length of the password field. Neat.

Posted: Fri Jun 02, 2006 5:06 pm
by RobertGonzalez
It seemed like a practical thing to do. And simple too.

Thanks, by the way. I feel useful now. 8O