SlideShare a Scribd company logo
© 2014VMware Inc. All rights reserved.
Introduction to Authentication
Cloud Identity Summit
Dale Olds
olds@vmware.com
Senior Staff Engineer, VMware
July 2014
An Introduction to Authentication
●
Authentication definition and
purpose
●
Authentication methods
●
Federated authentication
●
Emerging trends and future
directions
1. This presentation has been prepared
for identity newbies.
2. All heckling is encouraged.
3. Advanced hecklers, please see #1.
Definitions for Identity and Authentication Terms
From Open ID Connect Core 1.0, http://openid.net/specs/openid-connect-core-1_0.html
A Few Definitions for Starters
●
Entity – Something that has a separate and
distinct existence and that can be identified
in a context. An End-User is one example of
an Entity.
●
Identity – Set of attributes related to an
Entity.
●
Identifier – Value that uniquely characterizes
an Entity in a specific context.
●
Authentication – Process used to achieve
sufficient confidence in the binding between
the Entity and the presented Identity.
The Authentication Event
The ceremony that
establishes context
and security
(Pam's view)
Something to get past
quickly on the way to
something else (my view)
Why Do We Authenticate?
● Authentication is necessary for
authorization.
● Authentication of a user is necessary to
allow the user to DODO something.
● Authentication is the user in action
● Identity (user accounts) involves user
information at rest
● Provisioning involves managing identity
information by others.
“If you don't eat your meat, you can't
have any pudding. How can you
have any pudding if you don't eat
your meat?"
Pink Floyd (via Gil)
Why Do We Authenticate?
Photo by Emily Carlin, https://www.flickr.com/photos/cuttingboard/
To get to
authorization
Authentication Methods, and the Problems with Passwords
“Passwords are easy. Change is hard.”
-- Jeff Bohren
Protecting Password Data is Difficult
Source: http://blog.ircmaxell.com/2011/08/rainbow-table-is-dead.html
● Saving some password
data necessary so a
service can verify the
password, making it a
tasty target.
● It's an arms race with
the birds that want to
eat your lunch.
Problems with Passwords: Password Hash Needs Salt
Source: http://blog.ircmaxell.com/2011/08/rainbow-table-is-dead.html
● Saving passwords in clear text is obviously
dangerous if the password data is stolen.
● Save password hashes – non-reversible
fingerprint of the password means raw
passwords are not stored.
● Lookup tables, dictionary attacks and rainbow
tables can be used to efficiently crack large
amounts of hashed passwords.
● Using a unique, large salt value with each hash
renders rainbow tables much less effective.
● CPU/GPU capabilities have greatly increased.
Brute force cracking of passwords is feasible.
● Use hash algorithms such as Bcrypt to blunt
increase in CPU capability, and get users to use
larger passwords.
● And so it goes.
Problems with How Users Choose Passwords
Users use the same
password for multiple
sites.
Even “low value” sites
share password with
“high value” sites.
Passwords Should be Easy to Remember, Hard to Crack
Source: http://blog.ircmaxell.com/2011/08/rainbow-table-is-dead.html
● Four short words are easy to remember, and hard to
crack.
● Password policy for punctuation and special
characters just irritates the users and is very little
help against password cracking.
● Good open source projects exist that implement this
technique. See https://github.com/dropbox/zxcvbn and
http://blog.cloudfoundry.org/2012/11/07/password-policy-in-cloud-foundry/
● Not so good for mobile devices yet.
Password Anti-Pattern is STILL in Use
If you actually read the User Agreement above,
it's clear what the password anti-pattern
really means.
source: http://virtualsoul.org/blog/2012/10/11/password-anti-pattern-alive-and-well-at-a-financial-institution/
Password Problems are Even Misunderstood
● The problem was a key logger virus
● No password data was retrieved from
Facebook, Yahoo, Google, etc.
● The article's advice for password
length, character type, and
uniqueness is not applicable to a key
logger.
Beyond Passwords: Other Authentication Methods
● Password managers
● Smart Cards
● Multi-factor authentication systems
● SMS message and other call-backs
● The rise of FIDO
However, the evolution of authentication methods remains an arms race.
We need a way to manage changing authentication methods, and to manage
the evolution of authentication effectively...
Federated Authentication: Add a Level of Indirection
Speaking of Computer Science...
“There are two hard problems in computer
science: cache invalidation, naming things,
and off-by-one errors.”
– various unattributed sources
Old-School Federated Authentication with SAML
WebAppA
SAML Identity
Provider - IdP
Browser
WebAppB
WebAppC
1. Joe starts at
WebAppA but is
not logged in,
gets redirected to
SAML IdP.2. Joe logs in with method
known only to IdP. IdP saves
session with Joe (probably in
a cookie) and redirects back
to WebAppA with a SAML
artifact.
3. WebAppA gets the
SAML artifact.
5. When Joe accesses
WebAppB or WebAppC, they
redirect him to the IdP – which
already has a session with Joe
so he is immediately redirected
back with an artifact.
4. WebAppA exchanges the SAML artifact for a
SAML assertion via the back channel. It trusts
the SAML assertion from that IdP, sets up
session with Joe (probably with a cookie) and
grants access.
Modern, Cool Federated Authentication with OpenID Connect,
and Delegated Authorization via OAuth2
WebAppA
OIDC AuthZ
Server - AS
Browser
WebAppB
WebAppC
1. Joe starts at
WebAppA but is not
logged in, gets
redirected to OIDC
Authorization Server.2. Joe logs in with method
known only to AS. AS saves
session with Joe (probably in
a cookie) and redirects back
to WebAppA with an
OAuth2/OIDC authorization
code.
3. WebAppA gets the
OAuth2 authorization
code.
5. When Joe accesses
WebAppB or WebAppC, they
redirect him to the AS – which
already has a session with Joe
so he is immediately redirected
back with an authorization
code.
4. WebAppA exchanges the authorization code
for an ID token (and an access token) via the
back channel. It trusts the ID token from that AS,
sets up session with Joe (probably with a cookie)
and grants access.
Progress in Identity Evolution
One
identity
(user
account)
per
application
External
identities
via LDAP
External
authentication
via SAML
External
authentication
and roles via
OAuth2 and
OpenID
Connect
External
authorization
We are
here
Does Federated Authentication Need to be so Complex?
● I went to Starbucks and ordered a vente
coffee with cream with my VISA debit card.
● The VISA network contacted my bank,
which transmitted an authorization code to
Starbucks.
● The authorization code was used to
transfer funds to Starbucks from my
account.
● I enjoyed the latte.
● I pointed a browser at my employee
benefits site and selected our payroll
provider, ADP.
● The benefits site presented a SAML
artifact to ADP
● The artifact was used to retrieve an
assertion which authorized access to my
payroll information.
● I wish I made more money
Teenagers, most adults, and
supposedly tech-averse grandmothers
have no problem understanding this.
Programmers, technologists, and tech-
executives claim this is too difficult.
Advantages of Federated Authentication
● Fewer numbers of identity and
authentication sources means less exposure
(but also higher value targets of those
sources).
● Identity and authentication sources can
specialize in security – no need for casual
services like Gawker to handle passwords.
● Authentication methods can evolve with no
change to applications.
● Varying authentication methods can be
required for applications based on identity
provider policy.
● Better user experience (longer lived single
signon) with more control over revocation of
access.
● Partitioned security space – authentication
and role information is targeted to specific
services. No password anti-pattern.
Future Directions
● Authentication policy – including step-up
authentication, and re-authentication
intervals.
● Continuous authentication and risk
analysis.
● Shared signals.
Remember why we authenticate...
Photo by Angélica Portales, https://www.flickr.com/photos/frozen-in-time/
Shared Signals
Shared Signals
White Paper
at the Open
Identity
Exchange
http://oixuk.org/wp-content/uploads/2014/04/The-Shared-Signals-Model-1.pdf
Shared Signals
White Paper
at the Open
Identity
Exchange
http://oixuk.org/wp-content/uploads/2014/04/The-Shared-Signals-Model-1.pdf
Conclusion to Introduction to Authentication
●
Authentication definition and
purpose: to get to authorization
●
Authentication methods: evolve,
passwords suck, other methods
exist and are improving.
●
Federated authentication: helps us
handle authentication evolution,
provides better security with better
user experience.
●
Emerging trends and future
directions: continuous
authentication, shared signals

More Related Content

CIS14: Authentication: Who are You? You are What You Eat

  • 1. © 2014VMware Inc. All rights reserved. Introduction to Authentication Cloud Identity Summit Dale Olds olds@vmware.com Senior Staff Engineer, VMware July 2014
  • 2. An Introduction to Authentication ● Authentication definition and purpose ● Authentication methods ● Federated authentication ● Emerging trends and future directions
  • 3. 1. This presentation has been prepared for identity newbies. 2. All heckling is encouraged. 3. Advanced hecklers, please see #1.
  • 4. Definitions for Identity and Authentication Terms From Open ID Connect Core 1.0, http://openid.net/specs/openid-connect-core-1_0.html
  • 5. A Few Definitions for Starters ● Entity – Something that has a separate and distinct existence and that can be identified in a context. An End-User is one example of an Entity. ● Identity – Set of attributes related to an Entity. ● Identifier – Value that uniquely characterizes an Entity in a specific context. ● Authentication – Process used to achieve sufficient confidence in the binding between the Entity and the presented Identity.
  • 6. The Authentication Event The ceremony that establishes context and security (Pam's view) Something to get past quickly on the way to something else (my view)
  • 7. Why Do We Authenticate? ● Authentication is necessary for authorization. ● Authentication of a user is necessary to allow the user to DODO something. ● Authentication is the user in action ● Identity (user accounts) involves user information at rest ● Provisioning involves managing identity information by others. “If you don't eat your meat, you can't have any pudding. How can you have any pudding if you don't eat your meat?" Pink Floyd (via Gil)
  • 8. Why Do We Authenticate? Photo by Emily Carlin, https://www.flickr.com/photos/cuttingboard/ To get to authorization
  • 9. Authentication Methods, and the Problems with Passwords “Passwords are easy. Change is hard.” -- Jeff Bohren
  • 10. Protecting Password Data is Difficult Source: http://blog.ircmaxell.com/2011/08/rainbow-table-is-dead.html ● Saving some password data necessary so a service can verify the password, making it a tasty target. ● It's an arms race with the birds that want to eat your lunch.
  • 11. Problems with Passwords: Password Hash Needs Salt Source: http://blog.ircmaxell.com/2011/08/rainbow-table-is-dead.html ● Saving passwords in clear text is obviously dangerous if the password data is stolen. ● Save password hashes – non-reversible fingerprint of the password means raw passwords are not stored. ● Lookup tables, dictionary attacks and rainbow tables can be used to efficiently crack large amounts of hashed passwords. ● Using a unique, large salt value with each hash renders rainbow tables much less effective. ● CPU/GPU capabilities have greatly increased. Brute force cracking of passwords is feasible. ● Use hash algorithms such as Bcrypt to blunt increase in CPU capability, and get users to use larger passwords. ● And so it goes.
  • 12. Problems with How Users Choose Passwords Users use the same password for multiple sites. Even “low value” sites share password with “high value” sites.
  • 13. Passwords Should be Easy to Remember, Hard to Crack Source: http://blog.ircmaxell.com/2011/08/rainbow-table-is-dead.html ● Four short words are easy to remember, and hard to crack. ● Password policy for punctuation and special characters just irritates the users and is very little help against password cracking. ● Good open source projects exist that implement this technique. See https://github.com/dropbox/zxcvbn and http://blog.cloudfoundry.org/2012/11/07/password-policy-in-cloud-foundry/ ● Not so good for mobile devices yet.
  • 14. Password Anti-Pattern is STILL in Use If you actually read the User Agreement above, it's clear what the password anti-pattern really means. source: http://virtualsoul.org/blog/2012/10/11/password-anti-pattern-alive-and-well-at-a-financial-institution/
  • 15. Password Problems are Even Misunderstood ● The problem was a key logger virus ● No password data was retrieved from Facebook, Yahoo, Google, etc. ● The article's advice for password length, character type, and uniqueness is not applicable to a key logger.
  • 16. Beyond Passwords: Other Authentication Methods ● Password managers ● Smart Cards ● Multi-factor authentication systems ● SMS message and other call-backs ● The rise of FIDO However, the evolution of authentication methods remains an arms race. We need a way to manage changing authentication methods, and to manage the evolution of authentication effectively...
  • 17. Federated Authentication: Add a Level of Indirection
  • 18. Speaking of Computer Science... “There are two hard problems in computer science: cache invalidation, naming things, and off-by-one errors.” – various unattributed sources
  • 19. Old-School Federated Authentication with SAML WebAppA SAML Identity Provider - IdP Browser WebAppB WebAppC 1. Joe starts at WebAppA but is not logged in, gets redirected to SAML IdP.2. Joe logs in with method known only to IdP. IdP saves session with Joe (probably in a cookie) and redirects back to WebAppA with a SAML artifact. 3. WebAppA gets the SAML artifact. 5. When Joe accesses WebAppB or WebAppC, they redirect him to the IdP – which already has a session with Joe so he is immediately redirected back with an artifact. 4. WebAppA exchanges the SAML artifact for a SAML assertion via the back channel. It trusts the SAML assertion from that IdP, sets up session with Joe (probably with a cookie) and grants access.
  • 20. Modern, Cool Federated Authentication with OpenID Connect, and Delegated Authorization via OAuth2 WebAppA OIDC AuthZ Server - AS Browser WebAppB WebAppC 1. Joe starts at WebAppA but is not logged in, gets redirected to OIDC Authorization Server.2. Joe logs in with method known only to AS. AS saves session with Joe (probably in a cookie) and redirects back to WebAppA with an OAuth2/OIDC authorization code. 3. WebAppA gets the OAuth2 authorization code. 5. When Joe accesses WebAppB or WebAppC, they redirect him to the AS – which already has a session with Joe so he is immediately redirected back with an authorization code. 4. WebAppA exchanges the authorization code for an ID token (and an access token) via the back channel. It trusts the ID token from that AS, sets up session with Joe (probably with a cookie) and grants access.
  • 21. Progress in Identity Evolution One identity (user account) per application External identities via LDAP External authentication via SAML External authentication and roles via OAuth2 and OpenID Connect External authorization We are here
  • 22. Does Federated Authentication Need to be so Complex? ● I went to Starbucks and ordered a vente coffee with cream with my VISA debit card. ● The VISA network contacted my bank, which transmitted an authorization code to Starbucks. ● The authorization code was used to transfer funds to Starbucks from my account. ● I enjoyed the latte. ● I pointed a browser at my employee benefits site and selected our payroll provider, ADP. ● The benefits site presented a SAML artifact to ADP ● The artifact was used to retrieve an assertion which authorized access to my payroll information. ● I wish I made more money Teenagers, most adults, and supposedly tech-averse grandmothers have no problem understanding this. Programmers, technologists, and tech- executives claim this is too difficult.
  • 23. Advantages of Federated Authentication ● Fewer numbers of identity and authentication sources means less exposure (but also higher value targets of those sources). ● Identity and authentication sources can specialize in security – no need for casual services like Gawker to handle passwords. �� Authentication methods can evolve with no change to applications. ● Varying authentication methods can be required for applications based on identity provider policy. ● Better user experience (longer lived single signon) with more control over revocation of access. ● Partitioned security space – authentication and role information is targeted to specific services. No password anti-pattern.
  • 24. Future Directions ● Authentication policy – including step-up authentication, and re-authentication intervals. ● Continuous authentication and risk analysis. ● Shared signals. Remember why we authenticate... Photo by Angélica Portales, https://www.flickr.com/photos/frozen-in-time/
  • 26. Shared Signals White Paper at the Open Identity Exchange http://oixuk.org/wp-content/uploads/2014/04/The-Shared-Signals-Model-1.pdf
  • 27. Shared Signals White Paper at the Open Identity Exchange http://oixuk.org/wp-content/uploads/2014/04/The-Shared-Signals-Model-1.pdf
  • 28. Conclusion to Introduction to Authentication ● Authentication definition and purpose: to get to authorization ● Authentication methods: evolve, passwords suck, other methods exist and are improving. ● Federated authentication: helps us handle authentication evolution, provides better security with better user experience. ● Emerging trends and future directions: continuous authentication, shared signals