php uk 2017 - don't lose sleep - secure your rest
TRANSCRIPT
@adam_englander
Don’t Lose Sleep Secure Your REST
Adam Englander, iovation
@adam_englander
A Little Background About Me And APIs
@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.
@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
@adam_englander
Some Were More Secure Than Others
@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
@adam_englander
2015 Changed All Of ThatIETF RFC 7523: JSON Web Token (JWT) Profile
for OAuth 2.0 Client Authentication and Authorization Grants
@adam_englander
Javascript Object Signing and Encryption (JOSE) Went Mainstream
@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
@adam_englander
Case Study: iovation LaunchKeyTransformation of an Authorization API
@adam_englander
LaunchKey is a Multi-Factor Authentication and Authorization
Service
@adam_englander
LaunchKey API Version 1.xThe Before Time. The Long Long Ago…
@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
@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.
@adam_englander
Cryptography
• RSA OAEP encryption for most requests
• AES 256 CBC for large packages
• RSA SHA-256 signatures for portions
@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
@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
@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
@adam_englander
LaunchKey API v2.xAn almost awesome attempt at making a better API via open standards
@adam_englander
Enter JSON Web Token (JWT)
@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
@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
@adam_englander
LaunchKey API v3.0A full blown JOSE secured REST API
@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
@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
@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
@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
@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
@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
@adam_englander
How Did We Do It?
@adam_englander
JOSE, JOSE, JOSE
@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)
@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
@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
@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
@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
@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.
@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.
@adam_englander
How We Use JOSEJOSE Solved Every Problem We Had
@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
@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"}
@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
@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
@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
@adam_englander
Private Request Claims• Method
• Path
• Body hash
• Body hash algorithm
• Query parameters
@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" } }
@adam_englander
Hierarchical Credentials
… "iss": "dir:fd57bffe-7391-47c4-94d0-a0ad4b6bc979", "sub": "svc:d2083969-b5aa-4753-909d-472ce2517fd1", "aud": "lka", …
@adam_englander
Timestamp and Duration… "iat": 1487244120, "nbf": 1487244120, "exp": 1487244125, …
JWT hash stored until expiration to prevent replay attacks.
@adam_englander
Nonce
… "jti": "bec95e07-cee2-4c77-b080-56a8b24b2e54", …
@adam_englander
Request Validation
POST /service/v3/auths HTTP/1.1
… "request": { "meth": "POST", "path": "/service/v3/auths", "func": "S256", "hash": "66a045b452102c59d840e…" } …
@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
@adam_englander
Private Response Claims• Status Code
• Cache-Control Header
• Location Header
• Body hash
• Body hash algorithm
@adam_englander
Response Example RepresentationHTTP/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
@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" } }
@adam_englander
Hierarchical Credentials
… "iss": "lka", "sub": "svc:d2083969-b5aa-4753-909d-472ce2517fd1", "aud": "dir:fd57bffe-7391-47c4-94d0-a0ad4b6bc979", …
@adam_englander
Timestamp and Duration
… "iat": 1487244121, "nbf": 1487244121, "exp": 1487244126, …
@adam_englander
Nonce
… "jti": "bec95e07-cee2-4c77-b080-56a8b24b2e54", …
Nonce is echoed in JTI to allow for detection of Man In The Middle attacks
@adam_englander
Response ValidationHTTP/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…” } …
@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
@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"}
@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
@adam_englander
Libraries
• spomky-labs/jose - Full JOSE
• lcobucci/jwt - JWT only - Author presenting tomorrow
@adam_englander
If You Want To Follow Up
• @adam_englander
• https://www.iovation.com/blog/author/aenglander