16

First I am very bad in cryptographic algorithms.

I found online that Argon2 is more secure than SHA-512, so I used it for password hashing.

There're recommended options for Argon2:

  • Memory: 4Gb
  • Iterations: 4 or more

On my ancient server it takes a little less than infinity for 100 users... So, I've decreased options to:

  • Memory: 100Mb
  • Iterations: 3
  • Threads: 4 (if it's important)
  • Type: Argon2i (recommended for password hashes)
  • Salt size: 20 bytes

These options are significantly lower than options that I found as recommended. So I was wondering...

Will Argon2 with my options still be more secure than SHA-512? Or should I switch back to SHA-512?

P.S. If my question is not clear, text me, plz, I will try to reformulate it

Improve this question
6
  • @EsaJokinen so, does it mean that even with my options Argon2 is still better than SHA-512? It still works slower than SHA-512
    – Denis Steinman
    Commented May 11, 2022 at 6:09
  • @EsaJokinen thank you for explanation
    – Denis Steinman
    Commented May 11, 2022 at 6:17
  • 2
    Changing the salt size won't change the time it takes, as far as I'm aware, so I'd leave that as whatever the recommended one was.
    – rydwolf
    Commented May 11, 2022 at 12:50
  • 4
    as a suggestion: please have a look at bcrypt where you can have both salt and computation factor customized.
    – Kerim Oguzcan Yenidunya
    Commented May 11, 2022 at 14:17
  • 4
    You should be using Argon2id, not Argon2i.
    – forest
    Commented May 13, 2022 at 1:54

3 Answers 3

Reset to default
23

Argon2 is intentionally slow: slow-hashing functions are good for storing passwords, because it is time/resource consuming to crack them. In the case of Argon2, the hashing consumes memory, too. The tradeoff in your fine-tuning is that your hardware can calculate the hashes a bit faster, and an attacker would have the same advance to the same extent. Also, you just have to consume the resources once per login attempt or password creation, while someone cracking the hash must do it per every single try.

On the other hand, SHA-512 is not designed for storing passwords. Not only that it is faster on the hardware in question, but SHA-512 is way faster to calculate on GPU or specialized hardware, whereas Argon2 does not have this weakness.

Improve this answer
2
  • 15
    Argon is slow but that is not the point of Argon (by multiple iterations you can also make SHA-512 slower): it has the ability to consume a configurable amount of memory which can make brute force attacks a lot more difficult as you can't perform may be 1000 attacks in parallel.
    – Robert
    Commented May 11, 2022 at 13:07
  • 5
    Slow doesn't necessarily mean processor cycles, but I've clarified my answer.
    – Esa Jokinen
    Commented May 11, 2022 at 15:16
16

Argon2 tuned to the max delay you can stand, if you must choose between the two - but the better answer may be: neither.

Multiple judges for the Password Hashing Competition - that selected the Argon2 family as its winner - have since acknowledged that once you tune Argon2 to be as responsive as indicated by UX studies for interactive authentication (<=500ms), it's actually worse than bcrypt from a defense perspective (better for the attacker, worse for the defender). This is because at those tuning levels, Argon2 is less resistant to parallel attack than bcrypt is when tuned to the same responsiveness.

So as long as you're OK with bcrypt's other limitations (max 72 characters, and avoiding nesting), bcrypt may still be a better choice, depending on your scale and threat model.

And either would be a better choice than both raw SHA-512 (because even high iterations don't sufficiently reduce parallelism) or sha512crypt (because it has its own issues).

Edit: some benchmarks that one of the other PHC judges (Steve Thomas) posted to support this claim.

Improve this answer
14
  • Thank you! I will learn more about bcrypt
    – Denis Steinman
    Commented May 11, 2022 at 17:30
  • 1
    Be sure to tune bcrypt to as high a 'work factor' as can be absorbed by your scale - ideally, cost 12 or 13 (whatever gets you closest to that 500ms as you can tolerate.)
    – Royce Williams
    Commented May 11, 2022 at 17:32
  • 1
    Excellent addition, not to limit this to the two algorithms given by the OP.
    – Esa Jokinen
    Commented May 11, 2022 at 17:49
  • 1
    The context was that most users aren't surprised by login times that take longer than a generic page load, and that 500ms was the upper bound of refraining from surprising them. :D
    – Royce Williams
    Commented May 13, 2022 at 3:04
  • 1
    @user1067003 Putting a faster unsalted hash inside a slower salted one opens up a very specific kind of attack called 'hash shucking' - which is non-intuitive for some, but makes some kinds of attacks much faster than the un-nested alternative: security.stackexchange.com/a/234795/6203
    – Royce Williams
    Commented May 13, 2022 at 6:49
3

The other answers have already explained why Argon2d is better than SHA512 for password hashing, but I'd like to share some experience on tuning Argon2 for web server.

  • First, pick the Argon2 variant. Although the spec said Argon2i uses data-independent memory access, which is preferred for password hashing and password-based key derivation, I prefer Argon2id because it provides a balance resistance to both side-channel and GPU-based attacks
  • Second, pick the memory requirement, since a web server need to serve multiple users at the same time. OWAPS's guideline recommend a minimum of 19MB, but you can use a lower number without reducing security by increasing the number of iteration.
  • Third, pick the number of threads/degree of parallelism: 1 is a safe bet, since the web server should already use multiple threads to serve requests.
  • Forth, pick the number of iteration, the higher number the better, as long as the verification speed is not too slow for you. The rule is the lower amount of memory you want, the higher iteration counts you will need to achieve the same level of security.
  • For salt size and output size, just use your hashing library's default value. If you want to customize, a 16 bytes salt size and 32 bytes output size is good enough.
Improve this answer
5
  • Thank you, it means my options are not so bad as I thought!
    – Denis Steinman
    Commented May 12, 2022 at 11:25
  • Tuning the values this low is exactly what makes Argon2 less resistant to cracking than bcrypt is.
    – Royce Williams
    Commented May 14, 2022 at 19:04
  • 1
    It's resistant enough. The argument that Argon2 is worse than bcrypt when tuning to be faster than 500ms has a lot of holes in it; since speed is dependent on hardware: what run slower than 1s in one system can run in under 500ms in another system.
    – Kien Truong
    Commented May 16, 2022 at 1:15
  • 1
    While your answer looks interesting at first glance, it gives almost no reasoning for the values you decided to use. Your solutions may be either really good or can be terribly bad. And nothing gives a hint how exactly one may check it easily. Only for the amount of iterations you proposed to test how fast it is. All others are just "random" numbers.
    – Victor Yarema
    Commented Jul 18, 2022 at 20:12
  • @KienTruong I forgot to mention that reducing the memory requirement is not a "without reducing security" choice. Reducing the memory required makes it cheaper to parallelize attacks by reducing the memory required to be "near" the CPU for faster cracking attacks. Search for "memory hard kdf", or read Colin Percival's scrypt paper for background and reasoning.
    – Royce Williams
    Commented Jul 3 at 0:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .