Authentication

IAM: identity access management

Types of authentication

1. API security for end-users.
2. inter-service authentication
3. federated authentication and SSO: Google, Apple, Okta give tokens that map requests to identities on their platform.

Criteria:

1. Token revocation
2. DB hit
3. Vulnerabilities

---

0. Username & Passwords via HTTP basic auth:
   • Probably a bad idea. You want your password to be random tokens.
1. Simple Random Tokens:
   • Maintain a table of <tokens, userid, actions>
   • used as bearer tokens. Problem: anybody that has them, can use them.
     • Note: by default bearer tokens are not cryptographically signed. its just a random string.
2. Platform tokens
   • Motivation: reduce db queries for user info.
   • Solution: “stateless auth” via encrypt-then-mac string in a cookie.
   • Drawback:
     • user info in cookie might be stale, as it’s effectively a db cache.
     • how to do token revocation
   • How to revoke token? Add a token version in the user table. Tokens bear the current version. Maintain cache of user versions. To revoke, increment token version in DB and update cache version.
   • Django implementation of signed cookies
     • Return URL-safe, hmac signed base64 compressed JSON string. Key used is settings.SECRET_KEY. salt used is "django.contrib.sessions.backends.signed_cookies". The session data is prepended with current timestamp (this is to check against max_age attribute to determine whether session is valid). The hmac algorithm is hmac/SHA-256.
3. Oauth2
   • Canonically used to pass authorization from one application to another.
   • Provides built-in solution for short-expiry tokens, “refresh token”, that can be exchanged for “access tokens”.
   • This access tokens could simply be a platform token.
4. JWT
   • JWT Header contains an alg parameter, which tells server what algorithm was used to sign the token.
   • Usually refers to JWS (JSON Web Signature) which only encodes the payload. An alternative variant is JWE (JSON Web Encryption) which encrypts the payload.
   • Many implementation pitfalls
     • libraries accepting alg=None, i.e. unsecured JWT.
     • token forgery through
       • JWT algorithm confusion attacks by trusting the alg presented in JWT header. Attacker could pass a HS256 (symmetric crypto via server’s public key)-signed token to a RS256 (asymmetric crypto) server, which would pass the verification.
       • jwk header injection. This header is used to embed server’s public key directly within the token.
       • jku header injection. This header is set to url from which servers can fetch a set of keys containing the correct key.
   • Don’t use it to track session data.
     • Stateless JWT Tokens (where session data is encoded directly into the token) cannot be invalidated or updated, introduce size issues or security issues. Just use cookies for sessions. It has a lot of battle tested implementations.
     • JWT is good as a single-use authorization token. “Hello Server B, Server A told me that I could < claim goes here >, and here’s the (cryptographic) proof.”
       • Tokens are also short-lived.
   • But it’s non optional in OIDC (OpenID Connect) which is how Google and Apple implement SSO. In this case though, for sessions, we can exchange the JWT token with a session in our server.
5. PASETO
   • Support only one of symmetric or asymmetric tokens. Otherwise might suffer algorithm confusion attacks like JWT.
6. Protobuf tokens: defining your own strongly-typed protocol format.
7. Authenticated requests: canonicalize all http requests, and compute HMAC tag over the canonicalized request. Popularized by AWS
   • Stateful. Server needs to store the secret access key of the client.
   • Upside: no bearer tokens. no tokens to be stolen.
   • Downside: need SDK to build this code.
8. Facebook “Crypto Auth Tokens” (CAT)

---

Aegis 2FA docs

• derived a key from user’s password (“credential”) via scrypt. key = scrpyt(password, salt)
• use the derived key to encrypt 256-bit master key using AES-256 GCM.
  • nonce is stored. should be unique
  • this encrypted master key is store in password slot together with scrypt parameters and salt.
• use the master key to encrypt vault contents using AES-256 GCM.
• Possible confusion: there are 2 nonce/tag objects, because there is 2 AES-256 GCM step.
  • As AES-256 GCM needs a unique 96-bit nonce for each invocation, Aegis assumes that user will never save (open?) the vault close to $2^{32}$ times.
• Vault contents:
  • Contains a secret. This secret is generated once (when you register your authenticator app) by the server and presented to you via a QR code.
  • Aegis will then calculate TOTP (time-based one-time passwords) which is HMAC(secret, timestamp).