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

@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 That
IETF RFC 7523: JSON Web Token (JWT) Proﬁle
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 LaunchKey
Transformation of an Authorization API

@adam_englander
LaunchKey is a Multi-Factor
Authentication and Authorization
Service

@adam_englander
LaunchKey API Version 1.x
The 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 identiﬁers
• 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 veriﬁcation 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 ﬁrms
• 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.x
An 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.0
A 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 prooﬁng 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 identiﬁcation 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 ﬁve 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 identiﬁcation.
• Used by JWE/JWS with number of keys in the
header which are determined by the key type.

@adam_englander
How We Use JOSE
JOSE 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 speciﬁc 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", 
"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
…
…

@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 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

@adam_englander
JWT Response Claims Example
{ 
"iss": "lka", 
"aud": "dir:fd57bffe-7391-47c4-94d0-a0ad4b6bc979", 
"iat": 1234567891, 
"nbf": 1234567891, 
"exp": 1234567896, 
"response": { 
"status": 201, 
"cache": "no-cache", 
"location": "/directory/v3/users/518f5d3e-7cdf-4ef1-…", 
"func": "S256", 
"hash": "66a045b452102c59d840ec097d59d9467e13a3f34f6494e539ffd32c1bb35f18" 
} 
}

@adam_englander
Hierarchical Credentials
… 
"iss": "lka", 
"aud": "dir:fd57bffe-7391-47c4-94d0-a0ad4b6bc979",
…

@adam_englander
Timestamp and Duration
… 
"iat": 1487244121, 
"nbf": 1487244121, 
"exp": 1487244126, 
…

@adam_englander
Nonce
…
…
Nonce is echoed in JTI to allow for detection of
Man In The Middle attacks

@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…” 
}
…

@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
Please Rate This Talk
https://legacy.joind.in/20330

@adam_englander
If You Want To Follow Up
• @adam_englander
• adam.englander@iovation.com
• https://www.iovation.com/blog/author/aenglander

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

Recommended

Recommended

More Related Content

What's hot

What's hot (16)

Viewers also liked

Viewers also liked (20)

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

Similar to PHP UK 2017 - Don't Lose Sleep - Secure Your REST (20)

More from Adam Englander

More from Adam Englander (20)

Recently uploaded

Recently uploaded (20)

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