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

[Daniel0]

[jackpf]

Your actual name is suffixed with a 0? Cool.

[Xeoncross]

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

 

lol, if you can call that an ad (ads should sell something). You missed all the good discussion, but we are still looking for new and better algorithms and ideas for (portable) hashing.

[corbin]

This is gonna sound kinda dreary, but as far as I know, none of us are cryptographers, so I doubt any of us are going to have any epiphanies about encryption/hashing methods/techniques.

 

 

I guess we could introduce each other to well known things that each other may not know though.

[jackpf]

Yeah.

However...I don't think hashing is really that critical to a website's security. Like what 448191  said, if someone's got access to your database you're pretty buggered anyway.

[Daniel0]

Getting the password hash doesn't necessarily equate to having root access to the database server. It could have been through an SQL injection where you got it to dump the password hash.

[jackpf]

That's true...

But as long as you escape everything, you're pretty safe from that.

[Daniel0]

That ultimately boils down to "as long as you've secured it properly, you are secure", which is not really a good argument.

[jackpf]

Lol true.

But what I'm trying to say is that I don't think hashing is as vital as people on this thread suggest it is.

If you use a sha1() or md5(), possibly with salt, combined with some common sense you're pretty safe from most attacks.

[dbo]

Wow, I'm getting no love on this thread. We've got 448191 calling me corbin. We've got jackpf saying "just like 448191 said"

 

I believe I started the thread with, security in layers.... if you have your database compromised you have bigger issues anyways.... nothing is impossible to crack, etc.

 

I guess I'm the suck and you don't believe me! Or... maybe I'm not really here. Is this thing on?

[jackpf]

Getting the password hash doesn't necessarily equate to having root access to the database server. It could have been through an SQL injection where you got it to dump the password hash.

 

As Daniel0 pointed out, the mysql server doesn't neccessarily have to be owned in order to download databases

 

But yeah, you're right about security in layers.

[moon 111]

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.

 

That's why I'm not so sure about studying Cryptography. With that kind of security already in place, what's the point?

 

Back on topic, though, assuming you use SHA-1 or MD5 or one of the others out there you should be sage. It is ridiculous to try to make an attack take 3 years instead of 5 months (as you mentioned earlier) if you have a regular website. When your in charge of security at a bank or hospital, give us a call.

 

Although this research is fascinating (no sarcasm), if you're so worried it would probably make more sense just to force a password change every 3 months (or have a random one) every three months, and change the hashing algorithm, too. I'm pretty sure this would work, and it would save you a lot of hassle.

[448191]

That ultimately boils down to "as long as you've secured it properly, you are secure", which is not really a good argument.

 

Why not, it's an ultimate truth. Perhaps lies make better arguments, or perhaps saying truth is a lie is closer to the truth.

 

But, to further derail this thread, when was the last time you were concerned with, or discovered reason for concerns of SQL injection concerning something you wrote, not counting crappy CMSes (very concerning all these concerns)?

 

Btw, this is a pretty interesting thread, but it's missing something. You know who would be great to have in on this discussion? dbo. Maybe someone should PM him or something to point him to this thread.

[Daniel0]

But, to further derail this thread, when was the last time you were concerned with, or discovered reason for concerns of SQL injection concerning something you wrote, not counting crappy CMSes (very concerning all these concerns)?

 

I don't know about you, but I always write my code under the assumption that it works (if I knew it didn't work then I wouldn't have released it). As Seneca said, "errare humanum est", and considering I'm a human it would be reasonable to expect that I could have made a mistake somewhere. If we for a moment imagine that I never do err, then say for instance I decided to write some sort of application. We could take an open source forum system as an example. Seeing as my code was perfect, there would be no security vulnerabilities. However, because this product will have many deployments that are not under my control, it is impossible to ascertain the security of the server it is running on. Moreover, because this is open source, people would likely write and distribute plugins and/or modifications. These people might not be perfect like me, so they may err, or create security vulnerabilities if you wish.

 

We presupposed that nobody would be able to get to the raw database in the first place, so that in fact makes hashing the password (with or without salting techniques) completely redundant; if no unauthorized person ever sees it, then there is nobody to protect it from. A security problem consists of three entities: 1) an asset, 2) an attacker, and 3) a vulnerability. If you remove any of them then you have no problem. If there is nothing of interest, then nobody will try to get it. If there is nobody to get your asset then nobody to protect from. If there is no vulnerability then there is no way for the attacker to get to the asset. Because we presupposed that #3 didn't exist, it would have been wasteful to implement additional security measures.

 

In light of the circumstances our aforementioned open source application runs under, there can be potential security issues, so we have all three entities in play. Had the hashing not been done then whoever got a dump of the database would have a list of passwords. Had I used hashing it would be slightly more difficult, but looking over some of the most popular passwords, all of them would be easily cracked using dictionary attacks or rainbow tables. Most non-tech savvy users do not have insight in proper password policies so their passwords are pretty weak. As an attacker, knowing that you could probably get a good deal of plaintext passwords out of a dumped table that's just hashed. Using a salt you get additional benefits. The string will be too large to make brute-forcing feasible, and it'll make sure the string doesn't exist in a dictionary. Rainbow table attacks would be unlikely as well. A larger password combination range would require a larger rainbow tables. The size of a such rainbow table would increase exponentially. For a mixed case alphanumerical password, the number of combinations would be 62ⁿ where n is the password length. If we suppose that the average password has a length of 6 chars and your salt is 32 that would be a 38 string long input to the hashing algorithm. To even list all those passwords you would need 62³⁶ byte ≈ 1.29*10⁶⁸ byte = 1.29*10⁴⁰ YB. That rainbow table will not exist (well, maybe on DreamHost's servers because they have infinite space).

 

As I see it, salting makes it considerably more difficult to get to the plaintext password. You cannot make it impossible to break in, but you can make it increasingly difficult to break in. The more time and resources it will take, the more valuable an asset you must have, but even then there is a limit on how many resources and how much time the attacker can and will use on breaking in.

 

That ultimately boils down to "as long as you've secured it properly, you are secure", which is not really a good argument.

 

Why not, it's an ultimate truth. Perhaps lies make better arguments, or perhaps saying truth is a lie is closer to the truth.

 

Essentially because it can support neither side of the argument. You can reverse it to say "as long as you've not secured it properly, you are not secure", or in other words if P => Q then ¬P => ¬Q (proof by contrapositive). So if "as long as you've secured it properly, you are secure" (1) is true, which it is because it's a tautology, then that also makes "as long as you've not secured it properly, you are not secure" (2) true. So if (1) supports one side of the argument, then (2) must support the other side. That makes it useless in a debate context because it indirectly supports the other side of the argument as well

[corbin]

Wow, I'm getting no love on this thread. We've got 448191 calling me corbin. We've got jackpf saying "just like 448191 said"

 

 

Everyone is out to steal your thunder.  lol.

[DarkWater]

To even list all those passwords you would need 6236 byte ≈ 1.29*1068 byte = 1.29*1040 YB. That rainbow table will not exist (well, maybe on DreamHost's servers because they have infinite space).

 

That DreamHost comment made my day.  =P  I remember when you had that whole conversation with one of the tech reps from DreamHost and posted it.

[jackpf]

Yeah, I read your blog about that. Found it pretty funny.

[corbin]

Infinite harddrive space would own.

[jackpf]

Yeah. I laughed at how the first guy he emailed obviously thought he was retarded asking where to buy a hard disk with infinite capacity, possibly not realising that's what his company was advertising.