Authentication and Authorization

IAM

In security land, the term IAM is short for Identity and Access Management.

Authorization is the identity part, authorization is the access part.

Authentication

Authenticating users can be done using many factors. Authentication factors can be:

• Something you KNOW: password, passphrase, PIN
• Something you HAVE: phone, physical key (USB), email address
• Something you ARE: face/voice/fingerprint/retina recognition

Let’s go over some topics in Authentication.

Password Strength

Obviously if an attacker steals or guesses your password it’s game over. Good passwords must be hard to guess by an adversary. This means (1) not a common password, as this is subject to a Dictionary Attack, and (2) not be short, as this would be subject to a Brute-force Attack.

To make these attacks less successful, a system should make the validation check on the password very slow. That way an attacker can not try thousands or millions of guesses a second but only one per second or fewer.

In addition to being strong (hard to guess), you might want to make your passwords easy to remember:

Of course, if you use a password manager, remembering them no longer becomes important.

Required Reading

Read Troy Hunt’s article on password authentication.

Password Storage

So first, Where should we store passwords? Depends if you are the user or the application.

• USERS need their actual passwords. They can store their passwords in a vault or password manager.
• SYSTEMS must never ever ever ever ever EVER store actual passwords. They must never ever ever ever ever even store encrypted passwords! ONLY store salted hashes of passwords in a database or other secure location, server-side. Never unhashed, ever. Not even in memory (remember Heartbleed?). And make sure to use a very strong hashing algorithm. Also, applications should never store passwords that the user types in browser local storage (XSS can get these). Clear out memory after the hashes have been checked.

An organization should force users to create strong passwords (e.g., by enforcing minimum lengths), and never place too restrictive of limits on how long or how complex passwords should be. Stronger passwords are harder to crack, so even if the salted hashes get leaked, attackers will need a much longer time to get ready to do damage.

If you are doing an authentication service, hash passwords with something like bcrypt. It is really good. And slow, because we want it to be slow. Actually, it can be configured to make it as slow as you like.

On many Unix systems, passwords for users of a computer system itself, not the application, were traditionally stored in the file /etc/passwd, but today they are are stored in the shadow password file, /etc/shadow. The shadow file is owned by the root user, and contains the username, password hash, the datetime of last password change, min and max password age, warning and inactivity periods for password changes, and the datetime that the account was disabled, if any. The regular passwd file only contains the username, user and group ids, user full name, home folder, and preferred login shell.

On macOS there is no shadow file; credentials are store in plists (property lists) deep in the file system under /var/db. And yes, owned by the root user.

Wrong Password?

Important practices here:

• Never distinguish in your error messages between unknown username and unknown password. ONLY say “invalid credentials”. Otherwise you help the attacker with user enumeration.
• Never make a timing difference between bad username and bad password, otherwise, again, user enumeration is aided.
• Store a failed login attempt counter in a database. Lock out login attempts after a certain threshold has been reached. The lockout duration is up to you, but should be long enough to defeat brute forcing.

Identity Tokens

We need to minimize the use of credentials because the more these things are used, the more chances they have of being compromised. So rather than supplying a password on every request, the first presentation of valid credentials gets you a token. The token has your identity in it, and is hopefully signed. The token has a short lifetime, after which it needs to be refreshed, or it is destroyed and a new token obtained with the credentials.

MFA

Multi-Factor Authentication (MFA) is simply the requirement to authenticate with more than one factor (and they should be from different groups). Remember the groups?

• Something you KNOW: password, passphrase, PIN
• Something you HAVE: phone, physical key (USB), email address
• Something you ARE: face/voice/fingerprint/retina recognition

Generally it works like this:

1. User submits credentials from the KNOW group, like a password
2. System responds with “we‘ve sent a code to your device/mailbox.”
3. User goes to their device/email and uses the code. Using the code involves either:
   • Physically type the code (often a 6-digit number) into the original app
   • Clicking on a confirmation web link
   • Tapping a big green OK button

Important: These codes or links must be very short lived.

For convenience, and to make sure you get things right and efficient, MFA often uses third-party authenticators like Duo, Google Authenticator, or Microsoft Authenticator. Users install these on their device. Codes typically last only 30 seconds on these things.

Is this inconvenient?

Not really. The MFA really just kicks in the first time you login on a new computer or device. You just use tokens after that for a bit, until you hard logout or some other infrequent expiration event occurs.

Password Reset

What if a user forgets a password?

Send them a short-lived token to their verified email address with a link to a password-change landing page. That’s it. That’s how to do it.

On the forgot-password form, the user types in an email address. Regardless of whether the email is known or not, simply say “Thank you, we’ve sent an email that that address.” What should the email say? Something like “We’ve received a password reset request. If you did not request it, you can ignore this email. If it was you, visit [SUPER SHORT LIVED LINK] to enter your new password.”

SSO

Single Sign-on (SSO) allows one set of credentials to authenticate you for all the apps in a group. App groups are managed in an organization’s directory.

One-Time Password

This is like a 1FA using your mobile device. You ask to login and the app sends you a one-time-password (OTP) right to your phone which you use to log in, no password required. The session should be short-lived.

Password Reuse

You know, people use the same password across different sites. What can be done about this?

If Building Your Own Authentication System

You need to:

• Protect yourself from brute-force and rainbow attacks
• Make it hard for adversaries to do enumeration attacks
• If adversaries get password hashes, make sure they are hard to crack
• Know that attack vectors are everywhere: registration, login, password reset, etc.

In general:

• Hash and salt
• Require long, strong passwords from users
• Verify with slow hash
• Always respond to every kind of request THE SAME WAY regardless of whether a username/email exists or not, and regardless of whether provided credentials are correct or not
• On a password reset request, send an email (i.e., this takes the discussion out of the application and is 1-1 with the user in question)
• Be smart if you have a “remember me” feature
• Know best practices for cookies and tokens

Authorization

Sorry, this section has some terminology. You’ll need to know these five terms: user, group, role, permission, and policy. Three other useful terms are identity, resource, and session.

Start with permission. Oversimplifying, a permission is something like READ, WRITE, UPDATE, INSERT, SEARCH, FETCH, DELETE, LIST, or similar verb. A permission is granted to an identity for the access or modification of a specific resource or class of resources, possibly restricted in time, either for an explicit start time and duration or for a given session.

Okay so a resource is a file, storage bucket, object in a storage bucket, configuration, program, machine, and all kinds of similar things. And you can infer what a time range or session is. But what about an identity?

An identity, the thing that the permission is granted to, is usually just a user. But because a system can have millions of users and hundreds of thousands of permissions, assigning lists of permissions to each user individually, so we can assign roles to users, and then attach permissions to the roles! Roles can be things like SUPERUSER, ADMINISTRATOR, MEMBER, GUEST, WRITER, MODERATOR, PROVIDER, ANALYST, REVIEWER, and so on. You can also put users into groups like engineers, salespeople, interns, executives, and then assign roles to groups. And you can even do one-off assignments of specific permissions to individual users, roles, or groups.

A policy defines the assignments of permissions to users, roles, and groups.

Oh yeah, one more: a principal is a user or role, just not a group.

One way to learn more about all this is to study policies and permissions of a specific large system. Get started by reading about policies and permissions in Amazon Web Services. Follow links as you feel so moved.

Important best practices for authorization:

• Always do authorization checks SERVER-SIDE.
• Require login and logout whenever permissions change.
• Don’t allow impersonation models for customer support to happen at the authorization level; only do this at the authentication level.
• Check authorization for EVERY SINGLE transaction. Do not check just once and assume you’re good.
• Make sure your access control lists or permission matrices are well-documented and thoroughly reviewed, and that there are solid processes in place to modify them if necessary.
• Cover all permutations of roles and attempted operations in your test suites.

Table Of Differences

Review time!

Summary