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.

The claim — The user usually presents a username as her digital name (or identifier) to associate her with a particular user account. Imagine a user logging into Facebook with her username and password. She will enter her username, claiming that this is her Facebook account. To give Facebook some assurance that she in fact is the person behind that particular username, she must also back her claim with some proof. She therefore also enters her password, a secret shared only between her and Facebook.

Verifying the claim — Facebook looks up the account the user claims belongs to her, and verifies that the password presented matches the one they have on file for the account. If the password is correct, Facebook believes the claim to be true and will log in the user. If the password is wrong, authentication fails because the user's claim could not be shown to be true.

That was a short introduction to the concept of authentication, next we'll have a look at the authentication factors used to back up a claim. Just remember: Authentication is all about proving that you are the person corresponding to a digital identity in a computer system.

If you want to dig deeper into the topic of authentication, I recommend a great book on the subject: "Who Goes There? Authentication Through the Lense of Privacy." Clicking on the image will bring you straight to Amazon. This book touches upon the more fundamental aspects of authentication, and will give you a deeper understanding of what authentication really is. I've read it several times myself, every time I learn something new.

A word of advice: Don't drink wine while you read it, you'll suddenly find yourself in a very philosophical mood — asking yourself existential questions and wondering about who you really are. You've been warned.

Authentication factors
You can authenticate to a computer system in various ways. Computer systems are often said to use single-factor, or two-factor authentication. The authentication factors are the different types of evidence presented during authentication. To better grasp what this means, we'll have a look at the common categorization of authentication factors. These are so important that they deserve to be in a list before we explain them:

• Something you know
• Something you have
• Something you are

Something you know — usually refers to a shared secret such as a PIN code or a password. If you're warned that "you must never write down this code/passord/PIN" it's definitely a "something you know" factor. The answer to a personal question falls into this category as well. Examples would be classic password reset "security" questions such as: "Mother's maiden name?", "Name of your dog?", "Where did you go to school?"

*Update: See separate post on security questions: Why security questions are not.

Something you have — means that you can prove possession of a physical token. A well known example is RSA's SecurID tokens shown in the picture. All code generating dongles fall into this category. Mobile phones are increasingly being used for authentication as "something you have" elements, either through code generating apps or by receiving one time passwords by SMS.

Something you are  — biometrics. Iris scans, fingerprint scans and so on falls into this category. This is the least popular category of authentication factors, and it's not usually widely deployed in computer systems.

How many factors?
This brings us right to single-factor vs. two-factor authentication. The difference might seem apparent, but there are some subtleties. To make it a two-factor authentication, you need to use two different types of authentication factors. That means, if you supply a username and a code from your RSA Securid to log in, then it's a single-factor authentication procedure. You've only used the "something you have" factor to back up your claim. If you in addition supply a PIN or password, it becomes a two-factor authentication scheme since you also present a "something you know" factor.

Note that the username does not count as a factor! A common flaw in authentication systems is to e.g. use social security numbers as some sort of "password". It's not, it's an identifier often no more secret than your name. You can claim that it's your number, but you better back it up with some proof!

"Something you have" goes mobile
It is increasingly popular to rely on mobile phones when authenticating users. This is quite natural, since your mobile phone is usually "something you have" with you. There are several ways to leverage mobile phones when authenticating users. One approach is to send the user a one time password by SMS. When the user enters the password on her computer, you get assurance that the mobile phone was present during authentication. Similarly, the user might install an app to generate codes, making the mobile phone a replacement for dongles such as the RSA SecurID.

However, the very reason for a user to bring her mobile phone everywhere — to use it all the time for all sorts of things — also constitutes the biggest security challenge when relying on it as an authentication factor. People surf the web with their phone, they often uncritically download apps, and the phone is usually always online. The broad use of mobile phones, combined with their sophistication, make them an increasingly interesting target for malware writers. As a recent example, there were malicious software circulating on the Android market store, and there were also reports on how users could be tricked into installing apps on their Android phones. In February I blogged how the procedure to purchase and install apps through Android market would reduce two-factor authentication to single-factor authentication if an Android phone was used as an authentication factor.

As more and more websites build on the mobile phone as an authentication factor, efforts to attack mobile devices will only intensify. It will be interesting to see how it plays out.

The end
That concludes this post. I've laid out the basics of authentication, which authentication factors we have and how we count them, and we've touched upon the growing use of mobile phones as the "something you have" factor. I'll be blogging more about authentication procedures, and now that the foundation is in place I can focus more on the specifics.