I should say correct enough.
I should say correct enough.
(This is still awful, because then two users with the same password would have the same digest. If you know that joe@example.com has password "badpass", and jane@example.com has the same hashed password, then hers is also "badpass". So use randomly per-user salts, gang! Even better, pick a tested implementation of PBKDF2 or Argon2 and use that implementation. Don't roll your own crypto!)
But still, it's better than nothing.
Just pointing out that I have seen conditions where the article is not terribly wrong in its statement.
Things like bcrypt are nice because they take care of that for you.
Discussion from 2017: https://hashcat.net/forum/thread-6219.html
From 2018: https://security.stackexchange.com/questions/186953/cracking...
GPUs are much faster now. I doubt you’ll find many people using rainbowcrack or similar tools in 2021.
It's the same logic as applying well known target data like birthdays, anniversaries, etc.
I was talking about _reversed_ passwords, guesses that fulfill the algorithm. Bonus points if they look like names, words, etc, but even random junk might just be a pwgen password.
Wouldn't it be a pepper then?
https://en.wikipedia.org/wiki/Pepper_(cryptography)
edit: nvm, it seems the main difference is a pepper being secret.
Salts must be unique per password as far as I know? Otherwise they don't do their main goal which is to make every guess useful against only one hash. (ie: guess 'hunter2', check if any user had hunter2 as a password, but salted, you'd only be able to guess if cschneid had hunter2 since you'd be hashing hunter2-sssssaaaaallllltttt).
If right or wrong is a spectrum.
If the attacker hasn't seen the code, they won't know whether the salt is prepended, or appended, or both to the password (or if there are two salts), but the amount of computation needed to try all possible salts is roughly equivalent to the amount needed to crack a single well-chosen (unsalted) password.