Aspects of computer security: Authentication

In the first post in this series, I introduced a list of six interrelated things that together form the general topic of “security” in computer systems. Today I’m going to talk about the first of those:

1. Authentication — Who am I, and how can I prove it?

Authentication is a precursor to some of the other aspects, for reasons that we’ll see in detail as we look at the others. It should be obvious, for instance, why authentication is related to authorization and access control.

Everyone reading this is familiar with the authentication mechanism we started out with: some sort of user identifier (name, account number, serial number) and password. It served us well over the years, but it’s not a very robust system, for a number of reasons that I talked about here. When you log into webmail, Flickr, MySpace, online banking, or online access to your credit card account, you use this mechanism, which makes use of what you know.

We broadly divide what authentication mechanisms use into three categories:

1. What you know.
2. What you have.
3. What you are.

All of the “what you know” mechanisms are variations on userid/password combinations, and they all share the weaknesses that I talked about last August in the referenced post. And so here, I’ll talk about the others, which can help fix some of the deficiencies of passwords, especially when used in combinations.

The most well-known combinations in everyday life are these:

• Point-of-sale credit-card purchases, where you sign the credit slip. These are a combination of what you have (the credit card) and what you are (your signature).
• ATM transactions. These combine what you have (the ATM card) and what you know (your PIN).

Another “what you have” mechanism is the SecurID device, which gives you a generated code that you can only get if you have the device with you.

Other “what you are” mechanisms use fingerprints, retina scans, and voice or handwriting analysis — collectively, biometric mechanisms. The most robust authentication systems combine multiple biometric mechanisms with an identification card and a password, with all authentication information transferred securely (see the end of the “Why are passwords weak?” entry, where I talk about using public-key encryption). That makes a system that’s pretty hard to break.

A final note here: Some people are reluctant to use systems that go beyond “what you know”, because carrying the “what you have” card or device can be a burden (what happens if you lose it, or leave it at home when you’re travelling?), and biometric readers can be expensive. But also, there’s often a desire to allow an assistant or some other delegate to act on your behalf, and it’s easy to give the delegate your password (but much harder to “lend” your retina).

The answer to that is to understand that there’s a difference between impersonation and delegation, and the difference goes beyond authentication and into the next topics, authorization and access control. The right way to handle delegation is to have the delegate authenticate with his or her own identity, and then be authorized to act on your behalf, and be given access to the necessary information and resources. You should never allow another person to act on your behalf by impersonating you, because there’s no accountability in that.