Downloaded 36 times
![#RSAC
OpenID Connect id_token
18
Information about
authentication event
{
"iss": "https://server.example.com",
“sub": "248289761001",
"aud": "3214244",
"iat": 1311195570,
"exp": 1311281970,
“auth_time”: 131195001,
“acr”: http://example.com/basic_bio”
“amr”: [‘eye’, ‘pwd’, ‘12’]
}](https://image.slidesharecdn.com/idy-f02-dont-use-two-factor-authentication-unless-you-need-it-160303175454/85/RSA-Conference-2016-Don-t-Use-Two-Factor-Authentication-Unless-You-Need-It-18-320.jpg)
![#RSAC
id_token
23
Returned id_token
confirms acr and amr
values
{
"iss": "https://server.example.com",
“sub": "248289761001",
"aud": "3214244",
"iat": 1311195570,
"exp": 1311281970,
“auth_time”: 131195001,
“acr”: http://example.com/basic_bio”
“amr”: [‘eye’, ‘pwd’, ‘12’]
}](https://image.slidesharecdn.com/idy-f02-dont-use-two-factor-authentication-unless-you-need-it-160303175454/85/RSA-Conference-2016-Don-t-Use-Two-Factor-Authentication-Unless-You-Need-It-23-320.jpg)
Uploaded byMike Schwartz
RSA Conference 2016: Don't Use Two-Factor Authentication... Unless You Need It!
The document discusses the importance of two-factor authentication (2FA) and multi-factor authentication in enhancing security, emphasizing the need for standardized API usage for trust elevation and the challenges associated with deploying these methods. It also highlights the role of OAuth2 in making 2FA more deployable and the necessity of collaboration among domains to align on authentication standards. Finally, the document advocates for broader trust elevation strategies beyond just 2FA to enhance overall security in applications.
More Related Content
Similar to RSA Conference 2016: Don't Use Two-Factor Authentication... Unless You Need It!
RSA Conference 2016: Don't Use Two-Factor Authentication... Unless You Need It!
- 1.
- 2. #RSAC Obama says usetwo factors… 2 https://nakedsecurity.sophos.com/2016/02/12/obama-says-passwords-arent-strong-enough-urges-use-of-2fa/
- 3. #RSAC Progress = Obliviousness 3 2FA= two-factor authentication
- 4.
- 5. #RSAC Protect your money! 5 Issuedguidance in 2005 entitled “Authentication in an Internet Banking Environment“ Source: https://www.ffiec.gov/pdf/Auth-ITS-Final%206-22-11%20(FFIEC%20Formated).pdf “… the techniques employed should be commensurate with the risks associated with the products and services offered ”
- 6. #RSAC What is TrustElevation? 6
- 7. #RSAC Agenda 7 Background on authenticationtechnology: where are we today? Deep Dive into OAuth2: what features does it have to support Trust Elevation Trust Elevation across domain boundaries GOAL: Make you aware of some of the challenges we face to enable Trust Elevation
- 8. #RSAC What is Multi-FactorAuthentication? 8 NIST defines this as two or more of … Something you know Something you have Something you are Source: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf
- 9.
- 10. #RSAC Contextual Combinations Complicate 10 Isthe IP address a known hacker? Was the device rooted? Is a browser cookie present? Is the device running virus protection? Is the location recognized? When was credential issued? What is the time of the day?
- 11. #RSAC “…every scheme doesworse than passwords on deployability” 11 http://research.microsoft.com/pubs/161585/QuestToReplacePasswords.pdf
- 12. #RSAC OAuth2 will make2FA more “deployable” 12 Applications should use Standard API’s for authentication and Trust Elevation! No “one-offs” http://nordicapis.com/api-security-oauth-openid-connect-depth/ Good Intro to Oauth2:
- 13. #RSAC Enter OAuth2 13 i.e. API’s i.e.Website or mobile app i.e. Secure Token Service
- 14. #RSAC OpenID Connect 14 Resource Server= user_info API To call this API, you need an Access Token TOKENTOKEN
- 15.
- 16. #RSAC OpenID Connect: Client Registration,Discovery too! 16 http://openid.net/connect
- 17. #RSAC Overview of AuthorizationCode Flow 17 Relying Party (RP) redirects person to OpenID Provider (OP) for authorization Authentication happens only once! OP returns code to RP RP uses code to get tokens from OP RP uses access token to obtain user claims from /user_info API: {“given_name”: “Mike”, “family_name”: “Schwartz”}
- 18. #RSAC OpenID Connect id_token 18 Informationabout authentication event { "iss": "https://server.example.com", “sub": "248289761001", "aud": "3214244", "iat": 1311195570, "exp": 1311281970, “auth_time”: 131195001, “acr”: http://example.com/basic_bio” “amr”: [‘eye’, ‘pwd’, ‘12’] }
- 19. #RSAC ACR and AMR 19 Howdoes the app know what kind of authentication happened?
- 20. #RSAC OpenID Provider Discovery 20 GEThost + /.well-known/openid-configuration
- 21. #RSAC OpenID Dynamic ClientRegistration 21
- 22. #RSAC Authentication Request 22 In therequest, acr_values is actually a space delimited string…
- 23. #RSAC id_token 23 Returned id_token confirms acrand amr values { "iss": "https://server.example.com", “sub": "248289761001", "aud": "3214244", "iat": 1311195570, "exp": 1311281970, “auth_time”: 131195001, “acr”: http://example.com/basic_bio” “amr”: [‘eye’, ‘pwd’, ‘12’] }
- 24. #RSAC App Policy 24 GET https://example.com/finance Justan example… using OpenID Connect alone, you could require a certain type of authentication
- 25. #RSAC Best Practice: Centralize PolicyManagement 25
- 26. #RSAC UMA 26 Protect any API: requirean RPT Token
- 27. #RSAC UMA In 60seconds 27 Client Calls API without RPT Token RS obtains Permission Ticket from AS and returns it to Client Client presents ticket to AS AS evaluates polices. If ok, issues RPT token (bearer) Client calls API with RPT Token RS introspects Token: if ok, returns content
- 28. #RSAC Subtle difference… Scope referencespolicy 28 Scope based access: Level of abstraction that enables the central policy decision point to decide which acr is required
- 29. #RSAC What kind ofpolicies can you make? 29
- 30. #RSAC Elevating Trust usingUMA 30 You are Forbidden because you need acr…
- 31.
- 32. #RSAC Part III: Intedomaintrust elevation 32 Infrastructure and security is not (usually) basis for competition between firms in the same industry.
- 33.
- 34. #RSAC Many SAML Federationspublish user schema. 34 http://www.incommon.org/federation/attributesummary.html
- 35. #RSAC Oauth2 schema: notjust user claims… 35
- 36. #RSAC Collaboration on ACR/ AMR values 36 So what values should we use for amr and acr? https://tools.ietf.org/html/draft-jones-oauth-amr-values-05 This IETF draft defines some AMR’s… but its inadequate
- 37. #RSAC ACR alignment 37 Domains needto collaborate on the values for acr’s and amr’s
- 38. #RSAC OTTO – KantaraInitiative Work Group 38 http://kantarainitiative.org/confluence/display/OTTO/Home Open Trust Taxonomy for OAuth2
- 39.
- 40. #RSAC OAuth2 has newentities and new jargon 40
- 41. #RSAC Where do weneed federations 41
- 42. #RSAC Summary 42 We don’t lackways to identify people, but we lack agreement on the relative strength of these mechanisms. OAuth2 enables centralized risk based trust elevation, driving down the cost of deployment—the main impediment to 2FA adoption. To enable trust elevation across domains, federations are needed.
- 43. #RSAC Action items 43 Don’t limityour planning to two-factor authentication. Make a plan for trust elevation! Start architecting your applications to leverage central policy decision point—not for all fine grained authorization, but for key security escalations. If you work in an ecosystem, consider collaborating (even with your competitors) to drive down the cost of security.
- 44.
Editor's Notes
- #3 For the first time, the President of the United States advised citizens to use two-factor authentication. But he didn’t say when to use two factor authentication… Let’s face it… two factor authentication is a pain in the butt. I don’t want to get a SMS every time I turn on my TV. Ideally, I’d like to use two factor authentication never! I’d like my devices to just know who I am!
- #5 But there is a tradeoff between security, usability, and cost (or deployability). If there was a technology out there that was really secure, super easy to use, and cheap… we’d be using it. In fact, in many ways, passwords offer one of the most attractive triangles out there today.
- #6 Internet banking has always been at the forefront of digital person identification. Know your customer is the first rule of banking, but how do you know someone when they show up at your branch as a stream of electrons? Not surprisingly, banks have been at the forefront of what we call “trust-elevation”. For example, you may login with a password, but when you add a new wire recipient, maybe you receive a text. That’s text is a simple example of trust elevation– its because the bank wants to be even more sure its you.
- #7 There is a technical committee at OASIS, a standards organization, who is working on standards for Trust-Elevation. They came up with this definition. Its sort of a weird oxymoronic definition… but it works. They want to increment the decrementing of risk. But this is actually a very useful definition—notice it doesn’t assume we ever know who the person is. We only can reduce the risk that its not the person we think it is… no authentication technique is 100%. On the Internet, we’re basically never really sure its you!
- #9 We have a lot of technology to identify a person. I’m not going to go into it here. Check out my slides from the talk I gave on Monday where I detailed about 80 tricks we can use to authenticate a person. Let’s just say that we don’t have any shortage of technologies for person authentication. I assure you… the reason everyone is still using passwords is not because no one can think of some better way!
- #10 In addition to the classic “what you know”, “what you have”, “what your are” techniques, today we can mitigate a lot of risk by looking at the context of an authentication. Perhaps we have a positive biometic authentication, but the ip address indicates that the person is in a foreign country, and that it’s an IP address used recently by a known hacker.
- #11 So if you ever hoped to create some kind of uber-matrix, where you rate the various types of authentication, and how good they are…. Its really impossible. First of all, individual types are not the same. How complex is the password? How sensitive is the fingerprint scanner? Etc. etc. etc…. And how does fingerprint + password compare relative to mobile token + fraud detection?
- #12 So with all these techniques for person identification available to us? Why are we still using passwords at almost every website and mobile application? It goes back to cost? Cost is a big part of deployability. There was no license fee for passwords. It was easy for developers to implement. Users understand passwords—they aren’t going to call your help desk because they don’t undertand how to use it. And it was inexpensive to automate password recovery—support costs are low.
- #13 To justify the cost of two-factor authentication, we’re going to have to make sure its used by a lot of applications. This is where OAuth2 come in.