The Pragmatic Architect

Too often I still see plain-text passwords in a database – really, what need is there to store the actual password?  I find it rather funny that some of the IT types out there will fret for days over performing a firewall change but don’t really bat an eye at the fact that a simple SQL Select query may return all of their user’s password data.  I’ve heard arguments like “but the database server isn’t accessible to the internet” – really?  So can you really guarantee that your entire app is immune to SQL injection attacks?  And it will always remain that way?  And what about the administrative DBA that becomes disgruntled and quits?  Are you at risk now?  I think anyone that stores a password in plain text or even using SQL Server’s encryption should say they are at risk in the last scenario (DBA’s made the encryption key backups, right?)

At this point, if I have to do an evaluation of an existing application, one of the first things I’d do is query the main user table and just look at the data set – if I see passwords, it’s a FAIL IMHO.  There was a time where the encryption and/or hash was more difficult to do, but that time has passed.  Let’s move on .

Recommended Approach

My best recommendation to you would be to use what is called a salted hash to store a representation of the password (but not the password itself) – there are plenty of detailed articles online for more detail, feel free to search for more information – my goal here is to quickly define what this means and to show how little code is needed with the .NET framework to achieve a functional salted hash.

Definitions

First some quick definitions:

• Hash – generally a math formula that is applied to a given string or set of bytes that provides a numeric derivation or hash of the value provided – good algorithms offer excellent protection against 2 different values hashing to the same hash value.  In cryptography the common hash algorithms are SHA-1 and MD5 with more recent advancements being SHA-256 and SHA-512.  Hash values are often used for what is called a digest in security systems.
• Salt – a cryptographically random sequence of bytes generated once for each user – the function of salt in a user store is to generally obscure the fact that 2 users may actually have the same password.

How it Works

OK, so the basic idea is that when you create a user account, you generate a ‘salt’ – that is a random sequence of bytes usually 6-8 bytes long.  This is generated once and ONLY once – it can never be updated or you’ll break the password authentication.

So with a user created with a salt, you then calculate a hash by doing the following (pseudo code)

user.PasswordHash = CalculateHash(Concat(user.Salt,passwordString);

OK, now to validate a user’s login, it’s basically the same calculation and you compare the hashes – again pseudo-code for this section

if (user.PasswordHash == CalculateHash(Concat(user.Salt,passwordString))
	// user entered the correct password
else
	// passwords don't match

Continue reading →