> On 23 Apr 2018, at 14:44, David Adrian <[email protected]> wrote:
>
> > If we have to invent a new standard each time an existing standard is
> > implemented with a security flaw, we have a lot of work to do.
>
> You fundamentally cannot fix a standard with unusable to the point of broken
> negotiation by extending the negotiation. If you don't want PASETO to be a
> new standard, call it JOSEv3.
I don’t believe that PASETO is actually fundamentally different from JOSE in
this respect. Is there a meaningful distinction between v1.local.<token> and
{“alg”:”v1.local”}.<token> ?
One of the critical vulnerabilities historically in JOSE implementations was
[1], whereby if an implementation was using RSA signed JWTs an attacker could
get the server’s public key and use it as if it was a HMAC key to produce a
forged JWT with {“alg”:”HS256”} in the header. If the JWT library just provided
a verify(String jwt, Key key) function then it might be tricked into using the
attacker’s choice of algorithm (HS256) with the server’s RSA public key and the
JWT would validate. Oops!
This flaw has been rightly criticised, including by the authors of PASETO.
Don’t let the attacker chose the algorithm!
But wait, aren’t PASETO implementations potentially vulnerable to *exactly the
same vulnerability*?! If my server is set up to use v2.public (Ed25519) signed
PASETO tokens, what is to stop an attacker grabbing my Ed25519 public key
(which is a 32 byte value) and using it to create a PASETO token using
v2.local? Recall that v2.local takes a 32 byte symmetric key. If the PASETO
library just has a function verify(String paseto, Key key) and looks at the
header to decide how to process the token, then it will have exactly the same
vulnerability that those JOSE libraries had. So how does PASETO the spec make
this vulnerability less likely?
Looking at the reference implementation [2], it seems that if the library user
didn’t set an allowed purpose then the only thing stopping this is a type check
on the public key class. In other words, the implementor took extra safe-guards
beyond those documented in the specification. Phew!
Am I missing something here? As far as I can tell, the PASETO docs and draft
RFC don’t even mention this as a consideration. How is this better than JOSE?
[1] https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/
[2] https://github.com/paragonie/paseto/blob/master/src/Parser.php#L159
Neil
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
