Authentication of Humans

People aren't computers. They don't have the computational
or storage capacity. So the mechanisms to authenticate
humans are considerably different from the mechanisms
to authenticate machines. (Though they both have
in common the notion of secrets.)

Something you know: you demonstrate knowledge of secret,
e.g., password

Something you are: you demonstrate some feature of
yourself,
e.g., fingerprint

These aren't always clear-cut categories. A sheet
of passwords, each valid only once, could be "know"
or "have." A finger could be "have" or "are."

Frequently these are combined. Use independent methods
from each of two categories, and you have
two-factor authentication,
e.g., using an ATM card requires "have" (card) and "know" (PIN).
The general case is called multi-factor authentication.

Identity

What is an identity? A name? A netid? An email?
A URL? An IP address? An X.500 distinguished name
(/C=US/O=CORNELL/OU=CS/CN=Michael Clarkson)? Other attributes,
like your citizenship, your credit score, your political
party?

In this course, we'll say that
an identity is a set of attributes; each attribute
is a statement about or property of a principal. You have
many identities that you present to those around you.
Some of them might uniquely identify you, others might not.
An identifier is an attribute that is associated
with exactly one principal, perhaps within a
given population.

Enrollment is the process of establishing an identity.
We go through enrollment protocols all the time, e.g.,

creating an account on a website,

getting passports and visas,

registering a machine on a wireless network, and

establishing a signing key with (e.g.) Verisign.

The amount of work that the principal enrolling us does
varies widely. Websites rarely verify many of our attributes, but
governments issuing travel documents usually do. And we can pay to get various
levels of verification from companies like Verisign.

Enrollment is tricky to design. It's where the digital
world interfaces with the real world, so there's no fully technical
solution.

Privacy

When authenticating humans, privacy is an important concern:

When enrolling a human, a system learns about their attributes,
which might include personal information, e.g., SSN.

When requesting authentication from a human, the human might
believe that establishing
their identity is detrimental, e.g., concerns about
having a photograph captured.

When binding an action to an identity, the action might involve
information the human doesn't want to share, e.g., what medicine they purchased.

When auditing, an identity might be stored and later abused, e.g.,
the storer uses it for data mining or hackers commit identity theft.

So authentication of humans must be handled carefully.

Here are some guidelines for privacy in human authentication:

Seek consent. Authenticate only once you have consent,
and inform humans whether their identity will be stored.

Select minimal identity. Authenticate against smallest
set of attributes necessary.

Limit storage. Don't save information about authenticated
identities without a clear need. When the need expires,
delete the information.

Avoid linking. Don't reuse the same identifier across
multiple systems. This is commonly violated for the sake
of convenience.

Something You Are

"Something you are" is authentication based on biometrics.
Biometrics are a measurement of your physical or behavioral traits, e.g.,
your fingerprint, face, iris, retina, hands, or DNA.
To be usable for authentication, a biometric must be (i) an identifier within the
population; (ii) invariant over time (N.B., kids' fingerprints change);
difficult to spoof (proof of life?); and easy to measure.

Biometric measurement suffers from the problems of false positives
and false negatives, so biometric authentication mechanisms
can incorrectly accept or incorrectly reject
an authentication request. Which is better depends on
context. And both are bad: on commercial flights,
a false negative or false positive rate of just 1% could
have serious consequences.

Another problem with biometrics is updating of identities.
If a fingerprint is disclosed,
how do you issue the human a new finger? What about
a new retina??

But despite these problems, biometrics are attractive.
You can't lose them, forget them, or share them.

Something You Know

"Something you know" is authentication based on
a human's knowledge of a secret.
The secret is usually a PIN (short numeric code),
password (short string), or passphrase (longer string).
I'll write "password" from now on, but everything we talk
about is relevant to all three.

Passwords have a life cycle:

Create: user chooses password

Store: system stores password with user identifier

Use: user supplies password to authenticate

Change (Recover/Reset): user forgets; wants or needs to change

Passwords unfortunately do get disclosed to attackers sometimes. How
might that happen? They could be found on post-it notes, revealed by
the user themself (social engineering), guessed by the attacker
(online guessing), or cracked by the attacker who
obtains the password database (offline guessing).

Prompting for passwords.
Implicitly, there's always some kind of mutual authentication
going on. Before the human enters a password, she has to decide whether
to enter it. (Many people don't think about this very
carefully, contributing to the success of phishing attacks.)
Some systems go to greater lengths to achieve mutual
authentication:

Windows has a trusted path to the OS:
only Windows itself can receive the Ctrl+Alt+Del key sequence.
That makes it difficult for malicious code to pretend it's the OS.

Many banks use a visual secret technology.
The user enters a username, the bank displays that username's chosen secret,
then the user enters a password. The idea is to prevent phishing
by causing users to abort if the picture isn't right.

Do visual secrets really work?
The basic assumption underlying their use is that users can't discern
whether they're really interacting with their bank or not (e.g., by looking
at the browser's title bar.) Consider a man-in-the-middle (MitM) attack, in
which the attacker interposes between the human and bank. The attacker
learns the human's uid, forwards it on the bank, receives back the user's
visual secret, and displays it to the user. The user then enters her
password for the attacker. GAME OVER.

What would prevent this attack? Only the human noticing that website isn't
really the bank's. But that contradicts our initial assumption.
So visual secrets don't actually, fully prevent phishing attacks. QED.

Visual secrets do raise the bar, though, by making it (a little) harder for
attackers to mount phishing attacks. Maybe every little bit helps.

Finally, note that visual secrets are trying to solve a UI problem in
the browser—enabling the user to easily identify the remote server.
Perhaps that's the problem more worth solving, but it's a really hard one.
Users are quite bad at detecting counterfeits!

What should happen when password-based authentication fails?
I.e., how should an application react in response to successful or failed authentication?
It could be useful to tell successfully authenticated users when
they last logged in, the number of failed attempts
since then, and maybe even when those attempts were.
When authentication fails, the identity might be under online attack.
Possible responses include rate limiting future attempts to authenticate
under that identity, and eventually disabling the identity (though that creates
an availability attack).
Informative error messages tend to hurt security here.

A related question is: should an application prompt for a username
first, or at same time as the password? Prompting first creates a new vulnerability, in
that it enables attackers to guess valid usernames.
So it's better to prompt at the same time, and not give any indication of which
was wrong, the username or the password, if authentication fails.
(Note how visual secrets might disobey this rule.)

Recovering or changing passwords.
Users forget passwords. Systems cause passwords to expire.
And users want to change passwords. So recovery and change
are really important parts of the password lifecycle.

Unfortunately, these parts tend to receive less attention
than the rest of the system and consequently might be poorly designed
and tested. That makes them attractive targets for attacks, rather
than going after the (presumably well-engineered) primary authentication
mechanism.

Recognize that recovery is the authentication problem all over
again: the system must authenticate user by some other means than a
password. Standard solutions on the web today exemplify that:

Answers to questions: this is "something you know",
using attributes of your identity established during
enrollment. It trusts that other humans can't masquerade
as you—which is likely not true!

Sending an email with a link: this is "something
you know", using a (one-time) password that expires
immediately after use. It trusts that your email account
correctly authenticates only you.