back
5 comments
Little Jimmy Tables strikes again.
I believe Bobby Tables is the more well known name: https://xkcd.com/327/
Must have been changed via SQL injection
upvote
What? I said I'd upvoted the parent comment because I thought it was funny and I get downvoted? Wtf, sometimes I just don't get HN :-/
HN is not reddit. Comments should meaningfully add to the conversation. In this case your comment is just adding noise for people to scroll past.
I'm in a vortex of downvotes, would expect this to go the same. Ho hum.

Thanks, I guess. Whoops, more noise.

You're correct, I mis-quoted, but I'm strangely happy about that given the context :-)
I thought bcrypt had built in salts, how was he able to reverse those hashes for simple passwords? Any better algorithm to use or recommendation on salting?
The salts are typically stored together with the data, as is the case here. So, if you want to see if the first password is 'password', you salt it with the first salt and hash it with bcrypt. If the result matches, you know with a huge degree of confidence[0] that indeed the first password was 'password'. You can easily do this for the entire dataset, and for a few more common passwords.

[0] of course, there is a chance that you just discovered a hash collision, but that is exceedingly unlikely. It also means that Gab would have accepted 'password' as the password for that user anyway, even if the string they typed in was 'warblerer' (which it would also accept).

> [0] of course, there is a chance that you just discovered a hash collision, but that is exceedingly unlikely. It also means that Gab would have accepted 'password' as the password for that user anyway, even if the string they typed in was 'warblerer' (which it would also accept).

I don't think password policy enforcement can be reasonably done after the hashing. You cannot apply password rules as information about length and specific characters is lost; applying a blacklist would also be exceedingly expensive as you'd need to hash each word in your list with the selected salt.

I don't understand how your comment relates to what you are quoting.

Password policy enforcement is done on the plain text password, during initial account creation or during a password change workflow. Then, the password and salt are hashed and the result and the salt are stored.

When the user tries to login they then provide the plaintext password; the salt is retrieved, it is added to the password, the result is hashed, and the hash is compared to the stored hash.

Since the space of all passwords is larger than the space of all hashes, there is a theoretical possibility that the user can provide a different password than the original plaintext, and this new plaintext + the salt happens to have the same hash, so the login system (which has no idea what the original plaintext was) will accept it.

With any halfway decent cryptographic hashing function this is less likely than winning every lottery in the world at once with the same ticket.

Let's assume that the Gab user used a long and complicated password, that happened to hash-collide with "password". How do you know that Gab would have accepted "password" as a password? All we know is that it accepted the long and complicated one.

This is obviously moot, as a collision is exceedingly unlikely in this case, but still.

Salts have virtually nothing to do with the security of password hashes. Unix password hashes have essentially always be salted; they're cracked with dictionary generators, not with rainbow tables.
As you know (but others might not) salts aren't (just) for stopping rainbow tables. They also mean that two users picking the same password doesn't result in identical hashes. That's often a more meaningful protection than stopping rainbow tables.
Some people like to add "pepper" in addition to salt. Salt would be a unique value that's combined with each password. Pepper is a global secret combined with the unique salt, that is not stored near the passwords (e.g. stored in a config file). The idea being in an sql injection, you can typically dump the entire db but not config files or anything else. Of course if they totally take over your server you are still just as screwed, and if you have sql injections you likely have other vulns too.

https://en.m.wikipedia.org/wiki/Pepper_(cryptography)

If the password is on a short enough list, you can afford to check each hash separately with the salt.
> Any better algorithm to use or recommendation on salting? Check for common passwords:

https://haveibeenpwned.com/API/v3#SearchingPwnedPasswordsByR...

> Any better algorithm to use or recommendation on salting?

The only thing that works are better passwords. But in theory Argon2 should be a bit better than bcrypt.

Everybody can guess your password if it's 12345678
It’s funny, if a site requires a special character ,number, and capital requirement, those people will now have Password1! instead. Much more secure.
drop table fash;
A tale as old as time itself.
Niiiiice