18 ms·

I'm no expert and a bit tired, but: Is the problem around hashing password + salt for a key just about the fact it can be brute-forced with enough recources, or

I'm no expert and a bit tired, but: Is the problem around hashing password + salt for a key just about the fact it can be brute-forced with enough recources, or did I miss something?

lilyball 2y ago
Basically, yeah. It sounds like the problem is the difficulty of cracking it scales linearly, and a ton of work has gone into figuring out how to efficiently crack it. Modern KDFs are memory-hard, which is a resource that's a lot harder/more expensive to scale than computing power.
- tialaramex 2y ago
  But as Thomas points out, this is almost certainly not a problem you should actually care about. If the user of your new Shiny Goat service used the password "ShinyGoat" then all the memory hard KDF shenanigans in the world won't help, attackers will guess "ShinyGoat", and that's correct, they're in. If another user chose a 32 random alphanumerics then it doesn't matter if you just dropped in PBKDF2 with whatever default settings because the attackers couldn't guess 32 random alphanumerics no matter what. The KDF comes into the picture only for users who've chosen aggressively mediocre passwords. Not so easy attackers will definitely guess them, not so hard that it's impossible. Users who insist their "password" must be a single English word, or who insist on memorizing their passwords and so nothing longer than six characters is acceptable. That sort of thing. The attackers can guess these passwords, but they need a lot of guesses so the KDF can make it impractical. That's just not a plausible scenario for a real world attack and therefore it should not be a focus for your attention. You should use a real KDF, but PBKDF2 is fine for this purpose, any time you spend arguing about which KDF to use or implementing a different KDF, rather than solving actual defects in your system's security is a bad trade.
  - lilyball 2y ago
    PBKDF2 is at least better than YoloPBKDF (which looks rather like PBKDF1). Besides brute-forcing, YoloPBKDF/PBKDF1 has a maximum key length (the length of the hash function output) whereas PBKDF2 can construct longer keys. PBKDF2 also uses a pseudorandom function like HMAC-SHA-1 instead of just a hash function, and I'm assuming that change was done because it strengthens the security in some fashion. In any case, if you have the choice of making "aggressively mediocre" passwords harder to crack, is there a reason not to do so?
    - tialaramex 2y ago
      > In any case, if you have the choice of making "aggressively mediocre" passwords harder to crack, is there a reason not to do so? "All features start out with minus 100 points" (Eric Gunnerson, popularized via Raymond Chen)

I'm no expert and a bit tired, but: Is the problem around hashing password + salt for a key just about the fact it can be brute-forced with enough recources, or did I miss something?

lilyball 2y ago

Basically, yeah. It sounds like the problem is the difficulty of cracking it scales linearly, and a ton of work has gone into figuring out how to efficiently crack it. Modern KDFs are memory-hard, which is a resource that's a lot harder/more expensive to scale than computing power.

tialaramex 2y ago
But as Thomas points out, this is almost certainly not a problem you should actually care about. If the user of your new Shiny Goat service used the password "ShinyGoat" then all the memory hard KDF shenanigans in the world won't help, attackers will guess "ShinyGoat", and that's correct, they're in. If another user chose a 32 random alphanumerics then it doesn't matter if you just dropped in PBKDF2 with whatever default settings because the attackers couldn't guess 32 random alphanumerics no matter what. The KDF comes into the picture only for users who've chosen aggressively mediocre passwords. Not so easy attackers will definitely guess them, not so hard that it's impossible. Users who insist their "password" must be a single English word, or who insist on memorizing their passwords and so nothing longer than six characters is acceptable. That sort of thing. The attackers can guess these passwords, but they need a lot of guesses so the KDF can make it impractical. That's just not a plausible scenario for a real world attack and therefore it should not be a focus for your attention. You should use a real KDF, but PBKDF2 is fine for this purpose, any time you spend arguing about which KDF to use or implementing a different KDF, rather than solving actual defects in your system's security is a bad trade.
- lilyball 2y ago
  PBKDF2 is at least better than YoloPBKDF (which looks rather like PBKDF1). Besides brute-forcing, YoloPBKDF/PBKDF1 has a maximum key length (the length of the hash function output) whereas PBKDF2 can construct longer keys. PBKDF2 also uses a pseudorandom function like HMAC-SHA-1 instead of just a hash function, and I'm assuming that change was done because it strengthens the security in some fashion. In any case, if you have the choice of making "aggressively mediocre" passwords harder to crack, is there a reason not to do so?
  - tialaramex 2y ago
    > In any case, if you have the choice of making "aggressively mediocre" passwords harder to crack, is there a reason not to do so? "All features start out with minus 100 points" (Eric Gunnerson, popularized via Raymond Chen)