Live data from Hacker News

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

github.com

81–90 of 126 posts

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

#81
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"

This is where password management gets ridiculous, because you'll find a lot of registration forms limit the length of your password input to, say, 12 or 16 characters.

Why? Is it not being hashed? I have a (possibly very wrong) inkling that a longer phrase might increase the chance of collision but even so, so many places enforce a strong password but force you to keep it short.

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

#82
post #28
post #23

To the other posts saying how MD5 is not bad and/or it's stupid to use MD5 without salt (or whatever): See this script more as a fun little hack rather than a "Formal proof". Thanks aparadja for sharing. That being said, using MD5 without salt is asking for trouble. I mean, I know security is usually just a time vs $ vs quality problem, but it costs almost nothing more to add a salt in front of the password. Why not…

Using MD5 with a salt is asking for trouble. Using SHA256 with a salt is asking for trouble. Use bcrypt, scrypt, or PBKDF2. Do not DIY your password hash.

PostgreSQL does this right by supporting adaptive Blowfish hashing in their pg_crypto extension[1]. I checked to make sure since we do use pg_crypto.

1. http://www.postgresql.org/docs/current/static/pgcrypto.html

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

#83

Whenever one of these posts comes up it seems like there's a lot of comments rushing to defend salted MD5 or SHA1. What's actually wrong with bcrypt that prevents people from using it? Is it not available on all platforms? Too computationally expensive?

Integrate your email systems with Google mail or MS mail. You'll quickly find that they do not accept bcrypt. Plain md5 or plain sha1 is all they support (at least that was the case two years ago). When you are forced to inter-operate with the big guys, you'll find not many actual use bcrypt.

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

#84
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?

Microsoft Active Directory Server systems use MD4 in their central distributed credential database (ntds.dit). Yes, that's a 4, not a 5... MD4. This is the strongest storage hash that one can use in Active Directory.

Shock and horror when geeks meet the real-world. Yes, I know.

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

#85

Earlier quoted context omitted.

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"

This is where password management gets ridiculous, because you'll find a lot of registration forms limit the length of your password input to, say, 12 or 16 characters. Why? Is it not being hashed? I have a (possibly very wrong) inkling that a longer phrase might increase the chance of collision but even so, so many places enforce a strong password but force you to keep it short.

The worst offender is NVidia. They have half-a-dozen different developer logins for different bits of their site - and they all have different rules = your CUDA one must have a symbol but the parralel Nsight one must not etc

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

#87
post #16

Note to self: poison search results for md5 hashes of my passwords.

Because that way, anyone sniffing or monitoring your traffic doesn't even need to crack the systems to steal the hash, and so you'll be saving everyone some time? Edit: I'm trying to illustrate the general principle, that you shouldn't take any action thats visible outside your secure perimeter, that depends on knowledge of your password. What you define as 'outside the perimeter' depends. In the case of your corpora…

Poison over TOR?

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

#89

Earlier quoted context omitted.

In my experience, it is accurate. Google doesn't know "nicetry99", but it does know "octopus99", "octopus98", "octopus97", "hacker99", "hacker98", "hacker97" etc.

Anecdotal evidence might as well be no evidence. I'm not saying that you don't have a unique or clever idea, but it should be judged on its merits. This tool will be great for finding common passwords and variants where a system uses unsalted MD5 hashes; but it relies on known hashes, so for the vast majority of possible input strings that have no reason to be generated or indexed by Google it's ineffective.

Anecdotal evidence is perfectly fine to say 'usually' here.

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

#90

Earlier quoted context omitted.

There are 2^128 possible MD5 hashes. When it becomes impossible to increment a counter to a number, that's as good as infinite.

The point is that it's unnecessary to find the plaintext; all you need is some plaintext that produces the same hash value. It doesn't matter if your actual password is "zipobibrok5x10^8" when "fordprefect" also gets you into the system. (That, of course, only applies to a single system -- or to a cluster of systems all using something like an unsalted MD5. It would matter if you're trying to leverage a password foun…

I actually think you're missing the point here. While it is true that an infinite number of strings correspond with each md5 hash, the question was about trying to actually find a match. With a suitably large hash, say 256 bits, it becomes physically impossible to even count that high, let alone compute that many test hashes. A problem that is too large to evaluate is effectively infinite.

(Yes, md5 is 128 bits and might be possible if an entire country dedicated itself to the effort. Or an attack on its flaws could be used. But both these points are tangential to themouth's use of infinite.)

Post reply on HN