5
I’m trying to give my system a satisfactory level of security. In my researches I found several functions that create hashs for passwords, but among all of them, I saw the most recommended were PBKDF2 and Bcrypt.
In all the searches however, what I saw was: "If misused, a hash is no use!".
So here’s the question, what’s the right way to create a hash using Bcrypt, for example?
Follow my code as it currently is:
public static string HashGeneration(string password)
{
// Configurations
int workfactor = 10; // 2 ^ (10) = 1024 iterations.
string salt = BCrypt.Net.BCrypt.GenerateSalt(workfactor);
string hash = BCrypt.Net.BCrypt.HashPassword(password, salt);
return hash;
}
public static bool PasswordCompare(string hash, string password)
{
return BCrypt.Net.BCrypt.Verify(password, hash);
}
Seems right to me... I don’t know if a work factor 10 is good enough (such as in the case of PBKDF2, also pro bcrypt you must use the highest tolerable factor), but otherwise it’s okay (you’re creating a random salt, the bcrypt output already includes the salt and the working factor, and the password check is ok). P.S. For 2015, that response in security.SE suggests a working factor of
16(but if your system endures more, better).– mgibsonbr
@mgibsonbr I know why you are avoiding answering but I doubt that anyone will answer better, go ahead! And if someone responds, yours will cause no problem, because you will certainly put a warning that you do not give guarantees that you have seen everything that may be wrong and do not know this specific implementation, have not seen other parts of the application, etc.
– Maniero
@Honestly, it didn’t occur to me... : P In my conception, for the purpose of storing passwords it doesn’t make much difference whether or not there is failure in the implementation, if the result is correct the attacker’s work will be the same. After reading your comment I even thought "and if a bad implementation allows a Attack timing?" but I soon discarded it, as in your original question, the hash places a lower limit on testing a password, so even a brute force attack on the server will never be faster than the offline attack.
– mgibsonbr
@bigown I should have learned by now not to make that kind of statement... In fact, I still don’t know any Attack timing applicable to password hash, but I remembered have already studied on a very similar scenario - Macs verification - where in fact a flaw in the implementation allows a remote attack that completely destroys security. It does not apply here (because there was fixed the message and varied the MAC, here fixed the hash and varies the password) but serves as warning that things are never as simple as they seem...
– mgibsonbr