Heartbleed and Two-Factor Authentication - Does it help

Along with all the hype about the heartbleed bug, I've been reading a lot of posts and articles that recommend (amongst other things) to enable Two-Factor Authentication (2FA) to all services that support it.

In general, having 2FA greatly increases your security, since you credentials are not bound to just a username/password pair (something you know), but also rely on something you have (a phone to receive text messages or a device/application that generates one-time tokens).

Is this the panacea and the solution to the heartbleed problem?

User Authentication/Life-Cycle Management Best Practices

The last couple of years, we have witnessed an ever increasing number of pwnage to various sites, leading in compromised user accounts. A lot of these sites do not even have the user credentials hashed (even using the least amount of effort) but rather have the username/password pairs as plaintext. You can go to haveibeenpwned.com for a small list of such compromises. And the ones mentioned are mostly fairly recent to the blogs posting.

This allows malicious users that gain access to this data to possibly use the same credentials on different sites (because nobody reuses passwords, right?).

A greater concern is also the fact that the compromised site/services do not disclose the issue in a timely manner (in a lot of cases they are unaware the compromise happened!!!), so the user is unaware that their credentials have been leaked, allowing them (if we are talking about a slightly above average internet user) to do anything possible to protect themselves. Of course, little can be done if the site/service has very poor security mechanisms (if the user changes their password, the hacker could simply re-dump the password database for example). But, this is a conversation for another time.

What I will be focusing in this blog post is how to correctly manage user accounts in a web application. There is an abundance of frameworks out there that provide all the piping necessary to help a developer correctly set up the whole identity life-cycle. Some have more features than others, but at least they provide a start point for a developer to create more secure code. Why on earth a developer would try to re-invent the wheel is beyond me - after all, one of the basic principles of programming is code re-usability.

The blog post was heavily influenced by daily news, and Episode 1 of the Professionally Evil Perspective podcast which mentions some of the below points I will be making.

For the purposes of the blog post, I have created a Web Site project using Visual Studio 2010, which is available on codeplex.com here. I leverage the ASP.Net Application Services framework for the piping, but the same concepts hold for most of the other authentication and user management frameworks available out there.

TOTP for ASP.Net Web Forms

Ok, so following my previous post (Two-Factor Authentication - What's the right way) I decided to go on and create a Proof of Concept on how to implement RFC 422 (the way a lot of web services implement 2 Factor Authentication, including Google, Microsoft, DropBox, LastPass etc) using ASP.Net with the Membership Provider.

Although I managed to find a lot of sample code to implement the RFC in .Net code, I failed to find anything that implements this using ASP.Net Membership Provider (MP). In just a few words, MP is a solution built in to .Net Framework that allows for user and credential management in .Net applications (more here). Please note that the same concept can be applied in different frameworks.

Two-Factor Authenication - What's the right way

Following the numerous compromises of accounts to various online services (with the most news-covered being the Twitter account compromises), more and more online services are providing means for Two-Factor Authentication (2FA).

Just as a short primer, authentication is the procedure a service has in order to verify that the user claiming to want to authenticate is actually the user which holds the account. A good simple example (of one-factor authentication) is a username/password combination. I authenticate to the service by providing my username/password combination, and since I am the only on that should know this, I am authenticated as being the owner of the account.

The big problem with the above is what happens if my credentials are stolen or compromised? Well, the service can be tricked by a third person, which can provide the valid username/password combination, into thinking that the third person is me! Granted, there are cases where this is actually desirable (such as shared accounts) but in the end, the result is the same; the service has no way to identify that the person between the chair and the keyboard (or behind the touchscreen nowadays) is the account holder.