Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I wrote BozoCrack to show why plain MD5 is a horrible way to hash passwords.

github.com

Post reply on HN
Print view View original

101–110 of 126 posts

Re: I wrote BozoCrack to show why plain MD5 is a horrible way to hash passwords.

#101

Post by throwaway64 »

bad_user wrote: post #53
JoachimSchipper wrote: post #49

Earlier quoted context omitted.

It's somewhat optimistic to assume that the adversary knows no passwords - even if you can't create a user, phishing one isn't that hard. That makes recovering the salt much easier.

Well yeah, but then you're proposing a brute force against the salt and the salt can be anything of any length. So if you're assuming a salt that can contain standard latin letters and digits and is 256 in length, that's 62^256 possible variations. Do note that I'm not saying here that MD5_HMAC doesn't have flaws, but it definitely doesn't have the same flaws as MD5, cracking it ain't easy and I can't find a referenc…

A salt will not remain secret if your hashes are compromised, its always going to be a trivial step to also grab the salts.

Re: I wrote BozoCrack to show why plain MD5 is a horrible way to hash passwords.

#102

Post by throwaway64 »

maratd wrote: post #34
Cushman wrote: post #22

Seriously? Who is still using md5? There are strong hashing libraries for like every language. Anyone reading this uses md5? Can we find these people and just let them know?

> Anyone reading this uses md5? I use MD5 all the time, just not for security.

Ultimately, data integrity is the same thing as data security. If you cannot trust your data not be detectably corrupt in the face of a malicious collision attack, you do not have data integrity. Collided data can be used to cause a DoS, to overrun buffers, any number of nasty things that arbitrary user data can cause when trusted implicitly.

Re: I wrote BozoCrack to show why plain MD5 is a horrible way to hash passwords.

#103

Post by asharp »

tptacek wrote: post #42
aparadja wrote: post #14

Earlier quoted context omitted.

Perhaps I should have written it as "unsalted MD5" instead of "plain MD5" to avoid confusion. Unsalted MD5, in my opinion, is horrible. MD5 plays it's part in the mess: it's quick to calculate, which means that anybody can churn out huge lookup databases. Missing salts make those databases universally usable.

The salt does not matter. Neither does the specific hash; you'd be just as boned using SHA256. All cryptographic hash functions are designed to be fast. The vulnerability is "not using a password hash construction", of which the best known are bcrypt and PBKDF2.

Sure it matters.

If you don't have a reasonable salt then you're vulnerable to time/space tradeoff attacks like rainbow tables/etc.

Also, in case you haven't used it. Scrypt is pretty damn awesome. It's designed to be memory hard, which makes it very hard to crack even with GPUs.

Re: I wrote BozoCrack to show why plain MD5 is a horrible way to hash passwords.

#104

Post by asharp »

nobody3141592 wrote: post #41
TillE wrote: post #20

Earlier quoted context omitted.

> huge lookup databases "Huge" being the key word here. Try searching for the md5sums of arbitrary 8-character alphanumeric passwords. You won't find many results. 62^8 is a big number.

I believe that with GPUs it's now faster to calculate possible MD5s on-the-fly than use rainbow tables. Hence the current advice is to use "alongpassphraseasyourpassword" rather than "L33$Pa55wd"

I greatly doubt that it is faster to compute on the fly then to use a rainbow table.

Re: I wrote BozoCrack to show why plain MD5 is a horrible way to hash passwords.

#105

Post by asharp »

carbocation wrote: post #8
bad_user wrote: post #7

I don't think it's demonstrating anything other than: 1) many developers don't use salts / HMAC 2) MD5 is popular 3) hashed passwords end up on Google From these 3 points I don't think it follows that MD5 is horrible. Any hashing function would have the same issues, simply because a hashing function is a mathematical function, so for any X from the domain of definition, H(X) will always have the same value, on every…

If using your own salt is all you do, you'd still be susceptible to easy statistical attacks once someone compromises your database. But, yes, they probably wouldn't be available on google.

I don't believe you understand what the salt is for.

You use a salt so that time/space tradeoff attacks are no longer viable. All you need to do is provide a few bits (say 20) of entropy to make them infeasable.

Re: I wrote BozoCrack to show why plain MD5 is a horrible way to hash passwords.

#106

Post by bad_user »

JoachimSchipper wrote: post #58
bad_user wrote: post #53

Earlier quoted context omitted.

Well yeah, but then you're proposing a brute force against the salt and the salt can be anything of any length. So if you're assuming a salt that can contain standard latin letters and digits and is 256 in length, that's 62^256 possible variations. Do note that I'm not saying here that MD5_HMAC doesn't have flaws, but it definitely doesn't have the same flaws as MD5, cracking it ain't easy and I can't find a referenc…

Where did the HMAC come from? I thought we were discussing plain MD5. And yes, a huge secret salt will help. Of course, if your source code is ever visible to anyone you'll have to lock all accounts.

Well, I thought it was assumed :) ... since salting a hash has inherent vulnerabilities if you're not doing it right and HMAC is a sane way to do it.

I really don't get this argument that since MD5 is fast to compute, that's the reason it is vulnerable. That's not true, MD5 is vulnerable for other reasons, like collision attacks are possible, preimage vulnerabilities were demonstrated, huge rainbow tables are precalculated and so on and so forth.

However, HMAC_MD5 does not have the same vulnerabilities and increasing the size of the salt increases the time of a brute force attack exponentially. 62^256 is a freakishly big number and it doesn't matter much if you divide the work by 100,000 computation units. But if that makes you feel uncomfortable, you can always increase the salt to 1000 chars.

And I simply don't buy that we have enough computation power in this world to brute force something with 62^1000 computational complexity.

Re: I wrote BozoCrack to show why plain MD5 is a horrible way to hash passwords.

#107

Post by bad_user »

ohyes wrote: post #69
JoachimSchipper wrote: post #57

Earlier quoted context omitted.

The parent to my post specified "all use the same salt".

Phishing the password from one user and recovering the salt shouldn't be useful in the first place. The parent example was only meant to show how difficult it is to recover a salt even with multiple examples of its use, not to give a real life example of password hash use. (Which was my point) That said, I don't know how you would obtain a list of hashed passwords without also getting the associated list of salts (wo…

Having the exact salt in the same database as the user data defeats the purpose of the salt.

Normally you have a global salt, somewhere in your source-code, which you combine with the per-user generated salt. It also doesn't have to be something obvious in the database (like a column named user_salt :)), you could just use something like HMAC_MD5(global_salt, email + username + joined_date) for each user.

Of course, this may seem like security by obscurity, but even in the case of SSH you keep your private key safe and as a business if you have both your database and your source-code compromised, you're fucked anyway.

Re: I wrote BozoCrack to show why plain MD5 is a horrible way to hash passwords.

#108

Post by bad_user »

throwaway64 wrote: post #100
angelbob wrote: post #95

Earlier quoted context omitted.

In this case, the salt is effectively part of the key. They know how you use the salt, sure. Just not the big arbitrary hex string that is the salt.

No it is not, because the salt is stored in a plaintext or easily reversible format somewhere , and has to be in order for authentication to work, if you are in a position to grab the hashes, it will also be trivial to grab the salts. The point of the salt is not to add some padding bits to the password. Salts should be publicly knowable without it causing a loss of security. The one and _only_ use of a salt is to pr…

But isn't the SSH private key also stored in plain text?

I mean, yeah, you could also have a password for that key, but then most people use ssh-agent because typing that key every single time is annoying, which means the password is somewhere in memory. Or you could just install a keylogger on it and wait for the user to login.

If the user's computer is compromised, a hacker could gain access to his SSH credentials. Isn't that still security by obscurity?

And if you gain access to the source-code and to the database, I'm pretty sure you'll end up in a position to modify that source-code anyway, thus finding user passwords by simply logging them somewhere.

Security is a complex topic and relying on the slowness of an algorithm like bcrypt doesn't make me feel any safer, as people can always come up with a faster bcrypt. Instead we should rely on computational complexity, because no matter what we do, unless quantum computers become a realy, there are limits to what we can compute when exponential complexity is involved.

Re: I wrote BozoCrack to show why plain MD5 is a horrible way to hash passwords.

#109

Post by lloeki »

bad_user wrote: post #108
throwaway64 wrote: post #100

Earlier quoted context omitted.

No it is not, because the salt is stored in a plaintext or easily reversible format somewhere , and has to be in order for authentication to work, if you are in a position to grab the hashes, it will also be trivial to grab the salts. The point of the salt is not to add some padding bits to the password. Salts should be publicly knowable without it causing a loss of security. The one and _only_ use of a salt is to pr…

But isn't the SSH private key also stored in plain text? I mean, yeah, you could also have a password for that key, but then most people use ssh-agent because typing that key every single time is annoying, which means the password is somewhere in memory. Or you could just install a keylogger on it and wait for the user to login. If the user's computer is compromised, a hacker could gain access to his SSH credentials.…

> But isn't the SSH private key also stored in plain text?

Not if you passphrase-protect it.

Re: I wrote BozoCrack to show why plain MD5 is a horrible way to hash passwords.

#110

Post by FlowerPower »

Cushman wrote: post #22

Seriously? Who is still using md5? There are strong hashing libraries for like every language. Anyone reading this uses md5? Can we find these people and just let them know?

Last.fm

Its in the specification, and no salt.

Post reply on HN