PASETO – an option worth considering for Token Based Authentication problem

Tram Ho

I recently read an article on Okta Dev, introducing PASETO. After reading it, I felt quite good. Searching for this keyword on Google found it quite a bit. And the Vietnamese language is not found there. => So I decided to “translate” + “rewrite” about this.

1. Math problem / Best use case

1.1. Problem 1

  • You build a system. Including 2 applications:
    • Web application: allows users to pay to download files
    • Download service application: provide file download service (user uses the returned Web Application url, to request downloading)
    • These 2 applications have 1 secure connection channel with each other. (For example, on the same LAN, connect using private IP ..)
  • Desired scenario:
    • User makes payment on the Website
    • Website authentication of payment completed. And create download link (with token included), return to the user
    • User uses download link to download.

How to Download service validate the url request to download? … without having to call any database. (type not query to db to check token, check payment history …)

1.2. Problem 2

  • You build 2 systems:
    • Authorization service provision system. Manage user login, and grant permissions
    • Website system, allowing user login
    • 2 systems have 1 channel connection does not guarantee safety. (For example, the latter authorization system not only provides one website, but also any other website. Like OpenID, OAuth 2 …)
  • Desired scenario:
    • The user accesses the website and login (e.g. https://example.com/login )
    • Website that directs users to the authorization system (eg https://authorization-ex.com )
    • The user enters username / password at the login form of the authorization service.
    • Authorization Service authenticates account + redirects user to website, with token. ( https://example.com/authen?token=abcxyz )
    • Website received tokens. Perform validate, and create session access for the user.
    • The user accesses the Website using the provided session.

How does the Website ensure that the correct token is created by the Authorization Service? (Prevention of Middle-Man attack)

2. PASETO

  • PASETO = Platform-Agnostic SEcurity TOkens
  • Is a prototol for Token-based authentication problem
  • A Stateless token (i.e., it is validate itself, without needing to store / query further)
  • There are many similarities with JWT (JSON Web Tokens), but “upgrading” is more.
  • PASETO has 2 modes:
    • LOCAL (used for problem 1 above)
    • PUBLIC (used for problem 2 above)

2.1 Mode LOCAL

  • Token format: v1.local.payload.optional_footer
    • Exxample:
    • v1: is the version of PASETO. The choice of version will determine the type of algorithm used for encryption. (The higher the version, the newer the encryption algorithm, the more security it will be, but the downside is that it requires compatible devices). Currently there are only 2 versions v1, v2
    • local: is LOCAL mode
    • payload: 1 json object, then encoded.
    • optional_footer: yes or no. Used to contain metadata. And not encrypted.
  • LOCAL Mode uses Symmetric encryption – Symmetric (i.e. the key to encrypt and the key to decrypt are the same). Ex: AES algorithm
  • The Paseto versions are not backward compatible. That is, whichever side the encryption party uses, the decoder must use that version.
  • The field names in the json object are in the standard payload of PASETO RFC
  • Usually the field exp + iat is used to check the token duration.

//: -? One of the things that I don’t like about JWT is that the payload of JWT is only decode by base64. It’s like “I show you the information, but you can’t see it if you see it”.

  • Solution to problem 1 using PASETO. Baitoan1

2.2 Mode PUBLIC

  • Token format: v1.public.payload.optional_footer
    • The format is the same as LOCAL mode
  • Payload in PUBLIC mode is encrypted / decoded by ASymmetric (i.e. there will be a separate key pair, privateKey and publicKey. PrivateKey is used for encryption. PublicKey is for decoding. can decode, but only 1 person can encrypt). Ex: RSA algorithm

    Format

  • Solution to problem 2: Baitoan2

3. Compare PASETO vs JWT

3.1 The same

  • These are protocols for the Token-based authentication problem
  • Payload are all json objects
  • Are staless tokens
  • The idea of ​​the payload part has an “expire time” field, to check the expiry date of the token
  • They are not resistant to replay attacks. (ie the token is in the hands of the attacker, then the attacker can use it as the real user)

3.2 Different

DifferenceJWTPASETO
How to self validate (self-check signature)+ payload header is base64 decode by then will be hash hash algorithm that is declared in the header, using the secret key. Then compare with the signature sectionThe payload is decrypted by shareKey (or publicKey), if the successful decrypt is a valid token
Number of modesOnly 1 modeThere are 2 modes: local + public, depending on the use case selected

3.3 Weaknesses of JWT

  • Attacker can edit the alt field in the header, to change the hashing algorithm, with a hash function with weak security, and modify the signature . If the server does not perform the alt check, it increases the risk of vulnerability.

4. Reference

4.1 Algorithm

  • v1.local: AES-256-CTR + HMAC-SHA384 (Encrypt-then-MAC)
  • v1.public: 2048-bit RSA
  • v2.local: XChaCha20-Poly1305 (192-bit nonce, 256-bit key, 128-bit authentication tag)
  • v2.public: Ed25519 (EdDSA over Curve25519)

4.2 Related links

Share the news now

Source : Viblo