11
$\begingroup$

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.

Improve this question
$\endgroup$
8
  • 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
    Commented Feb 3, 2017 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
    Commented Feb 3, 2017 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
    Commented Feb 3, 2017 at 22:27
  • 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
    Commented Feb 6, 2017 at 19:43
  • 1
    $\begingroup$ honestly this is a good question, especially on a web-face server the intresting point is how much % of your RAM you want to give argon to be safe but at the same time not overstraining your server and suscepting yourself to ugly DDoS attacks. $\endgroup$
    – My1
    Commented Sep 21, 2017 at 9:50

2 Answers 2

Reset to default
4
$\begingroup$

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.

Improve this answer
$\endgroup$
4
  • 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
    Commented Feb 6, 2017 at 19:02
  • 7
    $\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
    Commented Feb 10, 2017 at 2:45
  • 1
    $\begingroup$ Thanks. Note it can be complicated. See also authentication - Why is client\-side hashing of a password so uncommon? - Information Security Stack Exchange $\endgroup$
    – nealmcb
    Commented Jun 27, 2020 at 2:56
  • 1
    $\begingroup$ @nealmcb the libsodium docs have a great description of how to implement server relief effectively: libsodium.gitbook.io/doc/password_hashing#server-relief $\endgroup$
    – orip
    Commented Jun 27, 2020 at 19:02
2
$\begingroup$

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)
Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ Thanks for describing your answer. It demonstrates that anyone thinking about low-level questions like Argon2 parameters needs at some point to make sure that they have the overall architecture and high-level goals for their business in mind. It can indeed be very good to use other techniques like crypto-anchors (that is a great talk!) to harden the rest of your service. $\endgroup$
    – nealmcb
    Commented Jun 27, 2020 at 2:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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