ASP.NET MVC 5 - Argon2 GetBytes method hangs

[ghost]

When I run my MVC Application, the Argon2 GetBytes method does not complete but instead hangs, for a reason unbeknownst to me. I have set up breakpoints to ensure that the correct parameters are passed to the method, and this is the case, yet when I execute the GetBytes method:

var hash = argon2pass.GetBytes(64);

The application hangs and the line is never executed.

[ghost]

It is known problem and the reason why I do not use this lib:

https://github.com/kmaragon/Konscious.Security.Cryptography/issues/22 https://github.com/kmaragon/Konscious.Security.Cryptography/issues/18 https://github.com/kmaragon/Konscious.Security.Cryptography/issues/11

[ghost]

@hardhub Thanks, I didn't realise this issue was widespread, I didn't check the closed issues. That's a real bummer. Have you got any good recommendations for another library, one that you have used?

[ghost]

Oh, it appears that there are workarounds.

[ghost]

It was a reason why PDKDF2 - HMACSHA512 with very big amount of iterations is finally used instead of Argon2.

I think there are no relatively stable lib for Argon2 in C# for now. So it was decision to use time-proved algorithms. Yes it is not such effective in case of GPU.

But https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40

3.5 MHashes/s

SHA512 allows you to use output till 512 bits. Even with 128 bit it will enough good. But I think 256 is preferable.

For 256 bit output of PBKDF2-HMAC-SHA512 some cluster with 1000 such 8xGPU machines will try to find collision approximately in 10^60 years. It is much more than age of Universe (as we know it for now).

So I recommend you to use first of all salt to avoid rainbow table attack (though I do not know any existing rainbow table for PBKDF2-HMAC-SHA512) and much more important - try to avoid dictionary attack (use secure random passwords).

Also you can try bcrypt or scrypt. But common rules are the same.

[ghost]

@hardhub Nice link, thanks for posting it. I take password security very seriously and in terms of password hashing itself I making sure that it will not be susceptible to any kind of brute-force attacks, rainbow tables and dictionary attacks as you have said. I would rather use a relatively recently proved KDF such as yescrypt/Lyra2 if I can't use Argon2.

Salts are an absolute minimum and I'm imposing somewhat good restrictions on what kind of passwords users can use, and make calls to the Pwned Passwords API to make sure they're not publicly exposed along with that.

[kmaragon]

I'm Closing this. The issue should be fixed (by putting the 'workaround' into the base library). Otherwise, not to disparage this conversation. It's a perfectly valid and useful conversation. But this is probably the wrong venue for it.