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

121–126 of 126 posts

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

#121

Post by brey »

bad_user wrote: post #107
ohyes wrote: post #69

Earlier quoted context omitted.

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,…

immutable fields are probably recommended for salts ... I quite like being able to change my email address on a site ;-)

but yes, a hashed (global + immutable-user-specific) combination seems to be best practice.

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

#122

Post by eru »

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.…

> 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.

Quantum computing does not help with exponential problems in general.

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

#123

Post by maratd »

throwaway64 wrote: post #102
maratd wrote: post #34

Earlier quoted context omitted.

> 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.

You are making assumptions that are unwarranted. There are other uses for MD5 besides data integrity and data security. For instance, I generate an MD5 hash of a user's email address and use that hash for Gravatar. While someone who knows quite a bit about MD5 and the other person's email address, can force a collision ... all that would get him would be the other person's avatar image ... which is public anyway. In other words, using MD5 is perfectly fine in situations where collisions don't pose a serious problem.

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

#124

Post by nobody3141592 »

asharp wrote: post #104
nobody3141592 wrote: post #41

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"

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

I think the record is just under 1Billion hashes/sec on a couple of NVidia Tesla cards linked by SLI.

You need a fairly expensive SAN to pull 1Billion MD5 hashes/second just from the raw disk - nevermind the DB lookup.

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

#125

Post by peterwwillis »

throwaway64 wrote: post #99
peterwwillis wrote: post #56

Earlier quoted context omitted.

A question on the practicality of expensive compute time for password hashes: If somebody got read-level access to your password hashes, it follows (based purely on the assumption that any app with the rights to read the hash will probably have the right to change it when applicable) that one could simply overwrite the password hash with a new one that is already known, gain unauthorized access, and change the hash b…

security is about defense in depth, and doing as much as is feasible to mitigate damage. Proper password hashing wont protect you from a break in on a primary system, but it could very easily prevent a break in on secondary ones. Also, a note to anyone reading the above post, that is not how bcrypt works and is incredibly insecure.

What is not how bcrypt works? The example that I gave? That comes from the 'crypt' man page explaining how to use blowfish encryption patched into libcrypt?

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

#126

Post by stan_rogers »

Dylan16807 wrote: post #90
stan_rogers wrote: post #77

Earlier quoted context omitted.

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 m…

With the technique under discussion (using Google to search for the MD5 hash), it doesn't really matter what the computational cost of finding a plaintext for the every possible hash value is -- you're not brute forcing a collision, you're doing a search using someone else's enormous resources. That's always going to be O(1) from your point of view (with a lot of overhead, of course).
Post reply on HN