What are reasonable parameters for Argon2 to hash passwords in a web application? On the one hand we need good performance, fast responses and DDoS resistance, but on the other hand we need protection from brute force on modern GPU, ASIC, FPGA etc. I see an example in Django - they use Argon2i with p=2, t=2 and 512kb of RAM, so is it enough nowadays?

Update: Basically I need to keep response time as low as possible, say 5ms for a user to hash his password. Taking into consideration theoretical throughput of RAM I can afford from 2 till 8Mb per password, so I can either spend more time doing calculations on CPU or consume more RAM with less calculations. What is the best strategy for such a case (do more CPU calculations or consume more RAM per password) to get as maximum brute force resistance as possible? The password hashing algorithm is Argon2, as it's mentioned in the title.

Update 2: Those who vote against some answers please do describe your point in comments.

  • 2
    $\begingroup$ Take your server, try these parameters and tune them such that they take as much RAM as you can (with maybe slightly higher iteration count) and only take ~100ms. $\endgroup$ – SEJPM Feb 3 '17 at 22:05
  • $\begingroup$ @SEJPM 100ms is too much because it's only 10RPS per core at best (160RPS for an average server) and besides such a response time will be painful for users (especially for mobile ones and in case of full TLS handshake). $\endgroup$ – CaptainRR Feb 3 '17 at 22:19
  • 1
    $\begingroup$ So you have already figured you want to do 160 (maybe 200?) RPS? So maybe increase the iteration count a little bit and then tune for the appropriate value by testing the values out, which would be like 5ms which is normally considered suboptimal to say the least. $\endgroup$ – SEJPM Feb 3 '17 at 22:27
  • $\begingroup$ @SEJPM Basicly I don't argue with you and I understand how to choose parameters, but I want achieve maximum performance at the lowest possible cost, so I want to learn what is the sane minimum nowadays in terms of Argon2's p,t, and m values... If I take 5ms then the memory consumption will be from 2 till 8Mb per password, so is it ok nowadays? $\endgroup$ – CaptainRR Feb 5 '17 at 18:35
  • 1
    $\begingroup$ @CaptainRR There is no standard minimum. The answer is pretty much "the maximum you're willing to tolerate". That said, I question your need to perform 160RPS for password hashing. That is nearly 10,000 unique users authenticating per minute. Facebook and Google might need to service that kind of scale of authentication requests, but it's virtually certain that you don't. If you're hashing user passwords on every request to your site, you're doing it very very wrong. $\endgroup$ – Stephen Touset Feb 6 '17 at 19:43

Only peripherally related, but consider doing somewhat expensive hashing on the client side as well as on the server, and arguably instead of on the server. This increases the costs of an attacker brute-forcing passwords, but scales better, and depending on your clients this could be viable - for example, browsers expose built-in PBKDF2 via webcrypto APIs.

  • 1
    $\begingroup$ Hmm.. but in this case mobile users will suffer from such heavy computations and the big response time problem remains unsolved.. $\endgroup$ – CaptainRR Feb 6 '17 at 19:02
  • 6
    $\begingroup$ This approach is called "server relief" by most of the password hashing competition submissions. It is necessary to prevent denial of service attacks. You need to do one last single salted hash on the server side for secure storage, otherwise you're just storing "plaintext passwords" from the perspective of an attacker. You tune the cost parameters of the client side Argon2 implementation to make user experience acceptable on the slowest devices you plan on supporting. $\endgroup$ – rmalayter Feb 10 '17 at 2:45

After some research I came up with the following solution - not to concentrate on a password hashing algorithm itself, but to apply mitigations on the overall password hashing scheme. I'd recommend the following steps:

  • define your server response KPI (for example, you can afford 20ms for password hashing per user)
  • optimize the implementation as much as possible (Runtime CPU dispatching and optimizations for different CPU instructions, like in this implemenation)
  • figure out the appropriate parameters using benchmarks
  • apply mitigations on the whole password hashing scheme level (use local parameters - algorithm secrets that are stored in app configuration and not in the database with hashed passwords, crypto anchors or state-of-the-art PO-PRF approach)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.