OAuth: When Things Go Wrong - Oktane19

OAuth: When Things Go Wrong - Oktane19

11954e59b49809173d48133ec4047fce?s=128

Aaron Parecki

April 03, 2019
Tweet

Transcript

  1. Aaron Parecki OAuth: When Things Go Wrong @aaronpk

  2. This presentation contains “forward-looking statements” within the meaning of the

    “safe harbor” provisions of the Private Securities Litigation Reform Act of 1995, which include, but are not limited to, statements regarding our financial outlook, product development, business strategy and plans, and market trends, opportunities and positioning. These forward-looking statements are based on current expectations, estimates, forecasts and projections. Words such as “expect,” “anticipate,” “should,” “believe,” “hope,” “target,” “project,” “goals,” “estimate,” “potential,” “predict,” “may,” “will,” “might,” “could,” “intend,” “shall” and variations of these terms or the negative of these terms and similar expressions are intended to identify these forward-looking statements, although not all forward-looking statements contain these identifying words. Forward-looking statements are subject to a number of risks and uncertainties, many of which involve factors or circumstances that are beyond Okta’s control. In particular, the following factors, among others, could cause results to differ materially from those expressed or implied by such forward-looking statements: the market for our products may develop more slowly than expected or than it has in the past; quarterly and annual operating results may fluctuate more than expected; variations related to our revenue recognition may cause significant fluctuations in our results of operations and cash flows; assertions by third parties that we violate their intellectual property rights could substantially harm our business; a network or data security incident that allows unauthorized access to our network or data or our customers’ data could harm our reputation, create additional liability and adversely impact our financial results; the risk of interruptions or performance problems, including a service outage, associated with our technology; intense competition in our market; weakened global economic conditions may adversely affect our industry; the risk of losing key employees; changes in foreign exchange rates; general political or destabilizing events, including war, conflict or acts of terrorism; our ability to successfully identify and integrate acquisitions, strategic investments, partnerships or alliances; our ability to pay off our senior convertible notes when due; and other risks and uncertainties. Past performance is not necessarily indicative of future results. Further information on potential factors that could affect Okta’s financial results is included in its Annual Report on Form 10-K for the year ended January 31, 2019 and other filings with the Securities and Exchange Commission that are posted on investor.okta.com. Any unreleased products, features or functionality referenced in this or other presentations, press releases or public statements are not currently available and may not be delivered on time or at all. Product roadmaps do not represent a commitment, obligation or promise to deliver any product, feature or functionality. Customers who purchase our products should make their purchase decisions based upon features that are currently generally available. The forward-looking statements contained in this presentation represent the Company’s estimates and assumptions only as of the date of this presentation. Okta assumes no obligation and does not intend to update these forward-looking statements whether as a result of new information, future events or otherwise. This presentation contains estimates and other statistical data that we obtained from industry publications and reports generated by third parties. These data involve a number of assumptions and limitations, and you are cautioned not to give undue weight to such estimates. Okta has not independently verified the statistical and other industry data generated by independent parties and contained in this presentation and, accordingly, Okta cannot guarantee their accuracy or completeness. Expectations, estimates, forecasts and projections are subject to a high degree of uncertainty and risk. Many factors, including those that are beyond Okta’s control, could cause results or outcomes to differ materially from those expressed in the estimates made by the independent parties and by Okta. Safe Harbor Statement
  3. Disclaimer: This presentation does not necessarily reflect
 the views of

    Okta. The examples given here are not meant to 
 pick on any one company in particular.
  4. oauth.net

  5. None
  6. @aaronpk

  7. What is OAuth? And Why Does It Matter?

  8. THE PASSWORD ANTI-PATTERN

  9. THE PASSWORD ANTI-PATTERN facebook.com ~2010

  10. @aaronpk

  11. @aaronpk the app can't just get access to the user's

    data directly
  12. @aaronpk the app isn't allowed to ask for the user's

    password and use it
  13. @aaronpk so... how can I let an app access my

    data without giving it my password?
  14. @aaronpk Connect with Google https://yelp.com/

  15. @aaronpk the app needs to ask the user for an

    access token
 which it can use with the API password
  16. @aaronpk POST /resource/1/update HTTP/1.1 Authorization: Bearer RsT5OjbzRn430zqMLgV3Ia Host: api.authorization-server.com description=Hello+World

  17. @aaronpk A HOTEL KEY CARD, FOR APPS

  18. How OAuth Works

  19. @aaronpk ROLES IN OAUTH OAuth Server (Authorization Server) aka the

    token factory API (Resource Server) The Application (Client) The User's Device (User Agent)
  20. User: I’d like to use this great app App: Please

    go to the authorization server to grant me access User: I’d like to log in to “The Best App Ever”, it wants to access my photos AS: Here is a temporary code the app can use App: Here is the temporary code, and my secret, please give me a token User: Here is the temporary code, please use this to get a token AS: Here is an access token! App: Please let me access this user’s data with this access token! User Agent App OAuth Server API
  21. Front Channel Back Channel https://accounts.google.com/?... Passing data via the browser's

    address bar The user, or malicious software, can modify the requests and responses Sent from server to server Code is run on a server, not on the user's computer, so requests cannot be tampered with
  22. Back Channel Benefits ‣ The application knows it's talking to

    the right server ‣ Connection from app to server can't be tampered with ‣ Response from the server can be trusted because it came back in the same connection
  23. OAuth Server OAuth Client Passing Data via the Back Channel

  24. OAuth Server OAuth Client access token! Passing Data via the

    Front Channel
  25. Front Channel Benefits https://accounts.google.com/?... ‣ The user being involved enables

    them to give consent ‣ Doesn't require the receiver to have a publicly routable IP
 (e.g. can work on a phone)
  26. Front-Channel Risks ▸ The sender has no guarantee the receiver

    will get the data
 e.g. if the redirect is intercepted ▸ The data is written to the browser history
 which may be synced to "the cloud" or other devices Any data received via the front channel must be verified before it is used!
  27. What Can Go Wrong?

  28. What Can Go Wrong with OAuth? ▸ Lots! ▸ Stolen

    API Keys ▸ Stolen Access Tokens ▸ Redirect URL Interception ▸ Phishing ▸ ... and more
  29. RFC 6749 Section 10 RFC 8252 Section 8 RFC 6819

    draft-ietf-oauth-security-topics What can go wrong with OAUTH?
  30. @aaronpk TWITTER STOLEN API KEYS

  31. @aaronpk 2013

  32. @aaronpk

  33. @aaronpk ANYONE CAN 
 IMPERSONATE 
 THE TWITTER APPS

  34. @aaronpk DON'T PUT SECRETS
 IN NATIVE APPS! https://developer.okta.com/blog/2019/01/22/oauth-api-keys-arent-safe-in-mobile-apps

  35. @aaronpk PKCE PROOF-KEY FOR CODE EXCHANGE RFC 7636 (pronounced "pixie")

  36. @aaronpk PKCE PKCE Authorization Code Flow

  37. OAuth Server (Authorization Server) API (Resource Server) The Best App

    Ever User: I’d like to use this great app App: Please go to the authorization server to grant me access, take this hash with you User: I’d like to log in to this app, here's the hashed secret it gave me AS: Here is a temporary code the app can use App: Here's the code, and the plaintext secret, please give me a token User: Here is the temporary code, please use this to get a token AS: Let me verify the hash of that secret... ok here is an access token! App: Please let me access this user’s data with this access token! App: Hang on while I generate a new secret and hash it
  38. @aaronpk AppAuth.io iOS / Android / JavaScript

  39. @aaronpk FACEBOOK STOLEN ACCESS TOKENS improperly issued

  40. @aaronpk 2018

  41. @aaronpk https://newsroom.fb.com/news/2018/09/security-update/ The vulnerability was the result of the interaction

    of three distinct bugs:
  42. @aaronpk https://newsroom.fb.com/news/2018/09/security-update/ The vulnerability was the result of the interaction

    of three distinct bugs:
  43. @aaronpk https://newsroom.fb.com/news/2018/09/security-update/ The vulnerability was the result of the interaction

    of three distinct bugs: ??!
  44. @aaronpk By using the "View As" feature to see what

    your profile looks like to someone else, you would end up with an access token belonging to that user, which had the permissions of the Facebook mobile app.
  45. @aaronpk Treat components of your application
 the same way you'd

    treat third-party applications
  46. @aaronpk JWT ALG=NONE photo by flickr.com/quidox

  47. @aaronpk 2015

  48. An Example JWT eyJraWQiOiJvQ1JjR3RxVDhRV2tJR0MyVXpmcEZUczVqSkdnM00zSTNOMHgtZDJhSFNNIiwiYW xnIjoiUlMyNTYifQ.eyJ2ZXIiOjEsImp0aSI6IkFULkp3eVRTcTlqNDU0bDNTNmRTM1VTV1hMV VpwekdKdWNSd1ZEbFZCNWNIc3cuVVM1V1NGYVFiQllUMC9GM2tjMG8vK1ZUY3VZZzdwVnZqZXZ TT3hkUHhCMD0iLCJpc3MiOiJodHRwczovL2Rldi0zOTYzNDMub2t0YXByZXZpZXcuY29tL29hd XRoMi9kZWZhdWx0IiwiYXVkIjoiYXBpOi8vZGVmYXVsdCIsImlhdCI6MTU0MzgwMzAyNSwiZXh wIjoxNTQzODA2NjI1LCJjaWQiOiIwb2FoenBwM3RjcEZyZmNXSTBoNyIsInVpZCI6IjAwdWkwZ mpraWV5TDQ2bWEwMGg3Iiwic2NwIjpbIm9mZmxpbmVfYWNjZXNzIiwicGhvdG8iXSwic3ViIjo

    iaW5xdWlzaXRpdmUtYWxiYXRyb3NzQGV4YW1wbGUuY29tIn0.ncVkzcc6qrFJSXE3-5UsRu_kH vbwIMKYL3PFaMwReYTquPAcOQ8t93xF0bxbS8wrP0udCDvk6eYq4VbjoFdD59Yy6ltz0OKQl3- g8uFg2RwqTBMOKR0mYtQH0RCr9ORhSsmKolaDDt4TcRX78ZOAyhZ_Qg_UcEoHM4uZikpzBJYpY KbCCfbx-6FzYyHuvevSFzURISYpSHv3nbzirkEzKbOv7eZlg1cCYBdUoGuVBskyHxfMxFpoKQU 3mwIFdlQJR8LZ8hA_5ZdYjjMeSXfjnhlP2rppJiHy1NreGXXcUsUA74V2t_keY44deTrnPgoFO Se9IchWqcj6sDMDutC4ag
  49. Attacking a JWT { "typ": "JWT", "alg": "RS256" } {

    "ver": 1, "jti": "AT.JwyTSq9j454l3S6dS3USWXLUZpzGJucRwVDlVB5cHsw.US5WSFaQbBYT0/F3kc0o/+VTcuYg7pVvjevSOxdPxB0=", "iss": "https://dev-396343.oktapreview.com/oauth2/default", "aud": "api://default", "iat": 1543803025, "exp": 1543806625, "cid": "0oahzpp3tcpFrfcWI0h7", "uid": "00ui0fjkieyL46ma00h7", "scp": [ "offline_access", "photo" ], "sub": "inquisitive-albatross@example.com" } header claims signature
  50. Attacking a JWT { "typ": "JWT", "alg": "HS256" } {

    "ver": 1, "jti": "AT.JwyTSq9j454l3S6dS3USWXLUZpzGJucRwVDlVB5cHsw.US5WSFaQbBYT0/F3kc0o/+VTcuYg7pVvjevSOxdPxB0=", "iss": "https://dev-396343.oktapreview.com/oauth2/default", "aud": "api://default", "iat": 1543803025, "exp": 1543806625, "cid": "0oahzpp3tcpFrfcWI0h7", "uid": "00ui0fjkieyL46ma00h7", "scp": [ "offline_access", "photo" ], "sub": "inquisitive-albatross@example.com" } header claims signature
  51. Attacking a JWT { "typ": "JWT", "alg": "none" } {

    "ver": 1, "jti": "AT.JwyTSq9j454l3S6dS3USWXLUZpzGJucRwVDlVB5cHsw.US5WSFaQbBYT0/F3kc0o/+VTcuYg7pVvjevSOxdPxB0=", "iss": "https://dev-396343.oktapreview.com/oauth2/default", "aud": "api://default", "iat": 1543803025, "exp": 1543806625, "cid": "0oahzpp3tcpFrfcWI0h7", "uid": "00ui0fjkieyL46ma00h7", "scp": [ "offline_access", "photo" ], "sub": "inquisitive-albatross@example.com" } header claims
  52. @aaronpk Never let the JWT header
 determine your verification mechanism

  53. @aaronpk Thankfully most JWT libraries
 fixed this in 2015-2016

  54. @aaronpk GOOGLE OAUTH PHISHING

  55. @aaronpk 2017

  56. https://accounts.google.com/oauth/authorize?response_type

  57. https://arstechnica.com/information-technology/2017/05/dont-trust-oauth-why-the-google-docs-worm-was-so-convincing/

  58. https://accounts.google.com/oauth/authorize?response_type

  59. None
  60. None
  61. Prompting the User for Authorization Consent • Provide clear and

    straightforward information • Provide enough detail so the user knows what the application can access • Don't provide too much detail that they are overwhelmed and just click "ok"
  62. None
  63. None
  64. None
  65. None
  66. None
  67. None
  68. None
  69. None
  70. None
  71. Authorization Interface

  72. Authorization Interface Identify your service Identify the third-party app List

    the scopes the app is requesting Identify the developer name Show which user is logged in Allow/Cancel buttons
  73. oauth.net/security oauth2simplified.com

  74. Find me in the Developer Lounge! @aaronpk aaronpk.com

  75. Rate this session 
 in the mobile app OAuth: When

    Things Go Wrong
  76. Recommended Sessions Keeping Mobile Secure Roadmap: Okta Security (Repeat) WEDNESDAY,

    APRIL 3 3:30 - 4:15 PM Speaker: Hans Reichenbach - Staff Software Engineer WEDNESDAY, APRIL 3 3:30 - 4:15 PM | Room 2022 Speakers: Alex Bovee - Dir, Product Management Tranh-ha Nguyen - Sr. Associate Product Manager