harbourlights wrote:The simpler a hash is the more chance there is of someone figuring out the original password or another combination that results in the same hash, right?
Maybe, but "simpler" is not well defined.
harbourlights wrote:So the concern isn't that they will be able to figure out your password specifically, just that they will be able to figure out a password that will work?
harbourlights wrote:See what I think I'm failing to understand is exactly what do people do with their matching hashes. Is the aim just to be able to go back to the site's interface and enter their new password in and have it work?
The concern is that they will be able to figure out the specific password used, or at least an input (preimage, or message) that will hash to the same output (hash, or message digest) as the original password.
The idea is that your database has already been compromised at this point, so the attacker has little need for the passwords of your users. However, if the attacker is able to get those passwords, he/she may be able to use them since users tend to reuse username/email and password combinations on various websites. As such, by hashing passwords for storage, you provide a secondary layer of protection for your users.
harbourlights wrote:Because they will never be able to get my original password out of that hash now that it's incomplete.
In the first place, there are many other messages that hash to the same message digest, so the attacker can never be absolutely sure that it was your original password, but he/she can be pretty confident about it. Trimming off the last 8 bits from the message digest does not make it impossible to get the original password from the hash, especially if the original password is a dictionary word. The attacker still has the same problem of trying to find the preimage given only the hash.
harbourlights wrote:But really it just increases the possibility of hash collisions.
Yes, or rather, probability. It is always possible to have hash collisions unless you have all the information beforehand and are able to create a perfect hash function, but that is not applicable here.
harbourlights wrote:But when they find a "hash collision" it won't match up with my saved hash because comparing the two will take another 2 characters off the new hash, won't it?
So the attacker just trims off the last 8 bits (as in 2 hex string characters) as well.
Basically, what you are doing is correct for a minimum level of security. Just have a user specific salt and use a cryptographic hash algorithm, and then store the salt and message digest in full. MD5 is okay for this since it is still believed to be preimage resistant (i.e., it is computationally infeasible to find the preimage given only the hash, bad passwords aside), though SHA-1 and others are likely to be even better.
