4 ms·

The problem with expensive KDF on the server is that you are opening yourself to a higher risk of DoS. More computationally intensive KDF - higher protection ag

The problem with expensive KDF on the server is that you are opening yourself to a higher risk of DoS. More computationally intensive KDF - higher protection against crackers, but easier for someone to DoS you. Better approaches: 1) Let the client do expensive KDF (e.g. in JavaScript if it's a web app) and send you only the resulting key. You can then store SHA256(key) instead of KDF(password, salt). 2) Use public keys. This requires some fancy infrastructure like a keychains, keybase.io, PGP software etc, but it is the most secure solution. User saves only his public key on the server and signs authentication token when he wants to get in. Server has absolutely no secret material to leak, while the user has complete control over safety of his keys. This is how SSH works. The reason it is not widely used on the web is because we don't yet have nice infrastructure: nice UI for keychains and protocols for one-click sign-in via crypto signatures. We all should work on this to make it better for our kids ;-)

mschuster91 13y ago
> 1) Let the client do expensive KDF (e.g. in JavaScript if it's a web app) and send you only the resulting key. You can then store SHA256(key) instead of KDF(password, salt). So $hacker has to simply do a rainbow-table attack... no security gained there, except for a vastly bigger key space.
- crusso 13y ago
  The reason for his suggestion was to prevent an expensive hashing algo from being a means for creating a DOS, not to make the rainbow table attack any harder... although if you offload an even more expensive operation to the client than you were going to perform on the server, it does make the attack harder.
  - jessaustin 13y ago
    Except an attacker wouldn't have to perform that expensive operation: she could just iterate over the range of the KDF. Unless there were rate-limiting!
    - taejo 13y ago
      Getting them to iterate over the range of the KDF is enough, isn't it?
      - jessaustin 13y ago
        Well I guess if the range is large enough it might not be feasible. But the hypothetical system is not rate-limiting (if it were, doing the KDF server-side wouldn't be a big deal), and it is not storing an individual salt, so time is the only thing standing in the way of this attack.
        taejo 13y ago
        Time is the only thing standing in the way of any attack (well, time and memory, I guess)
  - oleganza 13y ago
    I assume that key was generated through an expensive KDF with a proper salt and is at least 32 bytes long. So "rainbow table attack" is out of question here. That's why I said sha256(key), not sha256(key + salt).
- taejo 13y ago
  The vastly bigger key space is all you need to make the rainbow-table attack completely beyond the realm of possibility (isn't it?)
matthewmacleod 13y ago
Neither of these is a better option, in my opinion, because the complexity of setting them up and ensuring security far outweighs the risk of a DoS attack on your infrastructure. It's relatively trivial to rate-limit access to particular endpoints if you are particularly concerned about DoS attacks, which means you've got a simpler system overall – an simplicity in security is reaaaaaallly worth it!
tptacek 13y ago
People have been "worrying" about DoS attacks from password hashes for years. Strangely, they haven't become an issue in practice. My presumption is that this is because if you're going to launch an application-level denial of service attack against a particular application, it is already trivial to come up with one regardless of how you store passwords.
- oleganza 13y ago
  People haven't ever deployed reaaaally hardcore KDFs on their servers yet. I myself would like my password stretched with >100 Mb of memory and taking about a second on 8 threads. This kind of setup might be too expensive for a shared server.
  - tptacek 13y ago
    The whole point of adaptive KDFs is that you can set them wherever you'd like, so it's always going to be possible to take one of them and give it an unreasonable parameter. But you're not seeing anyone credibly advocating that anyone do that in the real world.
NateDad 13y ago
If someone can DoS your login api, they can do it to another api. Rate limit it. It's not hard. It's actually even easier because people login so rarely, you can really ratchet down the rate and not mess up the casual user's experience.

mschuster91 13y ago

> 1) Let the client do expensive KDF (e.g. in JavaScript if it's a web app) and send you only the resulting key. You can then store SHA256(key) instead of KDF(password, salt). So $hacker has to simply do a rainbow-table attack... no security gained there, except for a vastly bigger key space.

crusso 13y ago
The reason for his suggestion was to prevent an expensive hashing algo from being a means for creating a DOS, not to make the rainbow table attack any harder... although if you offload an even more expensive operation to the client than you were going to perform on the server, it does make the attack harder.
- jessaustin 13y ago
  Except an attacker wouldn't have to perform that expensive operation: she could just iterate over the range of the KDF. Unless there were rate-limiting!
  - taejo 13y ago
    Getting them to iterate over the range of the KDF is enough, isn't it?
    - jessaustin 13y ago
      Well I guess if the range is large enough it might not be feasible. But the hypothetical system is not rate-limiting (if it were, doing the KDF server-side wouldn't be a big deal), and it is not storing an individual salt, so time is the only thing standing in the way of this attack.
      - taejo 13y ago
        Time is the only thing standing in the way of any attack (well, time and memory, I guess)
- oleganza 13y ago
  I assume that key was generated through an expensive KDF with a proper salt and is at least 32 bytes long. So "rainbow table attack" is out of question here. That's why I said sha256(key), not sha256(key + salt).
taejo 13y ago
The vastly bigger key space is all you need to make the rainbow-table attack completely beyond the realm of possibility (isn't it?)

matthewmacleod 13y ago

Neither of these is a better option, in my opinion, because the complexity of setting them up and ensuring security far outweighs the risk of a DoS attack on your infrastructure. It's relatively trivial to rate-limit access to particular endpoints if you are particularly concerned about DoS attacks, which means you've got a simpler system overall – an simplicity in security is reaaaaaallly worth it!

tptacek 13y ago

People have been "worrying" about DoS attacks from password hashes for years. Strangely, they haven't become an issue in practice. My presumption is that this is because if you're going to launch an application-level denial of service attack against a particular application, it is already trivial to come up with one regardless of how you store passwords.

oleganza 13y ago
People haven't ever deployed reaaaally hardcore KDFs on their servers yet. I myself would like my password stretched with >100 Mb of memory and taking about a second on 8 threads. This kind of setup might be too expensive for a shared server.
- tptacek 13y ago
  The whole point of adaptive KDFs is that you can set them wherever you'd like, so it's always going to be possible to take one of them and give it an unreasonable parameter. But you're not seeing anyone credibly advocating that anyone do that in the real world.

NateDad 13y ago

If someone can DoS your login api, they can do it to another api. Rate limit it. It's not hard. It's actually even easier because people login so rarely, you can really ratchet down the rate and not mess up the casual user's experience.