2. About Me
● CloudFlare Security Systems Engineer
● Previously an engineer at LastPass
● Wrote passgo (https://github.com/ejcx/passgo)
● On twitter @ejcx_
● Personal sites:
○ https://ejj.io
○ https://twiinsen.com
3. What is JOSE
● Fairly new standard.
● It is actually a “suite” of standards.
● Methods for encrypting and signing javascript objects.
● Useful for stateless tokens
● https://jwt.io has a great demo but we’re about to do
one ourselves
4. What is a stateless token?
● Used in large web applications.
● Server provides a client with a token containing some
information needed by other servers to service the
request
● Cryptographically validated
● Meant to decrease load. Crypto is cheaper than
databases
● Commonly used for authentication
● Less code
5. What does JOSE look like
eyJhbGciOiJSUzI1NiIsImp3ayI6eyJrdHkiOiJSU0EiLCJuIjoieVRxNnRPbFdWNnBDdGJMT2Z
5dXZxVzlaeFlramxtX0pWbnZrN0syMEFYakxUV0dmTlI0bUNNU3A0djhuZXdhVUZITnIyYlJUYX
Zxc213Q1U3M3lONUlmclBYcU5sOVdWeTJ2eGh0dnZOM01sVXREWklFVkJDWkl2WVpZVlBsOW82L
W9HbnR6bUZqMmc1bDRERjFRNkc0enRhVGlER2s5V3BHRnNHVW4xNHJyWnR4a0JJeVVfMS1fRjRf
cnR0bHlQcjRSSW02QTM0OGU4cWV5SU9KZW9rbXNQZWNPWnRzN01RenRnVEVmMVJYTnRXQUg4ZGZ
FbG9PT0FpRG1sX0dtU1BCZ0RhYU5MQnhlV3ZPT1FITVU4NU5YbXFLVndkYWJESVcxQTlRUUg3LW
1NMmw0QzVLUGJmcEtvNklhbU5jX0dCRGd3TjFzd2kzcThNcTkwb2UtSmx3IiwiZSI6IkFRQUIif
X0.eydqdGknOidkZWFkYmVlZicsICdtc2cnOidUaGFua3MgZm9yIGNvbWluZyB0byBteSB0YWxr
J30.DQU1MV5NaWadp45mT66oH7-yQ_ltZNTU88gHOnrcnAjxRummFEH7wuAXaHSPChf7pPc-
ZBE5kEMEPFN0e_pY1df58xfabNPlJNpKnZJjiqClYRZ2VZbbB9_ePgj-XxVPgGeAmFakh-
O59xxvyHyG97NKtnBjwtdnvLgp5jnnwIiojh8LXdSmjyo2yJNbj34mluSF1qf3IgVGYUUuJAMy_
lxX8bIXLTnwLxCSd28mK6CqF7yBnmYLx6rzk1KMKkgzDrmLJMSdvwR-JYV6fFSnWixNLk-
Ttf7pJSZAV_n2TlGlTlgO-YkL-tGi2YFmzg2PLYcXrFJ1cutvtCp3Z_0BvA
6. What does JOSE look like
base64url({JSON JOSE HEADER})
.
base64url({JSON JWT Payload})
.
base64url(signature of previous two)
7. What does JOSE look like
eyJhbGciOiJSUzI1NiIsImp3ayI6eyJrdHkiOiJSU0EiLCJuIjoieVRxNnRPbFdWNnBDdGJMT2Z
5dXZxVzlaeFlramxtX0pWbnZrN0syMEFYakxUV0dmTlI0bUNNU3A0djhuZXdhVUZITnIyYlJUYX
Zxc213Q1U3M3lONUlmclBYcU5sOVdWeTJ2eGh0dnZOM01sVXREWklFVkJDWkl2WVpZVlBsOW82L
W9HbnR6bUZqMmc1bDRERjFRNkc0enRhVGlER2s5V3BHRnNHVW4xNHJyWnR4a0JJeVVfMS1fRjRf
cnR0bHlQcjRSSW02QTM0OGU4cWV5SU9KZW9rbXNQZWNPWnRzN01RenRnVEVmMVJYTnRXQUg4ZGZ
FbG9PT0FpRG1sX0dtU1BCZ0RhYU5MQnhlV3ZPT1FITVU4NU5YbXFLVndkYWJESVcxQTlRUUg3LW
1NMmw0QzVLUGJmcEtvNklhbU5jX0dCRGd3TjFzd2kzcThNcTkwb2UtSmx3IiwiZSI6IkFRQUIif
X0.eydqdGknOidkZWFkYmVlZicsICdtc2cnOidUaGFua3MgZm9yIGNvbWluZyB0byBteSB0YWxr
J30.DQU1MV5NaWadp45mT66oH7-yQ_ltZNTU88gHOnrcnAjxRummFEH7wuAXaHSPChf7pPc-
ZBE5kEMEPFN0e_pY1df58xfabNPlJNpKnZJjiqClYRZ2VZbbB9_ePgj-XxVPgGeAmFakh-
O59xxvyHyG97NKtnBjwtdnvLgp5jnnwIiojh8LXdSmjyo2yJNbj34mluSF1qf3IgVGYUUuJAMy_
lxX8bIXLTnwLxCSd28mK6CqF7yBnmYLx6rzk1KMKkgzDrmLJMSdvwR-JYV6fFSnWixNLk-
Ttf7pJSZAV_n2TlGlTlgO-YkL-tGi2YFmzg2PLYcXrFJ1cutvtCp3Z_0BvA
8. What does JOSE look like (JOSE Header)
eyJhbGciOiJSUzI1NiIsImp3ayI6eyJrdHkiOiJSU0EiLCJuIjoieVRxNnRPbFdWNnBDdGJMT2Z
5dXZxVzlaeFlramxtX0pWbnZrN0syMEFYakxUV0dmTlI0bUNNU3A0djhuZXdhVUZITnIyYlJUYX
Zxc213Q1U3M3lONUlmclBYcU5sOVdWeTJ2eGh0dnZOM01sVXREWklFVkJDWkl2WVpZVlBsOW82L
W9HbnR6bUZqMmc1bDRERjFRNkc0enRhVGlER2s5V3BHRnNHVW4xNHJyWnR4a0JJeVVfMS1fRjRf
cnR0bHlQcjRSSW02QTM0OGU4cWV5SU9KZW9rbXNQZWNPWnRzN01RenRnVEVmMVJYTnRXQUg4ZGZ
FbG9PT0FpRG1sX0dtU1BCZ0RhYU5MQnhlV3ZPT1FITVU4NU5YbXFLVndkYWJESVcxQTlRUUg3LW
1NMmw0QzVLUGJmcEtvNklhbU5jX0dCRGd3TjFzd2kzcThNcTkwb2UtSmx3IiwiZSI6IkFRQUIif
X0.eydqdGknOidkZWFkYmVlZicsICdtc2cnOidUaGFua3MgZm9yIGNvbWluZyB0byBteSB0YWxr
J30.DQU1MV5NaWadp45mT66oH7-yQ_ltZNTU88gHOnrcnAjxRummFEH7wuAXaHSPChf7pPc-
ZBE5kEMEPFN0e_pY1df58xfabNPlJNpKnZJjiqClYRZ2VZbbB9_ePgj-XxVPgGeAmFakh-
O59xxvyHyG97NKtnBjwtdnvLgp5jnnwIiojh8LXdSmjyo2yJNbj34mluSF1qf3IgVGYUUuJAMy_
lxX8bIXLTnwLxCSd28mK6CqF7yBnmYLx6rzk1KMKkgzDrmLJMSdvwR-JYV6fFSnWixNLk-
Ttf7pJSZAV_n2TlGlTlgO-YkL-tGi2YFmzg2PLYcXrFJ1cutvtCp3Z_0BvA
10. What does JOSE look like (JWT Payload)
eyJhbGciOiJSUzI1NiIsImp3ayI6eyJrdHkiOiJSU0EiLCJuIjoieVRxNnRPbFdWNnBDdGJMT2Z
5dXZxVzlaeFlramxtX0pWbnZrN0syMEFYakxUV0dmTlI0bUNNU3A0djhuZXdhVUZITnIyYlJUYX
Zxc213Q1U3M3lONUlmclBYcU5sOVdWeTJ2eGh0dnZOM01sVXREWklFVkJDWkl2WVpZVlBsOW82L
W9HbnR6bUZqMmc1bDRERjFRNkc0enRhVGlER2s5V3BHRnNHVW4xNHJyWnR4a0JJeVVfMS1fRjRf
cnR0bHlQcjRSSW02QTM0OGU4cWV5SU9KZW9rbXNQZWNPWnRzN01RenRnVEVmMVJYTnRXQUg4ZGZ
FbG9PT0FpRG1sX0dtU1BCZ0RhYU5MQnhlV3ZPT1FITVU4NU5YbXFLVndkYWJESVcxQTlRUUg3LW
1NMmw0QzVLUGJmcEtvNklhbU5jX0dCRGd3TjFzd2kzcThNcTkwb2UtSmx3IiwiZSI6IkFRQUIif
X0.eydqdGknOidkZWFkYmVlZicsICdtc2cnOidUaGFua3MgZm9yIGNvbWluZyB0byBteSB0YWxr
J30.DQU1MV5NaWadp45mT66oH7-yQ_ltZNTU88gHOnrcnAjxRummFEH7wuAXaHSPChf7pPc-
ZBE5kEMEPFN0e_pY1df58xfabNPlJNpKnZJjiqClYRZ2VZbbB9_ePgj-XxVPgGeAmFakh-
O59xxvyHyG97NKtnBjwtdnvLgp5jnnwIiojh8LXdSmjyo2yJNbj34mluSF1qf3IgVGYUUuJAMy_
lxX8bIXLTnwLxCSd28mK6CqF7yBnmYLx6rzk1KMKkgzDrmLJMSdvwR-JYV6fFSnWixNLk-
Ttf7pJSZAV_n2TlGlTlgO-YkL-tGi2YFmzg2PLYcXrFJ1cutvtCp3Z_0BvA
11. What does JOSE look like (Body + Claims)
{
'jti':'deadbeef',
'msg':'Thanks for coming to my talk’
}
12. What does JOSE look like
eyJhbGciOiJSUzI1NiIsImp3ayI6eyJrdHkiOiJSU0EiLCJuIjoieVRxNnRPbFdWNnBDdGJMT2Z
5dXZxVzlaeFlramxtX0pWbnZrN0syMEFYakxUV0dmTlI0bUNNU3A0djhuZXdhVUZITnIyYlJUYX
Zxc213Q1U3M3lONUlmclBYcU5sOVdWeTJ2eGh0dnZOM01sVXREWklFVkJDWkl2WVpZVlBsOW82L
W9HbnR6bUZqMmc1bDRERjFRNkc0enRhVGlER2s5V3BHRnNHVW4xNHJyWnR4a0JJeVVfMS1fRjRf
cnR0bHlQcjRSSW02QTM0OGU4cWV5SU9KZW9rbXNQZWNPWnRzN01RenRnVEVmMVJYTnRXQUg4ZGZ
FbG9PT0FpRG1sX0dtU1BCZ0RhYU5MQnhlV3ZPT1FITVU4NU5YbXFLVndkYWJESVcxQTlRUUg3LW
1NMmw0QzVLUGJmcEtvNklhbU5jX0dCRGd3TjFzd2kzcThNcTkwb2UtSmx3IiwiZSI6IkFRQUIif
X0.eydqdGknOidkZWFkYmVlZicsICdtc2cnOidUaGFua3MgZm9yIGNvbWluZyB0byBteSB0YWxr
J30.DQU1MV5NaWadp45mT66oH7-yQ_ltZNTU88gHOnrcnAjxRummFEH7wuAXaHSPChf7pPc-
ZBE5kEMEPFN0e_pY1df58xfabNPlJNpKnZJjiqClYRZ2VZbbB9_ePgj-XxVPgGeAmFakh-
O59xxvyHyG97NKtnBjwtdnvLgp5jnnwIiojh8LXdSmjyo2yJNbj34mluSF1qf3IgVGYUUuJAMy_
lxX8bIXLTnwLxCSd28mK6CqF7yBnmYLx6rzk1KMKkgzDrmLJMSdvwR-JYV6fFSnWixNLk-
Ttf7pJSZAV_n2TlGlTlgO-YkL-tGi2YFmzg2PLYcXrFJ1cutvtCp3Z_0BvA
15. What does JOSE fix?
Json is fairly universally supported. Easy.
No hacky parsing for homebrew solutions required.
Asymmetric key support.
Lots of cryptographic options
Compact and URL Safe.
Useful for many trust models.
URL Safe
16. What vocab do we need?
JSON Web Token (JWT)
JSON Web Encryption (JWE)
JSON Web Signature (JWS)
JSON Web Key (JWK)
JSON Web Algorithms (JWA)
17. JOSE Header
All types of JWTs contain a JOSE Header.
Type, Recommended to be ‘JWT’.
Content Type, image, video, etc.
Algorithm, Variety of algorithms. Sometimes ‘none’.
Certificates, can contain x509 certs, json web keys, or URLs
to published x509 certs
18. JSON Web Signatures (JWS) RFC 7515 (JOSE Header)
Data integrity but no encryption. Like our example.
Key ID, The Key ID used to secure the JWT.
JWK Set URL, URL of public keys.
JSON Web Key, A public key
x509 URL, x509 Chain, x509 Fingerprint (SHA1/2). Must support
TLS
19. JSON Web Encryption (JWE) RFC 7516 (JOSE Header)
Data protection and integrity.
Compression Algorithm, DEFLATE.
Encryption Algorithm, Defined in JWA
Public Keys,
THIS RFC IS MASSIVE
20. What is in the Payload?
JWT ID, Random ID of that individual JWT.
Issued At, Not Before, Expiration, Standard Time Stuff.
Audience, Who is the JWT for. Must be checked.
Issuer, Who issued it? A StringOrUri should go here.
Subject, What is it for? A StringOrUri should go here.
Other, Applications can agree on non-registered claims.
21. JSON Web Algorithms (JWA) RFC 7518
Just a list of supported crypto algorithms, and what is
necessary to use them. Very confusing.
Lots and lots of algorithms
Lots and lots of logic
Lots and lots of special tags for the JOSE Header
23. JWT Best Practices
Compartmentalize. Different keys for each service
Short lived? Long lived? Think about it.
Follow the algorithms for validating and generating. They are
in the RFC (if you’re writing code for this)
Strict JSON Format Checking.
Use a library
24. JWT Best Practices
Distinguish between JWS and JWEs
Look for 5 sections and 4 periods for a JWE.
alg in the header.
Look for payload versus ciphertext
29. JOSE Conclusion
The RFCs are massively over-engineered.
Tons of features. Tons of ways to do things that few use.
It’s getting worse.
Is slow JWT adoption because of this?
JOSE has gotten a lot more popular.
Think about revocation
Hello,
This talk is called JWTs and JOSE in a flash. It is meant to be a quick introduction to this new thing called “JOSE”, and sometimes referred to as JWTs.
I just want to let you know up front. There is no way you will be a JWT or JOSE expert from a 30 minute talk at the DEFCON cryptovillage. There are a lot of details here. JOSE is really wonky and has some strange things so this is more of an introductory talk. With 30 minutes. Hopefully by the end you’ll have a good idea about how JWTs work and how they are used
CloudFlare Security Systems Engineer
I wear a lot of different random hats.
I’m the company’s appsec person
I hunt vulnerabilities and then come up with remediation plans
I write code to fix vulnerabilities
I build security features and help make sure security products work, aren’t able to side step right around, etc.
Wrote all the account management and session stuff on our site.
Previously an engineer at LastPass
Where I got in to this world of password managers I guess.
I would regularly look at how other people’s password managers worked when I was at lastpass and learning what was good what was bad and what needed improvement.
Wrote passgo (https://github.com/ejcx/passgo)
It’s a command line password manager written in golang.
Has modern crypto
JOSE is a standard. Means “javascript object signing and encryption”. Fairly new standardization and it’s recently getting really really popular.
It’s a collection of about 5-7 RFCs that describe all the different acronyms that are required to make this possible
This is a really really big standard and one of the biggest hurdles to understanding the ecosystem is understanding the vocabulary.
JWT.io has a great visualization of the basic how JWTs work and you should definitely check it out.
Used in sessions.
Explain multiple servers.
Information sharing is hard you need a way for multiple servers to communicate with eachother.
Ruby sessions, golang sessions in the gorilla go library, python sessions
This is a JWT…… Viola….
The reason for this slide is to show you all that JWTs
The JOSE specifications have all of these “well known fields” that exist in both the JOSE header and the JWT Payload. This might confuse you if you’re not aware of it with my next slides. It confuses me and I’ve read the RFC 3 times probably so this is pretty normal.
First thing to notice is this is not just a base64 blob of data. It has periods as delimiters. For information.
This is the JOSE Header. It contains information about the JWT
Inside
First thing to notice is this is not just a base64 blob of data. It has periods as delimiters. For information.
First thing to notice is this is not just a base64 blob of data. It has periods as delimiters. For information.
“Thanks for coming to my talk”
This is the signature. No magic here. Signature is generated from the base64 of the jose header plus the body/claims concatenated together and then a signature is generated.
Notice that this is really really strange.
The signature algorithm is part of the signature. When verifying the signature, verifiers need to check the algorithm first in order to verify the signature. Does anyone see anything immediately scary about this
Here are some real digitalocean tokens that you get when you signup and when you verify an email change. These are real.
Just to be clear there is no vulnerability here, but it might indicate some future weaknesses.
DigitalOcean sent me a signup URL and it had multiple purposes. I could use the token at the end of the URL to both, confirm a signup to the website and verify that my email had changed.
This might be undesirable. The two things that this token could be used for are close enough. What happens when they add a new “confirmation” for something more security sensitive.
This thing they rolled out is just an email address and a confirmation. Nothing indicating what the token is for.
Another reason why JOSE is nice is because stateless tokens are sometimes implemented in a way that string formatter bugs are common.
Here is some pseudo-code that kind of shows a way someone might build stateless tokens that have a weakness.
JOSE fixes can’t completely eliminate these vulns that people write, but JOSE is a lot more of a mature framework to use to create stateless tokens.
What problems are JOSE meant to solve? It’s meant to standardize something that tons of people were homebrewing
Json is fairly universally supported. Easy.
No hacky parsing for homebrew solutions required.
Asymmetric key support. Most homebrew solutions don’t have this and it’s really cool
Lots of cryptographic options. I think this is bad
Compact and URL Safe.
Useful for many trust models.
URL Safe
This is kind of a lot of vocab to take in.
JWT is Json web token. This is any token that follows this standard.
JSON Web Encryption, or JWE is any encrypted token.
JSON Web Signature is any signed token. Integrity only. This distinction is somewhere a lot of people make mistakes
JSON Web Key is pretty neat. It’s a way to encode asymmetric key information, and it’s metadata as a JSON object.
We will talk about that more in a minute
JWE and JWS both have a JOSE header. Has information about the algorithms in the jwt’s.
All types of JWTs contain a JOSE Header.
Type, Recommended to be ‘JWT’.
Content Type, image, video, etc.
Algorithm, Variety of algorithms. Sometimes ‘none’.
Certificates, can contain x509 certs, json web keys, or URLs to published x509 certs
A JWT that is “plaintext” (base64’d) with a signature. This is what edge auth uses. Go check beyond.cloudflare.com, log in and check out your CF_Authorization cookie.
Data integrity but no encryption. Like our example.
Key ID, The Key ID used to secure the JWT.
JWK Set URL, URL of public keys.
JSON Web Key, A public key
x509 URL, x509 Chain, x509 Fingerprint (SHA1/2). Must support TLS
AFAIK we don’t use this here. It’s much more complex than JWS, but in instances where the data inside the jwt is sensitive it should be used. For example, Customer data in a JWT? Use JWE.
These are what the RFC says are standard and have predetermined meaning if they exist in a jwt. You can add whatever you’d like though.
JWT ID, Random ID of that individual JWT.
Issued At, Not Before, Expiration, Standard Time Stuff.
Audience, Who is the JWT for. Must be checked.
Issuer, Who issued it? A StringOrUri should go here.
Subject, What is it for? A StringOrUri should go here.
Other, Applications can agree on non-registered claims.
There is a whole RFC about what algorithm choices are allowed.
Here’s a screenshot with SOME of the new names of stuff from the RFC. There’s more.
This bug is amazing. Alg none
There are a lot of considerations.
This is my friend from Slack who is trying to learn more security and crypto stuff. He’s great and super motivated but it means he tries stuff often and is wrong a lot and learns quickly.
He had messaged me
One of the biggest problems I see with JWTs is you’re putting a lot of cryptography firepower in to the hands of people who are not necessarily crypto literate. They might not know if something is horribly broken.
The RFCs are massively over-engineered.
Tons of features. Tons of ways to do things that few use.
It’s getting worse.
Is slow JWT adoption because of this?
JOSE has gotten a lot more popular.
Think about revocation. If you NEED revocation. This is not for you. You can’t really revoke things in stateless systems.