4 ms·
> use hashing for password storage As opposed to...?
by stephenr 9y ago
> use hashing for password storage
As opposed to...?
- CiPHPerCoder 9y agoI assume they meant the use of a cryptographic hash function (which is wrong) instead of a password hash function (which, as the name implies, is suitable for password storage). For example, I see a lot of this construction in proprietary code: $passwordHash = md5(md5($password) . md5($salt)); if ($storedHash == $passwordHash) { // Authenticated successfully } I'm quick to find these offending snippets and migrate our clients to use password_hash() and password_verify().
- duskwuff 9y agoOr, for that matter... SELECT * FROM user WHERE username = '$username' AND password_hash = MD5('$password')
- chx 9y agoSurely not after all these years! Does this easy SQL injection still exist...?
- zaphar 9y agoIf you only knew the horrors I've seen. This week no less...
- bitexploder 9y agoYes. Even in places where people use prepared statement and things like LINQ to build queries, somewhere someone will end up wanting or needing a query that is hard to express so they will start string building a raw SQL query and forget or not know to use prepared statements. We see this /all/ the time on our assessment of our customer's software. It is markedly less common, but still quite common, if not pervasive like it used to be. PHP apps are dramatically more likely to have security vulnerabilities of any sort. It is a running joke we have that one of our recommendations to remediate security issues with PHP is to "rewrite in a different language". For whatever reason PHP has a history of encouraging vulnerable code. Even in good shops. PHP itself isn't really to blame (it is, of course much less likely for an experienced shop to write crappy PHP... but they probably wouldn't pick PHP to begin with).
- duskwuff 9y agoWhat deserves a lot of the blame is the awful mysql_* API, which didn't support query placeholders. (The mysqli and PDO APIs weren't available until much later, and weren't reliably available on many web hosts for even longer.) This forced PHP developers to become comfortable with constructing SQL queries as strings -- a habit which proved hard to break for many of them.
- deleted 9y ago[deleted]
- yjftsjthsd-h 9y agoPerhaps no salt?
- owenmarshall 9y agoSalts don't save you from an attacker who can calculate millions of hashes per second on a GPU. Using bcrypt/scrypt/Argon2id does.
- TheRealPomax 9y agoSalt is not intended to save you, just to make unhashing the next user's password just as much work as the one you just cracked.
- wongarsu 9y agoSalting is incredibly effective. Without salting, the entire power of the attacker can be used against all password hashes at once. With salting, those millions of hashes per second translates to only being able to crack simple passwords, or only the passwords of a few users.
- tedunangst 9y agoExcept in the case of MD5, it's billions, many billions, of hashes per second, which translates to cracking lots of users' passwords.
- aruggirello 9y agoPHP has had a dedicated password hashing function since version 5.5: it's password_hash(). But at least, if you want to roll your own password hashing, do it right: use hmac, salting, stretching and a decent hash function - or use bcrypt/scrypt and save yourself a few headaches.
- stephenr 9y agoI'm well aware of that. The original comment suggested that password hashing is bad, I was trying to identify what the poster thought should be used instead.
- idlewords 9y agoEvergreen: https://codahale.com/how-to-safely-store-a-password/ https://codahale.com/how-to-safely-store-a-password/
- deleted 9y ago[deleted]