rwinch
commented
8 years ago JWT
Generally speaking you should try to avoid using Crypto (i.e. JWT) unless you cannot achieve what you want to in another way (i.e. using a secure random id and a data store). The presentation gives examples of how cryptography is difficult. For example, the talk discusses vulnerabilities found in the TLS libraries which are written by developers that live and breathe cryptography (openssl developers). If there are crypto bugs in this software, then there are almost certainly bugs in the JWT (or other) libraries.
What's more is the JWT protocol is designed poorly. This was demonstrated in the way the specification stated to use the algorithm header. However, there are other fundamental problems with the specification that lead to a poorly designed "modern" crypto system. For example, it uses RSA. This is a bad choice for quite a few reasons. I'll let you read up on it Asymmetric encryption & Asymmetric signatures. I went ahead and copies some the sections below:
Asymmetric encryption (Was: Use RSAES-OAEP with SHA256 and MGF1+SHA256 bzzrt pop ffssssssst exponent 65537): Use Nacl.
You care about this if: you need to encrypt the same kind of message to many different people, some of them strangers, and they need to be able to accept the message asynchronously, like it was store-and-forward email, and then decrypt it offline. It's a pretty narrow use case.
Of all the cryptographic "right answers", this is the one you're least likely to get right on your own. Don't freelance public key encryption, and don't use a low-level crypto library like OpenSSL or BouncyCastle.
Here are several reasons you should stop using RSA and switch to elliptic curve software:
- Progress in attacking RSA --- really, all the classic multiplicative group primitives, including DH and DSA and presumably ElGamal --- is proceeding faster than progress against elliptic curve.
- RSA (and DH) drag you towards "backwards compatibility" (ie: downgrade-attack compatibility) with insecure systems. Elliptic curve schemes generally don't need to be vigilant about accidentally accepting 768-bit parameters.
- RSA begs implementors to encrypt directly with its public key primitive, which is usually not what you want to do: not only does accidentally designing with RSA encryption usually forfeit forward-secrecy, but it also exposes you to new classes of implementation bugs. Elliptic curve systems don't promote this particular foot-gun.
- The weight of correctness/safety in elliptic curve systems falls primarily on cryptographers, who must provide a set of curve parameters optimized for security at a particular performance level; once that happens, there aren't many knobs for implementors to turn that can subvert security. The opposite is true in RSA. Even if you use RSA-OAEP, there are additional parameters to supply and things you have to know to get right.
If you have to use RSA, do use RSA-OAEP. But don't use RSA.
Avoid: RSA-PKCS1v15, RSA, ElGamal, I don't know, Merkle-Hellman knapsacks? Just avoid RSA.
Asymmetric signatures (Was: Use RSASSA-PSS with SHA256 then MGF1+SHA256 yabble babble): Use Nacl, Ed25519, or RFC6979.
You care about this if: you're designing a new cryptocurrency. Or, a system to sign Ruby Gems or Vagrant images, or a DRM scheme, where the authenticity of a series of files arriving at random times needs to be checked offline against the same secret key. Or, you're designing an encrypted message transport.
The allegations from the previous answer are incorporated herein as if stated in full.
In 10+ years of doing software security assessments I can count on none fingers the number of RSA-PSS users I was paid to look at. RSA-PSS is an academic recommendation.
The two dominating use cases within the last 10 years for asymmetric signatures are cryptocurrencies and forward-secret key agreement, as with ECDHE-TLS. The dominating algorithms for these use cases are all elliptic-curve based. Be wary of new systems that use RSA signatures.
In the last few years there has been a major shift away from conventional DSA signatures and towards misuse-resistent "deterministic" signature schemes, of which EdDSA and RFC6979 are the best examples. You can think of these schemes as "user-proofed" responses to the Playstation 3 ECDSA flaw, in which reuse of a random number leaked secret keys. Use deterministic signatures in preference to any other signature scheme.
Avoid: RSA-PKCS1v15, RSA, ECDSA, DSA; really, especially avoid conventional DSA and ECDSA.
CSRF
CSRF is about writing data to another domain.
A browser cannot (generally) read the data from another domain because the data is protected by the Same Origin Policy. There are ways to get around Same Origin Policy, but you must take explicit steps to do so.
oiavorskyi
@rwinch first of all, thank you for the very informative presentation. I really enjoyed the step-by-step approach and focus on "why". I have two questions.
First, while JWT approach could be attacked with algorithm modification is it considered safe to use it if only RS256 is enabled on the resource server side? Especially in scenarios when it is used inside the perimeter to authorize one service to access resources or issue commands to another service. Is there anything else to be cautious about with JWT?
Second, in case of CSRF protection the GET request does not have the token thus it is possible for “evil.com” to send the request to “/csrf” endpoint the same way the SPA would send and get the CSRF token for the session. Isn’t it a case?
Thank you in advance.