Bcrypt / Bcrypt.net Strength and Alternatives

Question

Well after repeated research, I decided to use bcrypt (feel free to comment) for the hash and store passwords in my phonegap application.

A few days ago I stumbled upon Bcrypt.net, and it seems "good enough" to me (again, feel free to comment). So my question is, what other alternative bcrypt implementations are available in C #? Are there SEVERE flaws in the implementation of Bcrypt.net?

My security model will basically look like this:

• User enters their PIN / password / passphrase on the client
• This is sent to my .net application over secure SSL (so basically send in clear text from the client)
• Use a library like bcrypt.net to hash the password and save / compare

Is there anything else I really need to consider here?

Any help would be greatly appreciated.

Answer 1

Glad to see someone here who has done some research.

I did not see any good reason why you should not use bcrypt. In general, using bcrypt, PBKDF2, or scrypt on a server to provide a good level of security.

As always, the devil is in the details. You definitely need SSL if TLS 1.2 is possible using AES encryption. If you cannot do this, make sure that you do not allow much more than the username / password + required HTML in your connection.

You must decide on the encoding of the password character. I would recommend UTF-8, maybe narrowed down to printable ASCII characters. Either document the character encoding used, or save it somewhere in the configuration.

Try to save all the input parameters for bcrypt along with a "hashed" password. Of course, don't forget the iteration counter. This makes it easier to switch to a higher iteration counter when the user enters his password later. You need to create a secure random salt of 8-16 bytes in size to store with a password.

In addition, you can use the optional KBKDF (key-to-key) scheme to output any of the above PBKDFs. This allows the use of bcyrpt output for extra keys, etc. KBKDF works with data with sufficient entropy, so it usually takes a little time (for example, they use the KDF mode compatible with NIST SP 800-108). I think this should be considered as an "expert regime."

Answer 2

You are good at bcrypt.

Excellent research from the cracker: https://crackstation.net/hashing-security.htm#faq Additional software verification: http://www.sophos.com/en-us/medialibrary/PDFs/other/sophossecuritythreatreport2013.pdf

bcrypt is also part of C # libs: http://msdn.microsoft.com/en-us/library/windows/desktop/aa375383(v=vs.85).aspx

Answer 3

The main reasons for hashing passwords are:

a. Clear password texts are not transmitted over the wire (primary).
b. Clear password texts are never stored on the server (secondary)

So, with your setup - you do not. and rely on SSL instead. I think you should still hash the client side if possible. There remains more room for future changes, and overall passwords deserve better security / protection than your content data.

Also, I don’t know which server applications / extensibility you can support, so re-isolating passwords from code can still be an additional problem.

Regarding the actual algo / util for hash execution - I have no security experience :)