Authentication Concepts

Charles Southerland

Information Warfare● Summit 7

October 1, 2014

The Three “A”s

●Authentication●Authorization●Accounting / Audting

Accounting / Auditing

● Log absolutely everything.

● Know what is in your logs.

● Protect your logs.

● See my IWS talk from last year.

Accounting / Auditing

● Log absolutely everything.

● Know what is in your logs.

● Protect your logs.

● SHAMELESS PLUG:See my IWS talk from last year.

Authorization

● Authorization is the process of determining and enforcing which privileges an authenticated entity has.

● Most people use Access Control Lists to keep track of which entities have which privileges

Authentication != Authorization

It is considered best practice to separate authentication from authorization so that

authorization can be easily managed without fear of accidentally weakening the

authentication system and vice versa.

This is generally accomplished by keeping a username and password database used for

authentication separate from the collection of access control lists used for authorization.

Authentication

Authentication is the process of verifying that entities truly are what they identify themselves as.

Username-Only Systems

● Without authentication, anyone would be able to lie about their identity.

● There would be no accountability and no effective security.

Password-Only Systems

● Unfortunately, a flawed authentication system can be about as bad as no authentication system at all.

Most Authentication Systems

● The vast majority of authentication systems are based on a username and password.

● ANOTHER SHAMELESS PLUG:My IWS talk from 2011 has some suggestions on how to approach passwords.

Password Storage

● As a password is only used for authentication, only a hash of the password must be stored, not the password itself.

● FINAL SHAMELESS PLUG:My IWS talk from 2012 covers how to deal with passwords correctly.

Credentials

More generally, authentication is accomplished through the verification of certain authentication credentials that an

entity may have access to.

Usernames and passwords are two common types of authentication

credentials, but there are also other types of authentication credentials.

API Tokens

● Another type of authentication credential is an API token, which generally allows a third-party application to access certain functionality programmatically.

● It may be an appropriate option in some cases,but it is awfully similar to the password-only system.

OpenID / OAuth

● OpenID is a system that uses URLs from third-party websites as an authentication credential.

● OAuth is a system that allows the server to communicate with one of a few providers to obtain, among other things, authentication credentials for a user.

Cookies

● A cookie is an authentication credential that is managed by the browser and automatically sent to the server with every request.

Captcha

● A captcha is an authentication credential that tries to verify that a user is a human and not a program.

Simple Browser Fingerprint

● A simple browser fingerprint (user agent string, some HTTP behavior) is often used as an authentication credential when cookies aren't available for some reason.

Advanced Browser Fingerprint● When simple browser

fingerprinting is not enough, more advanced techniques are sometimes used.

● Sites can use a Flash cookie as an authentication credential.

● Recently there have been news articles about some sites which use canvas rendering behaviors as an authentication credential.

IP Address

● A popular authentication credential with some administrators is the IP address of the computer attempting to authenticate.

Client-Side SSL

● In my opinion, a client-side SSL certificate can make for a particularly good authentication credential in addition to providing improved transport security.

Multi-Factor Token● An increasingly popular

authentication credential is a multi-factor authentication token.

● In addition to the iconic RSA key fobs and the increasingly popular RFC6238-based systems (like Google Authenticator), providers like Yubico, Toopher, Duo, and Transakt are having more mainstream adoption.

● Unfortunately, my own multi-factor system is still on the back-burner

Stateful Credentials

Some credentials have a specific relationship to the state of the client and/or server.

XSRF Tokens● Cross-site request forgery

is a technique often used in phishing in order to perform actions and/or request data while authenticated using the stored browser cookie.

● An XSRF token is an authentication credential that is required for the next form submission to be accepted.

Anonymous Cookies

● Nowadays, almost all websites will send the browser a cookie as soon as they connect so that they can begin tracking behavior as quickly as possible.

● When this cookie is first received, the only information associated with it is that the browser did not just arrive for the first time.

Cookie Re-association

● Should the user log in, the state of this authentication credential will change from being associated with an anonymous browser to being an associated with an authenticated user.

Partially De-authenticated Cookie

As another example of a stateful authentication credential, if a user were accessing a website for some time after having authenticated, it may be permissable to continue to browse the site, but their cookie has changed state to the point where it will be necessary to re-authenticate before, e.g., purchasing an item or sending an email, whereas these actions would not have required re-authentication before the threshold had passed.

Credential Dependencies

● In some cases, credentials can be thought of as depending on other pre-requisite credentials.

Unsalted Password Hashes

● Even unsalted password hashes have dependencies: namely, the password.

● DON'T FORGET:If you use unsalted password hashes, you will be vulnerable to rainbow tables.

Salted Password Hashes● The salted password

hash depends on having access to the password and the per-user salt (another authentication credential).

● Access to the per-user salt depends on having the username.

● You could even consider having access to the database credentials as yet another dependency.

Typical Setup of Today

● An anonymous cookie is used from the beginning (in paywalls, the cookie even changes state).

● To login, the cookie is provided along with the XSRF token, the username, and the password.

● The username gets the salt, the salt and password get the hash, and if the hash matches and if the XSRF token corresponds to the cookie's, then the user is logged in.

Multi-Credential Login

● In more secure systems, even more authentication credentials are required at the same time.

● It is not uncommon for some sites' login systems to depend on most of the following credentials

simultaneously: a username, a password, a cookie, an XSRF token, a captcha, a multi-factor token, an IP

address, a browser fingerprint, and a canvas fingerprint.

Virtual Credentials

● It can be convenient to think of certain combinations of stateful credentials as being the dependencies for a kind of virtual credential.

● For example, whatever specific combination of those credentials can be thought of as the dependencies for the “logged in” credential.

Region Blocking

● In some cases, specific IP address ranges can help to authenticate whether a user is in a particular geographic area.

● Hmm... some of these more complicated authentication concepts look like authorization, and that's bad, right?

The Blurry Line

Now consider a web app that allows you to behave as an end user once you've logged

in, but in order to behave as an administrator, you must be logged in and

come from a specific IP address.

Is this authentication or authorization?

Even Blurrier

Now what if instead of coming from a specific IP address, you were required to

use whatever multi-factor token you've set up?

Especially given the notion of virtual credentials, couldn't authorization simply

be a matter of authenticating some specific virtual credential with some specific set of

credential dependencies?

But You Said We Should Use ACLs!

● You could shoehorn some level of awareness of these authentication ideas into your ACLs.

● Unfortunately, that would likely make your ACLs nightmarishly complex, thus defeating the purpose of ACLs.

Authorization as Virtual Credentials● If we instead look at

authorization as nothing more than virtual credentials, then access to resources would simply be a matter of authenticating these virtual credentials.

● The equivalent function of ACLs would then be encoded in the dependencies of virtual credentials and group membership.

Example (Part 1)

A user goes to a website, where they are given a cookie.

The recorded IP address, the browser fingerprint, and the cookie now give them the virtual credential of “anonymous user”.

This virtual credential authorizes them to access various pages on the website.

Example (Part 2)

● The user then goes to the login page, where they are given an XSRF token that will be associated with their cookie.

● The IP address, the browser fingerprint, and (obviously) the cookie are still checked every single request to continue to authenticate the user.

Example (Part 3)

● The user enters their username, password, and MFA token into the login form and submits it.

● The server immediately checks that the IP address, the browser fingerprint, the cookie, and the XSRF token all match, and if they do, the user now has the virtual credential for “authorized form submission”.

Example (Part 4)

● Since the user has the “authorized form submission” credential, the server uses the username to request the per-user salt from the database.

● The server then uses the password and the per-user salt to get the calculated salted password hash.

Example (Part 5)

● The server then uses the username to request the stored salted password hash from the database.

● If the calculated salted password hash matches the stored salted password hash, then the user has the virtual credential for “first-factor authenticated”.

Example (Part 6)

● The server uses the username to request the MFA key from the database.

● The server uses the MFA key and the timestamp to calculate the expected MFA token.

● If the expected MFA token matches the MFA token supplied by the user, the user will have the virtual credential for “second-factor authenticated”.

Example (Part 7)

● Since the user has the “first-factor authenticated” and “second-factor authenticated” virtual credentials, the user now has the “multi-factor authenticated” virtual credential.

● The user can browse the site so long as the IP address, browser fingerprint, and cookie match, and as long the time since acquiring the “multi-factor authenticated” credential is less than 25 minutes.

Example (Part 8)● Suppose the user is also a moderator.

Then their name would be in the “moderators” group.

● Whenever the user goes to a part of the site that requires moderator priveleges, all that is necessary is for that part of the site to verify that the user has the “moderator” virtual credential, which it can do by checking that it has the “multi-factor authenticated” virtual credential and the “moderators group member” credential.

In Conclusion...

● It is important not to use terrible authentication systems.

● When using the ACL approach, do separate authentication and authorization.

Some stateful authentication credentials are standard practice now.

● In my opinion, complex authentication requirements would be better off without ACLs.

● I'm considering making a portable, extensible, lightweight implementation to be dropped in for simple web apps... any interest?

Questions?