Towards more secure password hashing in ASP.NET

A couple of weeks ago I was remotely involved in a discussion on password hashing in .NET with @thorsheim, @skradel, and @troyhunt. (Follow them if you're on Twitter). The background for the discussion was that password hashing using MD5/SHA-1/SHA-256 isn't quite the state of the art anymore. All the recent password breaches have triggered recommendations to make password cracking harder. The algorithms that are usually recommended are PBKDF2 (Password based key derivation function), bcrypt, or scrypt. So which of these should you choose if you're working with .NET?

I'm a conservative guy. Cryptographic algorithms are very hard to get right, as there's all sorts of things that can go wrong when you implement them. Consequently, I prefer to use whatever is available in the .NET framework. That's because Microsoft have crypto-experts on staff, and they've also pioneered the SDL which means you should expect high quality implementations of their (security critical) software. So it's really a trust thing. At the time of writing, PBKDF2 is the only algorithm of the three mentioned that's readily available in the framework. You probably see where this is leading: bcrypt and scrypt are disqualified in my book. When it comes to cryptographic functions, stick with the framework! PBKDF2 is the best alternative for now.

Following the discussion on Twitter, @skradel shared a library where he had wrapped the built-in PBKDF2 as a HashAlgorithm. That way, PBKDF2 (through his wrapper) could easily be used by other parts of the framework, such as the SqlMembershipProvider. It really was an elegant solution. He blogged about it in: Strong Password Hashing for ASP.NET, you should check it out (@thorsheim was so delighted that he had to blog about it too :).

When you're dealing with PBKDF2, you'll see that it takes a couple of parameters. @skradel's already chosen some reasonable defaults in his implementation so it's all hidden and taken care of there. But if you were to implement this yourself and explain to someone how you chose those parameters, what then?

How not to hash passwords in .NET

In connection with a bug in TransformTool, I've been looking into how text encoding is handled in the .NET framework. Turns out there are some caveats that can affect the correctness of a program, and when used in e.g. password validation they might turn out to be severe security issues.

This post assumes you are somewhat familiar with how character encodings work. You might want to check out my Introduction to character encoding if you're not. I wrote it mainly because I didn't want to explain the basics of encodings in this post.

The encoding issues/features I discuss here are all well documented in the article Character Encoding in the .NET Framework, but I believe that the issues aren't that well known. Stack overflow, blogs, and discussion forums are riddled with insecure code samples. Do a Google search for "ASCII.GetBytes" password, and you'll get a lot of results. I even found insecure code examples in a text book, the C# 2008 Programmer's Reference (page 344). So I definitely believe we need to raise awareness of these issues in the .NET community.

Encoding subtleties
In the MSDN article on character encoding you'll find that the first suggestion on how to use the encoding objects in .NET is: 

Use the static properties of the Encoding class, which return objects that represent the standard character encodings available in the .NET Framework (ASCII, UTF-7, UTF-8, UTF-16, and UTF-32). For example, the Encoding.Unicode property returns a UnicodeEncoding object. Each object uses replacement fallback to handle strings that it cannot encode and bytes that it cannot decode.

And people love to use the static properties! But if you don't read this carefully and pause with the "replacement fallback", you might get into trouble. "Replacement fallback" means that every character that cannot be encoded to bytes will be replaced with the "?" character silently. But what does that mean? Time for a demo using the ASCII encoding:

Why security questions are not

The other day, I received an "encrypted e-mail" through the Cisco Registered Envelope Service. Their "about" page states:

If the envelope is password-protected, it can only be opened by authorized recipients who authenticate themselves. If you are a first-time recipient receiving a password-protected secure envelope, you will be asked to register with the service to set the password which will be used to authenticate you.

I had never used the service, so I had to register before I could get access to the e-mail. To my surprise, I had to choose three security questions and provide an answer to them before the registration could be completed.

Introduction to authentication

The last couple of months large players such as Microsoft, Google, and Facebook have announced changes to their login procedures and how they authenticate their users. Facebook and Hotmail offer single-use codes to avoid compromise of users' regular passwords. Google has rolled out a new (optional) two-step verification for access to Google accounts. These are interesting changes in functionality to increase the security for users on the Internet.

I'll be blogging about some of these authentication procedures. To lay the foundation for my upcoming blog posts on authentication I figured it would be a good idea to give a quick rundown of what authentication is, just to get the basics out of the way. Here it goes:

Authentication defined
If you consult the Oxford dictionary on your iPhone you'll learn that:

authenticate:
prove or show (something) to be true, genuine, or valid;

When we authenticate users of computer systems, what are we trying to prove? In short, that the correct people are logged in to the correct user accounts. So, for computer systems we'll see that it makes sense to use the following definition:

Authentication is the process carried out to show that a user is who she claims to be

To explain what this means we'll break a typical authentication procedure into two phases: the user claims to be the owner of a digital identity, and we need to verify that the claim is true before the user is allowed to assume the claimed identity.