4 ms·

eh, as someone who rolls my own login systems and depends on checking salted password hashes against those in a database: Assuming I block brutes after 3 or 4 a

eh, as someone who rolls my own login systems and depends on checking salted password hashes against those in a database: Assuming I block brutes after 3 or 4 attempts, is there anything I need to worry about here besides someone getting access to the database or the salt? I think your point was that people building logins off one way hashes aren't really doing anything outrageously wrong?

tptacek 2y ago
I mean to start with if you are literally using "salted hashes" you are boned. There's a whole literature of "password hashes" ("password KDFs"), and that literature exists for a reason; the papers are a record of the weaknesses found in "salted hashes", a construction dating back to the late 1970s. But once you adopt something like BCrypt or scrypt or PBKDF2 or Argon2 (literally throw a dart at a dartboard), you're into the space of things where you should, as a competent engineer, be expected to figure out a sound system on your own. The only domain-specific knowledge you really need given to you by a cryptographer is "don't just use salted hashes".
- pclmulqdq 2y ago
  Incidentally, a presentation at the NIST crypto reading group recently pointed out some of the weaknesses of current password KDFs: Argon2i has a viable attack, bcrypt truncates input, PBKDF2 needs an utterly insane number of rounds, and scrypt and argon2d/argon2id have data-dependent computation time and seem to be vulnerable to side-channel attacks. It turns out this is a really hard problem.
  - soatok 2y ago
    I wasn't present for the NIST crypto reading group, but I documented a lot of these in 2022, if you'd like a deeper dive into that problem space: https://soatok.blog/2022/12/29/what-we-do-in-the-etc-shadow-cryptography-with-passwords/ https://soatok.blog/2022/12/29/what-we-do-in-the-etc-shadow-...
  - tptacek 2y ago
    None of which are material compared to someone using a salted hash.
    - lelanthran 2y ago
      I'm still in the dark about the problem with storing a salted hash, assuming a decent hash function and a decently long random salt. Simply replying "everyone knows what the problem is and has know since the 70s" is not as helpful as "here is the problem in three sentences". You can assume a base level of knowledge in your answer, as I have worked in encryption for a little bit, having written the 3DES implementation for some firmware, and done EMV development.
      - eadmund 2y ago
        The very short version is that decent hash functions are very, very fast, take almost no storage to compute and can thus easily be run in parallel. If you store `(,salt ,(HMAC-SHA2-256 salt password)) in your database and it leaks, an attacker can check hundreds of millions of possible passwords every second. The password ‘open sesame’ will get found pretty early, but so will ‘0p3n#s3s4m3$’. Pretty much anything which is not of the form ‘62Jm1QyJKGIZUpb5zARRLM’ will get found pretty quickly. You want something that is slow and takes a lot of resources to run. PBKDF2 was an early attempt which uses lots and lots of CPU, but it doesn’t use a lot of space. scrypt, bcrypt and Argon2 use lots of CPU and also lots of space in an attempt to make it more expensive to run (which is the point: you want the expected cost of finding a password to be more than the expected value of knowing that password). That’s one level of issue. The next level of issue is that when you run a simple system like that the user shares his password with you for you to check that it’s valid. This sounds find: you trust yourself, right? But you really shouldn’t: you make mistakes, after all. An you may have employees who make mistakes or who are malicious. They might log the password the user sent. They might steal the user’s password. Better systems use a challenge-response protocol in which you issue a one-time challenge to the user, the user performs some operation on the challenge and then responds with a proof that he knows his secret. But those have their own issues! And then there are issues with online systems and timing attacks and more. It’s a very difficult problem, and it all matters what you are protecting and what your threat model is.
- tialaramex 2y ago
  Mostly, here in 2025 the question is: "Why are you using shared secrets?" - which is why this discussion comes up. These are never about a PAKE or the PIN for a Yubikey or something, it's always shared secrets when people say "passwords". This is a terrible stopgap solution, in 1975 it's reasonable to say we have other priorities right now, we'll get to that later. But it's very silly that in 2025 you're telling people to try PBKDF2 when really they shouldn't even be in this mess in the first place. Remember when Unix login still hadn't solved this? 1995. That was last century. And yet, here we are, still people are writing "Password" prompts and thinking they're doing a good job.
  - deleted 2y ago
    [deleted]
- derangedHorse 2y ago
  By salted hashes, I'm pretty sure OP meant using something like bcrypt or PBKDF2
  - noduerme 2y ago
    Thanks, yes, using bcrypt. Usually just with something like PHP's password_hash() and the default algorithm. I sort of expected to trigger people with my post, and it's enlightening, but I feel pretty safe with what I'm doing. I mean, I like to know exactly how everything in my engine works. But there's a point at which I can't get paid to reinvent the wheel anymore, nor do I want to try.
shkkmo 2y ago
You'll want to look at your hashing algorithm and number of iterations to make sure they are up to snuff and you'll want to make sure that your salts are unique and properly random. (I recently learned that the PS3 private keys were reversible because Sony's random number function returned a fixed result.) Proper password hashing is protecting against a different threat than blocking brute force login attempts (which isn't really an encryption issue.) Password hashing is more about protecting your user's passwords if your database is breached so that you limit the attackers ability to re-user those credentials to access other services the user may have re-used them with.

tptacek 2y ago

I mean to start with if you are literally using "salted hashes" you are boned. There's a whole literature of "password hashes" ("password KDFs"), and that literature exists for a reason; the papers are a record of the weaknesses found in "salted hashes", a construction dating back to the late 1970s. But once you adopt something like BCrypt or scrypt or PBKDF2 or Argon2 (literally throw a dart at a dartboard), you're into the space of things where you should, as a competent engineer, be expected to figure out a sound system on your own. The only domain-specific knowledge you really need given to you by a cryptographer is "don't just use salted hashes".

pclmulqdq 2y ago
Incidentally, a presentation at the NIST crypto reading group recently pointed out some of the weaknesses of current password KDFs: Argon2i has a viable attack, bcrypt truncates input, PBKDF2 needs an utterly insane number of rounds, and scrypt and argon2d/argon2id have data-dependent computation time and seem to be vulnerable to side-channel attacks. It turns out this is a really hard problem.
- soatok 2y ago
  I wasn't present for the NIST crypto reading group, but I documented a lot of these in 2022, if you'd like a deeper dive into that problem space: https://soatok.blog/2022/12/29/what-we-do-in-the-etc-shadow-cryptography-with-passwords/ https://soatok.blog/2022/12/29/what-we-do-in-the-etc-shadow-...
- tptacek 2y ago
  None of which are material compared to someone using a salted hash.
  - lelanthran 2y ago
    I'm still in the dark about the problem with storing a salted hash, assuming a decent hash function and a decently long random salt. Simply replying "everyone knows what the problem is and has know since the 70s" is not as helpful as "here is the problem in three sentences". You can assume a base level of knowledge in your answer, as I have worked in encryption for a little bit, having written the 3DES implementation for some firmware, and done EMV development.
    - eadmund 2y ago
      The very short version is that decent hash functions are very, very fast, take almost no storage to compute and can thus easily be run in parallel. If you store `(,salt ,(HMAC-SHA2-256 salt password)) in your database and it leaks, an attacker can check hundreds of millions of possible passwords every second. The password ‘open sesame’ will get found pretty early, but so will ‘0p3n#s3s4m3$’. Pretty much anything which is not of the form ‘62Jm1QyJKGIZUpb5zARRLM’ will get found pretty quickly. You want something that is slow and takes a lot of resources to run. PBKDF2 was an early attempt which uses lots and lots of CPU, but it doesn’t use a lot of space. scrypt, bcrypt and Argon2 use lots of CPU and also lots of space in an attempt to make it more expensive to run (which is the point: you want the expected cost of finding a password to be more than the expected value of knowing that password). That’s one level of issue. The next level of issue is that when you run a simple system like that the user shares his password with you for you to check that it’s valid. This sounds find: you trust yourself, right? But you really shouldn’t: you make mistakes, after all. An you may have employees who make mistakes or who are malicious. They might log the password the user sent. They might steal the user’s password. Better systems use a challenge-response protocol in which you issue a one-time challenge to the user, the user performs some operation on the challenge and then responds with a proof that he knows his secret. But those have their own issues! And then there are issues with online systems and timing attacks and more. It’s a very difficult problem, and it all matters what you are protecting and what your threat model is.
tialaramex 2y ago
Mostly, here in 2025 the question is: "Why are you using shared secrets?" - which is why this discussion comes up. These are never about a PAKE or the PIN for a Yubikey or something, it's always shared secrets when people say "passwords". This is a terrible stopgap solution, in 1975 it's reasonable to say we have other priorities right now, we'll get to that later. But it's very silly that in 2025 you're telling people to try PBKDF2 when really they shouldn't even be in this mess in the first place. Remember when Unix login still hadn't solved this? 1995. That was last century. And yet, here we are, still people are writing "Password" prompts and thinking they're doing a good job.
- deleted 2y ago
  [deleted]
derangedHorse 2y ago
By salted hashes, I'm pretty sure OP meant using something like bcrypt or PBKDF2
- noduerme 2y ago
  Thanks, yes, using bcrypt. Usually just with something like PHP's password_hash() and the default algorithm. I sort of expected to trigger people with my post, and it's enlightening, but I feel pretty safe with what I'm doing. I mean, I like to know exactly how everything in my engine works. But there's a point at which I can't get paid to reinvent the wheel anymore, nor do I want to try.

shkkmo 2y ago

You'll want to look at your hashing algorithm and number of iterations to make sure they are up to snuff and you'll want to make sure that your salts are unique and properly random. (I recently learned that the PS3 private keys were reversible because Sony's random number function returned a fixed result.) Proper password hashing is protecting against a different threat than blocking brute force login attempts (which isn't really an encryption issue.) Password hashing is more about protecting your user's passwords if your database is breached so that you limit the attackers ability to re-user those credentials to access other services the user may have re-used them with.