Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
JWT - To authentication and beyond!
Next
Download to read offline and view in fullscreen.

1

Share

Download to read offline

PHP UK 2017 - Don't Lose Sleep - Secure Your REST

Download to read offline

Are you worried that your REST API may be the next victim of an attack by ruthless hackers? Don't fret. Utilizing the same standards implemented by OAuth 2.0 and OpenID Connect, you can secure your REST API. Open and proven standards are the best ways to secure your REST APIs for now and well into the future. JSON Object Signing and Encryption (JOSE) is the core of a truly secure standards based REST API. In this talk, you will learn how to use the components of JOSE to secure your REST API for now and the future.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

PHP UK 2017 - Don't Lose Sleep - Secure Your REST

  1. 1. @adam_englander Don’t Lose Sleep Secure Your REST Adam Englander, iovation
  2. 2. @adam_englander A Little Background About Me And APIs
  3. 3. @adam_englander This is what I looked like when I started working on APIs It was so long ago that SOAP was the new hotness.
  4. 4. @adam_englander Over The Years • 2001 — Global Authentication Service API • 2008 — Loan Application Ping Tree • 2010 — Loan Management System API • 2012 — Advertising Network API • 2013 — Real Time Loan Risk Assessment API • 2015 — Decentralized Multi-Factor Authorization API
  5. 5. @adam_englander Some Were More Secure Than Others
  6. 6. @adam_englander Auth and Crypto Was Messy • Auth as part of the message added complexity • Auth outside of the message lost context • Every implementation was specialized • Crypto was non-standard and static • Non-experts had to write a lot of code
  7. 7. @adam_englander 2015 Changed All Of That IETF RFC 7523: JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants
  8. 8. @adam_englander Javascript Object Signing and Encryption (JOSE) Went Mainstream
  9. 9. @adam_englander Why Was It A Big Deal? • Authentication, authorization, encryption, and data integrity validation are not tied to the protocol • OAuth, OpenID, and FIDO adopting the standard gave it credibility, stability, and longevity as an IETF working group
  10. 10. @adam_englander Case Study: iovation LaunchKey Transformation of an Authorization API
  11. 11. @adam_englander LaunchKey is a Multi-Factor Authentication and Authorization Service
  12. 12. @adam_englander LaunchKey API Version 1.x The Before Time. The Long Long Ago…
  13. 13. @adam_englander Data • RESTish Web API • Query parameters for GET including encrypted data and signature • Mostly form encoded requests for POST/PUT/ DELETE • JSON responses
  14. 14. @adam_englander Credentials • Silo credentials for entity types • Random integers for identifiers • Passwords sent in encrypted package • Password rotation with old password expiring one hour after new password generated.
  15. 15. @adam_englander Cryptography • RSA OAEP encryption for most requests • AES 256 CBC for large packages • RSA SHA-256 signatures for portions
  16. 16. @adam_englander Security • Replay prevention for requester ID and timestamp • Signature verification for password and timestamp • Encrypted password and timestamp • Rate limited by requester ID and subject
  17. 17. @adam_englander The Good — Security • The API was never compromised even though there has been a bug bounty for four years • It passed multiple static and dynamic analyses from top security analysis firms • No-one has ever been able to fabricate an authorization ever
  18. 18. @adam_englander The Bad — Usability • Has its own way of doing things • API is not uniform in data and encryption • Security trumped RESTful • Too many credentials to manage • No proper credential rotation
  19. 19. @adam_englander LaunchKey API v2.x An almost awesome attempt at making a better API via open standards
  20. 20. @adam_englander Enter JSON Web Token (JWT)
  21. 21. @adam_englander What We Gained • Began using an open standard for data security • We added a private claim for as SHA-256 hash of the request body • A more secure API request format
  22. 22. @adam_englander What Was Missing • Still using custom and inconsistent encryption • Did not increase the RESTful quality • Did not sign the entire request • Did not reduce the quantity of credentials • Did not improve the response
  23. 23. @adam_englander LaunchKey API v3.0 A full blown JOSE secured REST API
  24. 24. @adam_englander What Changed? • JWT with custom claims used to validate entire request and critical portions of the response • JWE to encrypt request and response • JWA for future proofing cryptography • JWK for credential rotation • Removed password entirely
  25. 25. @adam_englander The Good — Decoupling • Authentication, authorization, validation, encryption and decryption was moved to middleware • Controllers handled only HTTP/JSON which greatly reduced code complexity • Better unit testing across the board • Reduced development times for new functionality
  26. 26. @adam_englander The Good — OSS Libraries • We can test our API without requiring our own client SDK • Client SDKs are less complex • OSS contributions are actually possible • Documentation complexity was reduced
  27. 27. @adam_englander The Good — Uniformity Across APIs • All APIs will be migrated to JOSE • Different key implementations are possible • Shared knowledge across vastly different teams • Federated authentication is attainable
  28. 28. @adam_englander The Good — Hierarchical Auth • JWT inclusion of issuer, subject, and audience allows for a parent to provide credentials for action on a sibling with proper context. • JWK allows for easy identification of credentials used
  29. 29. @adam_englander The Bad • Some languages have minimal support for algorithms and strengths • Some languages have no support for JWE. We had to write our own minimal Objective-C implementation • Some good documentation but a good working knowledge requires reading RFCs
  30. 30. @adam_englander How Did We Do It?
  31. 31. @adam_englander JOSE, JOSE, JOSE
  32. 32. @adam_englander What is JOSE? • JavaScript Object Signing and Encryption encompasses: • JSON Web Token (JWT) • JSON Web Signature (JWS) • JSON Web Encryption (JWE) • JSON Web Algorithm (JWA) • JSON Web Key (KWK)
  33. 33. @adam_englander JSON Web Token (JWT) • JWT is actually a JSON Web Signature (JWS) package with standardized payload in the form of Claims. • Provides for credentials, nonce, timestamp, and duration • Private claims can be added for extensibility
  34. 34. @adam_englander JSON Web Signature (JWS) JWS is comprised of three segments: 1. Header provides key information, signature algorithm, and optionally content metadata 2. Payload is the data to be signed 3. Signature of the header and payload
  35. 35. @adam_englander JSON Web Encryption (JWE) JSON Web Encryption contains five segments: 1. Header provides key management mode, key information, key encryption algorithm, content encryption algorithm, and optionally content metadata 2. Content Encryption Key (CEK) may contain generated symmetric keys used for encryption and HMAC that are encrypted using asymmetric key encryption
  36. 36. @adam_englander JSON Web Encryption (JWE) 3. Initialization Vector for encrypting the payload 4. Encrypted payload 5. Authentication tag is an HMAC of the header, IV, and encrypted payload
  37. 37. @adam_englander JSON Web Algorithm • Standardized format for expressing encryption and signature algorithms. • Used by JWE/JWS with “enc” and “alg” keys in the header.
  38. 38. @adam_englander JSON Web Key • Standardized format for expressing keys used for JWE and JWS. • Provides for key identification. • Used by JWE/JWS with number of keys in the header which are determined by the key type.
  39. 39. @adam_englander How We Use JOSE JOSE Solved Every Problem We Had
  40. 40. @adam_englander Request Example Representation POST /service/v3/auths HTTP/1.1 Content-Type: application/jose Content-Length: 112 Authorization: IOV-JWT eyJhb.VuYyI6IkEy.OKOaw eyJhbGciO.Ppd6dIAkG.71lYoW6jA.t-4rRH6GsoXt0.1DGC4k
  41. 41. @adam_englander JWT Header Example {
 "kid": "09:f7:e0:2f:12:90:be:21:1d:a7:07:a2:66:f1:53:b3",
 "alg": "RS256",
 "typ": "JWT",
 "cty": "JWT"
 }
  42. 42. @adam_englander Key Rotation • Key ID id provided in request and response • Current and specific public keys are available via endpoint • https://api.launchkey.com/public/v3/public-key/ 09:f7:e0:2f:12:90:be:21:1d:a7:07:a2:66:f1:53:b3 • https://api.launchkey.com/public/v3/public-key
  43. 43. @adam_englander Key Rotation {
 "kid": "09:f7:e0:2f:12:90:be:21:1d:a7:07:a2:66:f1:53:b3",
 "alg": "RS256",
 "typ": "JWT",
 "cty": "JWT"
 } /v3/public-key/09:f7:e0:2f:12:90:be:21:1d:a7:07:a2:66:f1:53:b3
  44. 44. @adam_englander Request Authorization • Single use JSON Web Token (JWT) in Authorization header as Authorization scheme IOV-JWT • RSA key signature • Hierarchical ACL: Org -> Dir -> Service • Token ID as nonce • Private claims: request
  45. 45. @adam_englander Private Request Claims • Method • Path • Body hash • Body hash algorithm • Query parameters
  46. 46. @adam_englander JWT Request Claims Example {
 "iss": "dir:fd57bffe-7391-47c4-94d0-a0ad4b6bc979",
 "sub": "svc:d2083969-b5aa-4753-909d-472ce2517fd1",
 "aud": "lka",
 "iat": 1234567890,
 "nbf": 1234567890,
 "exp": 1234567895,
 "jti": "bec95e07-cee2-4c77-b080-56a8b24b2e54",
 "request": {
 "meth": "POST",
 "path": "/service/v3/auths",
 "func": "S256",
 "hash": "66a045b452102c59d840ec097d59d9467e13a3f34f6494e539ffd32c1bb35f18"
 }
 }
  47. 47. @adam_englander Hierarchical Credentials …
 "iss": "dir:fd57bffe-7391-47c4-94d0-a0ad4b6bc979",
 "sub": "svc:d2083969-b5aa-4753-909d-472ce2517fd1",
 "aud": "lka", …

  48. 48. @adam_englander Timestamp and Duration …
 "iat": 1487244120,
 "nbf": 1487244120,
 "exp": 1487244125,
 … JWT hash stored until expiration to prevent replay attacks.
  49. 49. @adam_englander Nonce … "jti": "bec95e07-cee2-4c77-b080-56a8b24b2e54",
 …
  50. 50. @adam_englander Request Validation POST /service/v3/auths HTTP/1.1 … "request": {
 "meth": "POST",
 "path": "/service/v3/auths",
 "func": "S256",
 "hash": "66a045b452102c59d840e…"
 }
 …
  51. 51. @adam_englander Response Authorization • Single use JSON Web Token (JWT) in custom header X-IOV-JWT • RSA key signature • Hierarchical credentials • Token ID nonce is echoed • Private claims: response
  52. 52. @adam_englander Private Response Claims • Status Code • Cache-Control Header • Location Header • Body hash • Body hash algorithm
  53. 53. @adam_englander Response Example Representation HTTP/1.1 201 Created Content-Type: application/jose Content-Length: 112 Cache-Control: no-cache Location: /directory/v3/users/518f5d3e-7cdf-4ef1-… X-IOV-JWT: eyJhb.VuYyI6IkEy.OKOaw eyJhbGciO.Ppd6dIAkG.71lYoW6jA.t-4rRH6GsoXt0.1DGC4k
  54. 54. @adam_englander JWT Response Claims Example {
 "iss": "lka",
 "sub": "svc:d2083969-b5aa-4753-909d-472ce2517fd1",
 "aud": "dir:fd57bffe-7391-47c4-94d0-a0ad4b6bc979",
 "iat": 1234567891,
 "nbf": 1234567891,
 "exp": 1234567896,
 "jti": "bec95e07-cee2-4c77-b080-56a8b24b2e54",
 "response": {
 "status": 201,
 "cache": "no-cache",
 "location": "/directory/v3/users/518f5d3e-7cdf-4ef1-…",
 "func": "S256",
 "hash": "66a045b452102c59d840ec097d59d9467e13a3f34f6494e539ffd32c1bb35f18"
 }
 }
  55. 55. @adam_englander Hierarchical Credentials …
 "iss": "lka",
 "sub": "svc:d2083969-b5aa-4753-909d-472ce2517fd1",
 "aud": "dir:fd57bffe-7391-47c4-94d0-a0ad4b6bc979", …

  56. 56. @adam_englander Timestamp and Duration …
 "iat": 1487244121,
 "nbf": 1487244121,
 "exp": 1487244126,
 …
  57. 57. @adam_englander Nonce … "jti": "bec95e07-cee2-4c77-b080-56a8b24b2e54",
 … Nonce is echoed in JTI to allow for detection of Man In The Middle attacks
  58. 58. @adam_englander Response Validation HTTP/1.1 201 Created Cache-Control: no-cache Location: /directory/v3/users/518f5d3e-7c… … "response": {
 "status": 201,
 "cache": "no-cache",
 "location": "/directory/v3/users/518f5d3e-7c…",
 "func": "S256",
 "hash": “66a045b452102c59d840ec097d59d9467e13…”
 } …
  59. 59. @adam_englander Encrypted Data with JWE • JWK provides for key rotation • Combination of RSA and AES encryption is always used • Algorithms and modes are always the same • Key size is variable in allowed range • Response uses same AES key size as request
  60. 60. @adam_englander JWE Header Example {
 "kid": "09:f7:e0:2f:12:90:be:21:1d:a7:07:a2:66:f1:53:b3",
 "alg": “RSA-OAEP-256",
 "enc": "A256CBC-HS512",
 "cty": “application/json"
 }
  61. 61. @adam_englander Conclusion • JOSE has made our secure API more secure • JOSE has made our API easier to use • JOSE has made our code less complex • JOSE has homogenized auth and crypto across multiple platforms regardless of language
  62. 62. @adam_englander Libraries • spomky-labs/jose - Full JOSE • lcobucci/jwt - JWT only - Author presenting tomorrow
  63. 63. @adam_englander Please Rate This Talk https://legacy.joind.in/20330
  64. 64. @adam_englander If You Want To Follow Up • @adam_englander • adam.englander@iovation.com • https://www.iovation.com/blog/author/aenglander
  • DimitarGeorgiev25

    Feb. 24, 2017

Are you worried that your REST API may be the next victim of an attack by ruthless hackers? Don't fret. Utilizing the same standards implemented by OAuth 2.0 and OpenID Connect, you can secure your REST API. Open and proven standards are the best ways to secure your REST APIs for now and well into the future. JSON Object Signing and Encryption (JOSE) is the core of a truly secure standards based REST API. In this talk, you will learn how to use the components of JOSE to secure your REST API for now and the future.

Views

Total views

524

On Slideshare

0

From embeds

0

Number of embeds

1

Actions

Downloads

18

Shares

0

Comments

0

Likes

1

×