CIS14: Authentication: Who are You? You are What You Eat
1 like1,011 views
The document is a presentation on authentication, covering definitions, methods, and trends in the field. It highlights the significance of authentication for authorization, the challenges associated with passwords, and various alternatives to password-based authentication. The presentation also discusses federated authentication and its advantages, as well as emerging trends like continuous authentication and shared signals.
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/
- 25. Shared Signals
- 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