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, e.g., password, passphrase, PIN
• Something you HAVE, e.g., phone, physical key (USB), email address
• Something you ARE, e.g., 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, e.g., password, passphrase, PIN
• Something you HAVE, e.g., phone, physical key (USB), email address
• Something you ARE, e.g., 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!

Auth in Webapps

Kyle’s tour of permission systems:

Recall Practice

Here are some questions useful for your spaced repetition learning. Many of the answers are not found on this page. Some will have popped up in lecture. Others will require you to do your own research.

1. Which of authentication and authorization is concerned with users proving they are who they say they are?
   Authentication.
2. Which of authentication and authorization is concerned with managing permissions?
   Authorization.
3. Access control lists are examples of ________________?
   Authorization.
4. What does IAM stand for?
   Identity and Access Management.
5. What are the three major factors that can be used to authenticate a user?
   Something you KNOW
   Something you HAVE
   Something you ARE.
6. What attack is sufficient against short passwords?
   Brute-Force Attack
7. What attack is used to guess passwords that takes into account the fact that some passwords are more common than others?
   Dictionary Attack
8. Should user passwords ever be stored encrypted? Why or why not?
   NO! Never store them encrypted. Encrypting something implies that you can decrypt it and you never need to know a user’s password. Hash it instead.
9. Why must password hashing algorithms be slow?
   To drastically reduce the number of password cracking attempts per second
10. Why must you salt password hashes?
    If you don’t salt, everyone with the same password gets the same hash, and attackers can make note of the frequency of hashes to assist in cracking, and compromise more users if a commonly-appearing hash is inverted.
11. What is a common attack used against unsalted hashes that is more efficient than the brute-force or dictionary attack?
    Rainbow Attack
12. Why do many systems use a shadow password file?
    The original /etc/passwd file on Unix systems contained the password hash and was world-readable; these days it does not, and the actual hash is now kept in a (shadow) location readable only by a superuser.
13. What are the three major security steps to do when accepting user names and passwords?
    1. Don’t use separate error messages for bad usernames and bad passwords
    2. Don’t allow timing differences between error responses for bad usernames and bad passwords
    3. Implement rate limiting (such as lockout after a certain number of failed attempts) to prevent brute-force attacks
14. Why are identity tokens important?
    Identity tokens are important because they allow a system to verify the identity of a user or service without repeatedly asking for primary credentials.
15. What is MFA?
    MFA stands for Multi-Factor Authentication, which requires users to provide two or more verification factors to gain access to a resource.
16. How does MFA generally work?
    A user first submits something they know, then the system sends a very short-lived code to something they have, which they must enter to complete the authentication process.
17. How is password reset typically implemented?
    By sending a secure, time-limited link to the user's registered email address, allowing them to set a new password without exposing the old one.
18. What is an OTP?
    OTP stands for One-Time Password, which is a password that is valid for only one login session or transaction.
19. Do most security experts recommend password managers these days?
    Yes. The risk of losing the single password to the vault or password manager, while indeed catastrophic, can be made extremely low, while the odds of losing one or more of your 50 varying credentials that are kept who knows where will always be much higher.
20. What is a permission?
    A specific access right granted to an identity (user or system), allowing them to perform certain actions on a resource.
21. What is a session, in the context of authorization?
    A unit of time in which an authorization grant applies.
22. Why are roles used in authorization?
    Roles group permissions together, making it easier to manage and assign access rights to users.
23. How are groups different from roles?
    Groups are collections of users, while roles are collections of permissions. Groups can be assigned roles to grant permissions to all members.
24. What is a policy?
    A set of rules that define what actions are allowed or denied for a particular identity or group of identities.
25. What are some best practices for authorization?
    Check server side; check on every request; principle of least privilege; force logout on permission change; maintain and review ACLs; full coverage of all permutations in unit test suites.

Summary