Web Authentication for Actual Humans, Part Two

Welcome back dear readers! You’ll remember last time we talked about the basic concepts of handling authentication and authorization. Today we’ll discuss the concept of authentication in more depth, look at a few common implementations of some of these specific concepts and the pitfalls you might run into with them. We’ll also describe some of the attacks against each kind.

Authentication types

Last time we defined authentication as your user proving that they are who they say they are. You can break down the methods into a few different types. Most professionals will claim there are three main types of authentication.

Something You Know

The first and most common method of authentication is by using something you know. Some common examples of this would be:

• Usernames
• Passwords
• Security Questions
• PINs
• Social Security Numbers

This method is incredibly common because it’s fairly easy for developers to implement. As the author, you don’t have to worry about having hardware or using external software to authenticate your users.

In all likelihood, you are already collecting some of this data from your users. So it’s a matter of collecting just a bit more so that you can validate who they are.

Users are also generally familiar with this form of authentication and don’t need much training on how it works.

Let’s look back at our nightclub example from the previous post.

The bouncers at The Seal Club are spending too much time verifying every visitor to see if they’re members. One night your bouncer has the brilliant idea that he’s just going to ask each member for a password that he came up with last night.

Everything goes great for a while until someone is walking by when one of your members gives the password to the bouncer.

Shady Johnson over hears it and decides to try it out. He waits a few minutes and then goes up to the door and gives the password he overheard. Your bouncer, being the smart guy he is, thinks to himself “I don’t know this guy but he’s got the password, so he must be a member.” He lets Shady into the club and now you’ve got an unauthorized guest in your club.

As you can see there are some weaknesses with this method. People can share their passwords or have them stolen.

We're all human and very few of us have perfect recall. Because of this you'll find that users will reuse the same authentication data across many applications. This opens an even further weakness to using this method as it doesn’t require your application to be compromised directly for an attacker to gain illicit access to it.

Another weakness of this form is that it’s somewhat trivial to compromise. All an attacker needs to do is collect the data you use to authenticate through one method or another. There are many ways that Shady Johnson could do that. He could use complex methods like installing a key-logger on your computer, shoulder surfing while your users are logging in or even simply asking the user for the information.

There have even been studies that show that a large portion of users will give up their login credentials for a bit of chocolate.

Because of these weaknesses, The tech world has started turning to other forms of authentication.

Something You Have

This method of authentication validates you by using something you physically have. Common examples of this are:

• A physical key
• Your mobile phone
• An RFID badge
• A magnetic strip, such as on your credit cards.
• A device that generates random strings of characters based on a shared algorithm generally referred to as a “token” or “smart card”

If you remember in the previous post, The Seal Club started giving out RFID bracelets that were used to identify any particular member. This sped up entry for members, made it easier for your bartender to verify that members are allowed to buy drinks and freed up time for your manager to run other parts of the club. These improvements to your employees workflows and the perceived security comes at a cost unfortunately. The hardware required for these bracelets are fairly expensive, roughly $500-$1000 per access point and each bracelet can cost upwards of $10 each unless you’re buying thousands or tens of thousands of them at once. This can be a significant expense if you’re just starting out.

Your members also now have to worry about keeping track of a new bracelet. If they forget their bracelet, they can’t enter your club. If they lose it, then you now have a bracelet out there that anyone could use to get into your club and run up a legitimate member’s bar tab without their knowledge.

Generally these types of authentication all require some extra hardware that your users may or may not already own and generally some extra hardware and software on your end as well.

They’re also not completely foolproof, aside from malicious users stealing the actual physical key, in the case of RFID or other similar devices it’s possible for someone to trigger your key from a short distance and copy its data onto a new key and use it that way.

Something You Are

This type of authentication uses things that are unique to you as a human being. Common examples are:

• Fingerprint scanners
• Retina scanners
• Iris recognition
• Facial recognition
• Voice recognition

The final mainstream type of authentication relies on authenticating you based on physical traits of your user specifically. These are generally much more difficult to impersonate but not impossible. They also require much more expensive hardware and software to use.

As a club owner, you got tired of having your bouncers ask for ID for all of your patrons, so you’ve decided to only check ID up front and record your patrons fingerprints using a consumer level scanner. This definitely speeds up the process for your employees. You feel like you’ve made a great purchase and frees up your bouncer to do other duties. Everything is going well until you start getting complaints from patrons who are being charged for drinks on nights that they can prove they weren’t at the club. After an investigation you determine that a few bad actors have been making fingerprint copies a la Mission Impossible. You ban those guests and have your bouncers watch out for them. A few weeks later you get more complaints, this time the culprit is unintentional. After some research you determine that the consumer level scanners only do partial matches on fingerprints. This means that it’s very possible to have false positive comparisons. You also thank your lucky stars that no one had their finger cut off and used directly.

In general these types of authentication are fairly secure and you’ll never have to worry about your users losing them or having them stolen. But you can see that it is possible to compromise them as well.

The hardware involved can also be fairly expensive to implement in the field. You might ask about the plethora of fingerprint and facial recognition systems built into smartphones these days. Offloading some of the cost to your users is possible with these systems, but they still require paying for access to the APIs involved. They’re also not necessarily very strong.

Many security professionals will stop the list of the different styles of authentication there. I like to remember that there’s a fourth kind of authentication that’s just as useful as all of those as well.

Something you DO

This style of authentication is a bit more vague in what it means and how you accomplish it. There are lots of potential ways to think about it. For example you might have to go to a specific place to be able to use a particular system or you might have to press two buttons at the same time to begin a process.

If you have seen the original Mission Impossible film, Ethan Hunt had to infiltrate the CIA headquarters to access a database that could only be accessed from a single computer in a secure room. The CIA in this film was employing this type of authentication as part of the way to protect this data.

I would personally argue that oAuth is an implementation of this type of authentication as well. You might be thinking “but I have to put in a username and password?” That is definitely true, but you are not logging into the application directly. You’re authenticating using your username and password with a third party that both you and the application trust. The application you’re authenticating with trusts that you are who you say you are because the third party it trusts says you are.

You might then ask yourself “Then that’s something I am right? I’m a user of that third party” But remember that form of authentication relies on physical things about you that are nigh impossible to impersonate. In addition you might use those things to authenticate with the third party, but the important part of this method is that you use that third party. This is why I consider OAuth to be a form of “Something you do” Authentication.

So they’re all insecure?

That’s right, all of these methods have some amount of vulnerability to attack. With something you know being the most vulnerable and something you are being the least vulnerable. The goal of any authentication workflow is to choose an appropriate amount of risk for the application and how sensitive its data is. If you’re thinking “My data is very sensitive. I’m not comfortable having that much vulnerability in my application.” You would not be alone. To combat that you can use the next topic to assuage your fears.

Two/Multi factor authentication

One way that you can decrease the chances of your users being compromised is that you can combine multiple methods during a single authentication workflow. You always want to have them be different types of authentication, such as Something You Know and Something You Have. In that example that may manifest as a username/password combined with a physical token. If you are even more paranoid you can add more factors to the equation. Having multiple authentication methods in a single workflow lowers the likelihood that all of them will be compromised at the same time.

That said there are a couple common forms of 2 factor authentication that are less secure than one might think. Many places send an email or text message (SMS) to you in order to confirm that your are who you say you are. Both of these methods are easily compromised compared to other forms things you have.

What if you've lost it?

We’re all humans and most of us don’t have perfect recall. Because of this fact usernames and passwords are subject to being misremembered or forgotten completely. Physical tokens and other devices are subject to loss or damage.

In the many years that we’ve been building electronic systems, we’ve worked around these failings in many ways. For usernames and passwords we've built the capability for your users to reset their passwords using other forms of authentication. Today the fallback authentication usually consists of sending an email with a temporarily trusted key or password.

For physical tokens, mobile phone issues and biometric failures, we're mostly reliant on face to face, trusted email and other manual methods of authentication.

Other Concerns

One final thing to take into account when choosing an authentication method is the user experience. Depending on how essential your application is to your users, using multi-factor authentication with biometrics, physical tokens and username/passwords might be overkill and cause many of them to not use your application at all.

You can also understate the security of your application by only requiring a single form of authentication and this may turn off users if the subject matter is relatively sensitive.

We'll discuss this further in a future entry in this series where I'll give you some questions to think about when designing your authentication schemes.

Closing Ceremonies

In this installment of Authentication for Actual Humans, we discussed the different ways you can handle the initial authentication of your users, the common pitfalls while implementing them and the common ways some of them can be compromised. In the next installment I’ll show you the different ways you can handle ongoing authentication, server to server authentication and common authorization schemes.

Until then dear reader!

Web Authentication For Actual Humans:

1. Part One
2. This Post
3. Coming Soon