Fail when base64 data contains nonzero padding bits

[slashnick]

If the data in a base64 field of a PASETO token isn't a multiple of 6 bits, the last base64 character will be padded with 2 or 4 "zero" bits. But when decoding, most base64 libraries will ignore those last 4 bits.

eg. base64_encode(b"\xff") (11111111) == "_w" (111111 110000). But during decoding base64_decode("_w") (111111 110000) == base64_decode("_y") (111111 110001).

So given a valid PASETO token, you can construct a slightly different token with the same content but a different base64 representation. For example, these two public tokens both decode to the same content, despite having different final characters.

• v4.public.eyJleHAiOiIyMDIyLTA2LTA5VDE4OjI0OjA4LTA0OjAwIiwidXNlciI6Inplcm8gY29vbCJ9CaoTvJwHuqZgEE8bQVpaIo3sTdZMEtuAXicK_mB2km98GkxvHYc_7nAzCsWjsnvI7OiwUW9aVyS5UnPOXYBnCw
• v4.public.eyJleHAiOiIyMDIyLTA2LTA5VDE4OjI0OjA4LTA0OjAwIiwidXNlciI6Inplcm8gY29vbCJ9CaoTvJwHuqZgEE8bQVpaIo3sTdZMEtuAXicK_mB2km98GkxvHYc_7nAzCsWjsnvI7OiwUW9aVyS5UnPOXYBnCx

It seems weird for PASETO libraries to accept tokens that they clearly didn't generate.

[slashnick]

Oh, I guess a simpler way to construct duplicate tokens with would be to append ==. Maybe that should be blocked too?

[paragonie-security]

PASETO doesn't use Base64, PASETO uses Base64url (RFC 4648).

From the relevant section of the specification.

Nearly every component in a Paseto (except for the version, purpose, and the . separators) will be encoded using Base64url, without = padding.

If you'd like us to strengthen the wording ("MUST NOT include padding"; "decoders MUST be strict when decoding", etc.) then that's worth considering.

[paragonie-security]

https://github.com/paseto-standard/paseto-spec/commit/08be722de0bf5e38f39b6a06ffb2ee01479e6788

[paragonie-security]

Test vectors updated:

• https://github.com/paseto-standard/test-vectors/commit/d26d2dd8d45d316a581032205cd131ab5c326aa9
• https://github.com/paseto-standard/test-vectors/commit/f7cfbe02e4e069dddefc9001cd6303b045595ea3

[paragonie-security]

PHP encoding library updated: https://github.com/paragonie/constant_time_encoding/releases/tag/v2.6.0

[paragonie-security]

Reference implementation updated: https://github.com/paragonie/paseto/releases/tag/v3.0.1

• [x] Specification is now explicit about this requirement
• [x] The test vectors now have expected-to-fail test cases to reject malleable encoding
• [x] Reference implementation in PHP has been updated to be stricter

Thanks for reporting this.