The ideal portable (but secure) method of hashing strings (passwords)

[Xeoncross]

I have been following password hashing and security for a while now, even though much of the mathematics involved far exceeds my understanding. At any rate, this topic is a request for any advanced resources (scripts/articles) you may have or know of on the topic of hashing.

 

The main problem is that MD5 and SHA1 are theoretically becoming easier and easier to break into - even with salts. When some of these algorithms came out PC's could only handle about 4 hashes a second - now PC's can create 200,000 per second. Even though many auth systems use salts, the fact is that hashing is not keeping up with computer power.

 

Personally, I would like to use phpass for my projects. Seeing the benefit, many systems like Wordpress & drupal already employ this system. However, using the high-level Blowfish-based hashing that makes the lib so useful causes non-portable hashes to be created. This is a problem for sites that keep changing hosts or use multiple servers. You can downgrade the protection that phpass provides all the way back to md5 - but then what is the point of even using it?

 

So any ideas on better security for strings without locking a site to a certain system? If you are looking for a good read you might try this.

[dbo]

Traditional hashing methods are fine when used with salts. It's the same problem that always exists... security in layers. A hash by itself is not enough protection. Instead implement some sort of policy that says if a user account has X failed attempts in X amount of time lock the account for X minues. Even if a computer can generate 200,000 hashes a second (not sure if this is true or not) it won't matter if other means are limiting the number of attempts possible.

[Xeoncross]

Yes, that is true, security should always be in layers. However, I like to take the "max-out every layer" approach so that I don't get caught when something breaks though one-too-many layers.

 

For example, the case I am most worried about is the server being compromised and a copy of the user table being downloaded. On most community sites, blogs, etc.. the only things that really matter are the PM's sent and the user data. Therefore, to guard against any kind of failure on the server level - I like to have the app level as secure as possible so that when/if the server admin fails to stop an attack I can still do my part. While I doubt if this will ever happen - that is no excuse for me to just ignore the possibly. While having a salted+hashed version of the user passwords is a start, there must be new algorithms under development right now that will make brute forcing that much harder if this event ever were to take place.

 

I doubt I will get very many answers, this topic is way over most programmers - but it never hurts to ask

[jackpf]

Well, if you encrypt with a salt, it'll take a computer like 10 billion years to decrypt or something.

 

I reckon that's pretty secure. I doubt there's anyone willing to spend 10 billion years trying to crack your database.

[Xeoncross]

Yes, especially for sites that contain non-financial data. However, this is a chance for a learning opportunity. If I can change the time it would take a PC to crack a password from 8 months to 5 years - it is worth the time it would take to learn.

 

Now take passwords that do not have a salt.

 

The multi-platform password cracker Ophcrack is incredibly fast. How fast? It can crack the password "Fgpyyih804423" in 160 seconds. Most people would consider that password fairly secure.

 

Again, assuming that this is a chance that the server is compromised - if they can access the DB - they can probably also get my config file or DB salt for use in their brute-forcing. Thereby removing the benefit of the salt.

[jackpf]

I guess...but if you keep your config files outside of your www, theorietically, noone can access them.

[Xeoncross]

lol, your database is outside your root directory too...

[dbo]

You need to come to terms with the reality. That reality is that nothing is completely unhackable. In the event that your database is compromised you have more issues on your hands than a hashed password. Given an unlimited amount of time if they want the data that bad they're going to find it.

 

So let me ask you this. Are you even talking about deploying this on a dedicated server of some sort? Because if you're talking about security in layers, and wanting to have strong hashes, blah blah blah, it's really all circumvented when you throw it out in a traditional shared hosting environment.

[dbo]

And not that I really wanted to get engaged in this goofy argument that appears to be breaking out, but...

 

If you're talking about data that truly is sensitive (most times it's not). Store your salts, etc on another server and only expose them via a webservice. Then you have 2 machines that have to be compromised....

 

 

[Xeoncross]

That's is another good idea. There are lots of things that can be done to secure sites & servers. However, this thread is specifically about better hashing algorithms for creating portable hashes. I personally would be using bcrypt if it wasn't for this problem.

 

 

[448191]

The main problem is that MD5 and SHA1 are theoretically becoming easier and easier to break into - even with salts. When some of these algorithms came out PC's could only handle about 4 hashes a second - now PC's can create 200,000 per second. Even though many auth systems use salts, the fact is that hashing is not keeping up with computer power.

 

I don't know how you came to this "fact", but I call BS.

 

The hash extension, which is part of the php core and enabled since PHP 5.1.2, gives you all the algorithms you need. I wouldn't use MD5 or SHA-0, but this extension provides you with plenty of secure alternatives. I personally have been using the SHA-256 algorithm for a long time. SHA-256 has not been compromised. Nor has ripemd160, another algorithm supported by the hash extension.

 

Even algorithms supposedly compromised/insecure are not all unsafe to use. No one has even been able to produce hash collisions using SHA-1, even after 2^63 attacks. Assuming that 200,000 attacks/s is correct, even with 100,000x that processing power, it would take ~14.6 years (2^63/(200000*100000*60*60*24*365)) to execute that number of attacks. Even though federal US agencies are advised to abandon SHA-1 before 2010, clearly this is a precautionary measure. Only TRULY MASSIVE supercomputers would be able to crack SHA-1 any time soon.

 

Other supposedly "insecure" algorithms (also supported by the hash extension) like Snefru are even more impossible to crack:

 

Although differential cryptanalysis can break the revised version with less complexity than brute force search (a certificational weakness)' date=' the attack requires 2^288.5 operations and is thus not currently feasible in practice.[/quote']

 

Again assuming that 200,000 attacks/s is correct, it would take 111510855183599901068795283559298021935242343271473288826008368655932934627 years to crack on a single machine.

 

A million machines, operating at a million times that speed, would still need 2^288.5/(200000*1000000*1000000*60*60*24*365)= ~111510855183599901068795283559298021935242343271473288826008368 years to crack this algorithm. Even if computing power would increase by a factor of a tredecillion it would still take (2^288.5)/(200000*(10^42)*(1000000*(60*60*24*365))) = ~111510855183599901068795283 years on a million machines. I think it's safe to use this algortihm for a little while.

 

"hashing is not keeping up with computer power"? I don't think so.

 

Salts are used against dictionary attacks. Like corbin suggested, such attacks should be made impossible by your application; no algorithm in itself can protect against a dictionary attack.

[Xeoncross]

Thanks for the reply 448191, that was the input I was looking for. I can always count on you to post coarse, yet very useful information.

 

As I stated before, I am not really worried about people stealing my users data - there is nothing personal there but an email. However, staying ahead of the curve is important so that you don't wake up one day behind. By the way, you wouldn't happen to know if sha256 is portable would you?

[448191]

Portable in what respect? It won't work < php 5.1.2, obviously.

 

Phpass is totally obsolete when you are running a fairly recent php build.

 

About salting. I generally don't salt. I don't see the use. Free beer and chips if you manage to convince me otherwise.

 

[Xeoncross]

Good, I'm hungry. 

 

[*]Without salting, your user enters the password "1sK2qk4o0".

[*]Someone breaks into your DB server and seals user rows (with password hashes).

[*]a local copy of something like http://project-rainbowcrack.com/ is already setup on the attackers PC with up to 9 char ([a-z][0-0]#) hashes made (56GB).

[*]Checks user_a pass hash against his DB, a couple seconds later he's found it.

 

 

VS salts

 

Rainbow tables are easy to beat. For each password, generate a random number (a nonce). Hash the password with the nonce, and store both the hash and the nonce. The server has enough information to verify passwords (the nonce is stored in the clear). But even with a small random value, say, 16 bits, rainbow tables are infeasible: there are now 65,536 “variants” of each hash, and instead of 300 billion rainbow table entries, you need quadrillions. The nonce in this scheme is called a "salt". - http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/

 

 

Oh, and when I say portable I mean that you can move the password hashes around servers and the resulting hash of a string will be the same on all servers. crypt() yields different results on different servers which is a problem when using more than one server or changing servers.

[448191]

And you'll stay like that for a little longer I'm afraid.

 

Assuming we are talking about a regular database application, what use are the passwords when the cracker already has access to the database? In other words, why would I care about passwords I can use to restrictedly read and manipulate data I already have unrestricted access to? Lets say your application does other waaaay more interesting stuff than reading and manipulating the database. If we are having this discussion under the assumption that "someone" can "break into" your database server, what's to say they can't compromise your SSH or FTP and get the salt? Or upload and download code?

[dbo]

Thanks 448191 for clarifying that I'm not crazy... and I think I'm the corbin you mentioned in a post above

[Xeoncross]

and I was hoping to eat today....  :-\

 

You are right that if they can access the DB then the attacker can mess you and your site and/or users up big time. However, the thing we are trying to protect in this instance is the user data.

 

That attacker wants desperately to get the users password because they know that at least one of the users of your site must use the same password for their bank account. With no salt there a good chance they can crack at least 40% or so of the users with simple [a-z0-9+=\$#etc..]{4,10} passwords. With a dynamic salt for each user (a nonce) then they now can no longer use the Rainbow tables for the user checks. They have to recreate the ENTIRE rainbow table database for EACH USER (user_salt + pass). What a pain. 

 

Even worse, if that salt is over 12 char/symbols long (which most passwords by themselves aren't) then they probably can't even create a DB large enough to find a match (32 char salt + 6 char pass = 38char string). Rainbow tables are 128GB by the time you reach 12chars.

 

Salting is a way of life.

[448191]

Or, I could require password of more than 10 chars and some special characters. Ok, I hate it when systems do that myself.

 

Dislike of salting comes from some peoples implementations. I've seen some ridiculously complicated salting procedures, adding no extra value. Some salt, pepper, sauce, or even salty pepper sauce. While I don't think salting will save my ass in my lifetime, and energy would be much more appropriately focussed on database server security, I'll agree to the fact that when it comes to security, it never hurts to be more careful than less.

 

Salting really is no trouble at all, as long as you don't make it uselessly complicated for the developer having to work with your app after you, I'm all for it. I'll admit that I was secretly hoping you would propose some useless salting scheme that I could bash...

 

So I changed my mind to giving a rats ass about my users' passwords being stolen after my system has already been compromised, I'll send your beer and chips by DHL. Just need your email, mail address, credit card number and CvC, bank name and phpfreaks password. Thanks in advance.

 

If there's anything I wanted to accomplish with this rant it is this: security does work in layers, and should be approached in that way. Focus on a secure database server before preventing a cracker to find plaintext passwords from your password hashes. I think way too many people are caught up by the hype of rainbow tables and the proposed insecurity of hashes, when they should be focussing on database server security.

 

If your database server gets cracked, you are already screwed, and preventing hash "cracking" is then little more than damage control.

 

 

 

[corbin]

Thanks 448191 for clarifying that I'm not crazy... and I think I'm the corbin you mentioned in a post above

 

 

Hahah I saw my name in here and was like "Omg?  When did I post in here?  My memory is getting even worse!"  Then I realized it was you ;p.

[dbo]

That's okay. I'm sure you were here in spirit!

[corbin]

Errr.... sure.

 

 

At first I thought it was a bumped thread from like a year ago about md5, sha1, rainbow tables and so on.  lol.

[448191]

You yellow people look all the same too me

[Xeoncross]

I'll admit that I was secretly hoping you would propose some useless salting scheme that I could bash...

 

Yes, you get so used to people asking dumb questions around here right? I know the same feeling...

 

I'll send your beer and chips by DHL. Just need your email, mail address, credit card number and CvC, bank name and phpfreaks password.

 

Actually, I just tested this attack example out on a much larger site and I found some users that seem to have more cash than a low-pay programmer like me - would you like their info better?

 

Focus on a secure database server before preventing a cracker to find plaintext passwords from your password hashes... If your database server gets cracked, you are already screwed, and preventing hash "cracking" is then little more than damage control.

 

This text is for all you newbies out there - one security measure isn't enough. This topic was solely about portable hashing algorithms (then salting). That should make up about 5% of your general site security check list. If you want a better start watch my video.

 

 

 

 

[Xeoncross]

and yes, it wasn't until the third yellow comment that I looked over to realize that it was two different people.

[jackpf]

If you want a better start watch my video.

Wow, this thread has turned into a cheesy ad while I've been gone...