Authentication Concepts

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
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
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
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.

● 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?

Authentication Concepts

Recommended

More Related Content

What's hot (20)

Viewers also liked (8)

Similar to Authentication Concepts (20)

More from Charles Southerland (11)

Recently uploaded (20)

Authentication Concepts