JWT, Account Enumeration, and Security Galore

Joseph Ramirez, Phil Chmalts, and Rebecca Borison

Centralized authorization layer

• use a centralized authorization layer in your app-- don't one-off authorization for particular actions
• Although initial setup is more complex and expensive, it ensures consistent authorization across a large codebase
• all authorization decisions and enforcement should  take place server side
• JWT is how we handle this with easybib

Information leaks

• correlating ids to volumes is probably not the best idea

• Chegg used to include a sequential order number on all orders

• a competitor started using that to figure out how many orders Chegg was doing

• investors could also tracking it and trade based on it

Incremental User IDs

Superauth Dangers

Resources

• https://cybersecurity.ieee.org/blog/2016/06/02/design-best-practices-for-an-authentication-system/
• https://medium.com/technology-learning/how-we-solved-authentication-and-authorization-in-our-microservice-architecture-994539d1b6e6

JWT - What are they?

JSON Web Tokens are an open, industry standard method for representing claims securely between two parties.

It is a self contained way to share information between 2 parties. eg. Server and Client

The information inside the token can be trusted because it has been digitially signed via a shared secret, RSA (Private/Public key pair)

Created and maintained by Auth0 although the standard is open source

Great! What are they used for?

Most commonly JWT is used for authorization, and sent as an Authorization header on each request from a client (web app, mobile app, server, etc...)

The server then decodes and verifies that the JWT is valid and then is able to Authorize that request for the resource 

Single Sign On is a feature that widely uses JWT nowadays, because of its small overhead and its ability to be easily used across different domains.

Can replace the need for keeping track of sessions in Redis or Memcached (more on this later)

Wait...what's in this?

XXXXXXXX.YYYYYYYY.ZZZZZZZZ

Header

Payload

Signature

{
  "alg": "HS256",
  "typ": "JWT"
}

Type of token and alg used to sign

Claims - Not mandatory but recommended. There are public, private and registered claims

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

Each is base64 Encoded

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

Combo of header, payload, and secret encrypted by algorithm

Payload -- What goes in the claims?

Registered Claims - iss (issuer), exp (expiration time), sub (subject), aud(audience) -- These are recommended

Public Claims - These are things like email,  listed in
https://www.iana.org/assignments/jwt/jwt.xhtml

Private claims - Any custom information that's not standardized, eg. user-role, whatever else you need to share

EVEN THOUGH THIS INFORMATION CANNOT BE TAMPERED WITH IT IS STILL READABLE BY ANY CLIENT AS IT'S JUST A BASE64 ENCODED STRING, SO SENSITIVE INFORMATION SHOULD NOT BE PUT IN HERE

JWT - IRL

This is our jwt returned from easybib.com/api/token

{
  "client": "wbe",
  "email": null,
  "cheggTokens": null,
  "user_role": "not_logged_in",
  "paidMember": false,
  "sessionId": "k00ugvktqpq69l78n7n78j3fd1",
  "cheggUserUuid": null,
  "exp": 1533313442
}

I've pasted a JWT in FLS hipchat, go to JWT.io and try to verify the signature

Downsides to JWTs, 

There is no inherit way to invalidate a token without having a store keeping track of the active tokens.

Uses a secret key which can be compromised, FREQUENT key rotation is very important.

Generally relying on libraries to create and sign these tokens which can have their own vulnerabilities.