5 ms·

Couldn't all clients always do a larger amount of iterations and not let that number be configurable at all?

by aflag 4y ago

silverwind 4y ago
Clients could dynamically determine a value based on performance. That way, the encyption gets more secure the better the hardware gets.
- runnerup 4y ago
  How would the server know what the hash is? So you log in with your phone and its 5,000 iterations, then you log in with your desktop and it's 500,000 iterations? Then you get an updated driver for your GPU and it fixes a performance bug and now its 550,000 iterations...how the fuck would the server know what the matching hash should be that it never got sent to it? It sounds like the server would have to store the lowest possible hash (your phone), which defeats the purpose of the larger iterations on the desktop machine.
  - aflag 4y ago
    Couldn't the client send the number?
    - runnerup 4y ago
      Yes but the server has to have something stored. If the data stored was last encrypted with a hash that has fewer iterations then the client side, then 1) the data cannot be decrypted with a hash of more iterations because the server can’t undo client side hash iterations. 2) if the encrypted data is exfiltrated it will still be as easy to crack as the iterations performed for the original encryption of the data at last login ten years ago.
runnerup 4y ago
No, because today you pick a number of iterations that takes some "long but reasonable" amount of time. Maybe that's 2 seconds, maybe that's 2 minutes...but it's the longest your customers will put up with waiting at login. Then 10 years from now, CPU's will have sped up a LOT so that will only take 0.2 seconds or whatever. With normal users, you could update the # of iterations every year, but that requires a login to occur so that the "new" password hash can be sent by the client. With a user who only logs in every 10 years, you have to support the # of iterations that existed when the user last logged in.

Couldn't all clients always do a larger amount of iterations and not let that number be configurable at all?

by aflag 4y ago

Couldn't all clients always do a larger amount of iterations and not let that number be configurable at all?

Clients could dynamically determine a value based on performance. That way, the encyption gets more secure the better the hardware gets.

runnerup 4y ago
How would the server know what the hash is? So you log in with your phone and its 5,000 iterations, then you log in with your desktop and it's 500,000 iterations? Then you get an updated driver for your GPU and it fixes a performance bug and now its 550,000 iterations...how the fuck would the server know what the matching hash should be that it never got sent to it? It sounds like the server would have to store the lowest possible hash (your phone), which defeats the purpose of the larger iterations on the desktop machine.
- aflag 4y ago
  Couldn't the client send the number?
  - runnerup 4y ago
    Yes but the server has to have something stored. If the data stored was last encrypted with a hash that has fewer iterations then the client side, then 1) the data cannot be decrypted with a hash of more iterations because the server can’t undo client side hash iterations. 2) if the encrypted data is exfiltrated it will still be as easy to crack as the iterations performed for the original encryption of the data at last login ten years ago.

runnerup 4y ago

No, because today you pick a number of iterations that takes some "long but reasonable" amount of time. Maybe that's 2 seconds, maybe that's 2 minutes...but it's the longest your customers will put up with waiting at login. Then 10 years from now, CPU's will have sped up a LOT so that will only take 0.2 seconds or whatever. With normal users, you could update the # of iterations every year, but that requires a login to occur so that the "new" password hash can be sent by the client. With a user who only logs in every 10 years, you have to support the # of iterations that existed when the user last logged in.