We're currently working on a new server application that is going to communicate with client applications on many different systems. For this we wanted to implement a new password hashing scheme.
I've done quite some research, including reading many questions on security.SE and crypto.SE, about the hashing of passwords. After this research I've come up with the following hashing scheme:
We will use
PBKDF2 as the hashing algorithm. The choice for this lies mainly in it being available directly in the .NET Framework. I've looked at both
scrypt, but because both need third party libraries we just went with
With the use of
PBKDF2 there is also the free salt you get when generating a hash for the first time.
The question then was how to save the data in the database. We had two options:
- Save each value seperately, i.e. hash, salt, iterations and algorithm.
- Or save it as a single string.
We went with the single string value which looks as follows:
This is similar to how, for example, Django does it.
I've implemented it like this and wrote up a report with our choices and arguments. But now I get questions about the design. For example some wonder why the salt is so clearly saved, wouldn't it be better to combine the salt and hash in a single string to make it less obvious to attackers.
Usually these cases make assumptions where attackers only have the database and such. While I claim that we should always look at the worst case scenario and assume attackers have both the code and the database. I also claim that the salt is there to negate the effect of rainbow tables and lookup tables. And the number of iterations is the deter brute force attacks.
But because I'm not a security professional, what I say can easily be ignored (although this goes for any argument on the internet ;)).
Therefore, I need anything that can show that what we created is a correct way of doing it.
I've just implemented a lot of things I found on the internet, but have no (scientific) proof that this is sufficient.