4 ms·

> user passwords are saved in safe form using hash_hmac and sha256 algo with salt and pepper, all md5() passwords are deleted Wait, what? Definitely lesson not

> user passwords are saved in safe form using hash_hmac and sha256 algo with salt and pepper, all md5() passwords are deleted Wait, what? Definitely lesson not learned: - sha256 is not the proper way to store passwords, it's still vulnerable to the same attack as md5, rainbow tables, because it's a FAST algorithm (sure md5 is also poor for collisions, meaning it's worse, but practical attacks for lists of hashed passwords are rainbow tables). At least with salt+pepper it limits attack surface, but instead you should be hashing your passwords with: - `password_hash`[1] should be used instead of `hash_hmac`, with the algorithm being "PASSWORD_BCRYPT" or better[2]. This is a slow hashing method, meaning anyone trying to rainbow-table attack your passwords will have a hard time. - A common technique is not to delete old passwords, but instead to rehash them with the new algorithm. This would be useful for moving from sha256 => bcrypt, since collisions on sha256 are not practical, but if the original hash was md5 then I think it's fine to delete the md5 passwords and require a new one. Good luck to those who changed their email in 15 years though. [1] https://www.php.net/manual/en/function.password-hash.php https://www.php.net/manual/en/function.password-hash.php [2] I haven't followed the space too closely for 3-4 years, I'm not sure if bcrypt/blowfish is still the recommended algorithm or there's newer better ones

joren485 5y ago
> I'm not sure if bcrypt/blowfish is still the recommended algorithm or there's newer better ones While bcrypt is already much, much better than using MD5 or SHA256, the best practice is to use Argon2. In practice, it is more important to use a hashing algorithm that is designed for passwords (e.g. bcrypt, argon2, scrypt) than it is to choose the best one. As this breach shows, many sites are still using insecure hashes, like MD5, because it worked 15 years ago.
- brobinson 5y ago
  Which mode do you/would you use? Hybrid? I haven't had to write any password storage code since before Argon2 won the 2015 competition so I haven't gone deep on the "side channel attack vs. memory hardness" tradeoff question when picking the mode. I am curious which mode others are using.
  - joren485 5y ago
    Hybrid (Argon2id) is probably the safest bet if you are unsure. The specific modes are useful dependent on the threat model you are protecting against. Argon2i protects better against timing/side-channel attacks and Argon2d protects better against brute-forcing attacks. In my opinion, a developer should (in most cases) focus on application security instead of picking the perfect hashing algorithm, as application security is far more crucial.
  - fernovus 5y ago
    Argon2ID
woutifier 5y ago
Defense against rainbow tables is obtained via salt, not via slow hashes. A rainbow table is a space-time tradeoff (you give space, and you get time), so using a slow hash only "encourages" (for lack of me knowing a better word) creating rainbow tables. Adding long salts on the other hand requires the attacker to create an infeasible number of rainbow tables (one for each possible value of the salt).
- gwd 5y ago
  > Defense against rainbow tables is obtained via salt, not via slow hashes. And bcrypt includes stores a unique salt next to the hash for every password, making rainbow tables completely useless. https://en.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/Bcrypt
  - tialaramex 5y ago
    Nobody is saying bcrypt isn't a good choice here, they're saying that rainbow tables (and all time-space trades) are made infeasible by salt regardless of whether you're using a good password hash like bcrypt.
    - gwd 5y ago
      But both you & GGP are talking about bcrypt as though it was only a password hash. If someone says, "I'm using bcrypt", then they are using both a password hash and unique per-password salts, or they're not using bcrypt. What makes bcrypt and other such systems nice (and makes this kind of mistake basically inexcusable in 2022) is that if you're using a library or package which implements it (which you should), you don't need to think about salts; you just call GenerateFromPassword(<new_password>) and CompareHashAndPassword(<entered_password>, <stored_hash>) and forget about it. EDIT: I mean, I understand maybe why in 2006 you used md5 without salt. But a few years ago I when I tossed together my first webapp (a scheduling system for the community I'm involved in), I just googled "password hash" and immediately bcrypt came up as a recommendation; there was a package in my target programming language, so after half an hour of research and 5 minutes of programming I was done. I don't understand how the opensubtitles team, after having had their password database compromised, came up with "use sha256 without salt" instead of "use bcrypt or one of the many libraries which takes care of all of that for you".
etu 5y ago
A properly implemented use of password_hash() would also allow them to use the same field and code for different algorithms over time. What I mean is, the stored data contains which algorithms it is. So they can in their code or configuration change which algorithms to use and how many times it should hash. Then on login they can verify the password against the hash and also check if the stored hash needs to be rehashed against the current set settings, then it can create a new hash from the password the user entered on login and store that in the database. Then you get automatic hash upgrades to match the current settings of the hashing of the passwords on the site with basically no user interaction (other than the act of logging in to have the password in plain text).
mooreds 5y ago
Or how about "we moved to an open source library or third party auth provider to host all our user data. We learned we didn't want to be responsible for such a critical security area." There are lots and lots of options. Seems like they are a php shop, so even moving to any of these open source PHP server libraries[0] would have been a better move. Disclosure: I work for a third party auth provider, FusionAuth. 0: https://oauth.net/code/php/ https://oauth.net/code/php/

joren485 5y ago

> I'm not sure if bcrypt/blowfish is still the recommended algorithm or there's newer better ones While bcrypt is already much, much better than using MD5 or SHA256, the best practice is to use Argon2. In practice, it is more important to use a hashing algorithm that is designed for passwords (e.g. bcrypt, argon2, scrypt) than it is to choose the best one. As this breach shows, many sites are still using insecure hashes, like MD5, because it worked 15 years ago.

brobinson 5y ago
Which mode do you/would you use? Hybrid? I haven't had to write any password storage code since before Argon2 won the 2015 competition so I haven't gone deep on the "side channel attack vs. memory hardness" tradeoff question when picking the mode. I am curious which mode others are using.
- joren485 5y ago
  Hybrid (Argon2id) is probably the safest bet if you are unsure. The specific modes are useful dependent on the threat model you are protecting against. Argon2i protects better against timing/side-channel attacks and Argon2d protects better against brute-forcing attacks. In my opinion, a developer should (in most cases) focus on application security instead of picking the perfect hashing algorithm, as application security is far more crucial.
- fernovus 5y ago
  Argon2ID

woutifier 5y ago

Defense against rainbow tables is obtained via salt, not via slow hashes. A rainbow table is a space-time tradeoff (you give space, and you get time), so using a slow hash only "encourages" (for lack of me knowing a better word) creating rainbow tables. Adding long salts on the other hand requires the attacker to create an infeasible number of rainbow tables (one for each possible value of the salt).

gwd 5y ago
> Defense against rainbow tables is obtained via salt, not via slow hashes. And bcrypt includes stores a unique salt next to the hash for every password, making rainbow tables completely useless. https://en.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/Bcrypt
- tialaramex 5y ago
  Nobody is saying bcrypt isn't a good choice here, they're saying that rainbow tables (and all time-space trades) are made infeasible by salt regardless of whether you're using a good password hash like bcrypt.
  - gwd 5y ago
    But both you & GGP are talking about bcrypt as though it was only a password hash. If someone says, "I'm using bcrypt", then they are using both a password hash and unique per-password salts, or they're not using bcrypt. What makes bcrypt and other such systems nice (and makes this kind of mistake basically inexcusable in 2022) is that if you're using a library or package which implements it (which you should), you don't need to think about salts; you just call GenerateFromPassword(<new_password>) and CompareHashAndPassword(<entered_password>, <stored_hash>) and forget about it. EDIT: I mean, I understand maybe why in 2006 you used md5 without salt. But a few years ago I when I tossed together my first webapp (a scheduling system for the community I'm involved in), I just googled "password hash" and immediately bcrypt came up as a recommendation; there was a package in my target programming language, so after half an hour of research and 5 minutes of programming I was done. I don't understand how the opensubtitles team, after having had their password database compromised, came up with "use sha256 without salt" instead of "use bcrypt or one of the many libraries which takes care of all of that for you".

etu 5y ago

A properly implemented use of password_hash() would also allow them to use the same field and code for different algorithms over time. What I mean is, the stored data contains which algorithms it is. So they can in their code or configuration change which algorithms to use and how many times it should hash. Then on login they can verify the password against the hash and also check if the stored hash needs to be rehashed against the current set settings, then it can create a new hash from the password the user entered on login and store that in the database. Then you get automatic hash upgrades to match the current settings of the hashing of the passwords on the site with basically no user interaction (other than the act of logging in to have the password in plain text).

mooreds 5y ago

Or how about "we moved to an open source library or third party auth provider to host all our user data. We learned we didn't want to be responsible for such a critical security area." There are lots and lots of options. Seems like they are a php shop, so even moving to any of these open source PHP server libraries[0] would have been a better move. Disclosure: I work for a third party auth provider, FusionAuth. 0: https://oauth.net/code/php/ https://oauth.net/code/php/