Cracking JWT tokens: a tale of magic, Node.js and parallel computing - Code Europe Wroclaw December 2017
2 likes1,681 views
The document discusses the workings of JSON Web Tokens (JWT), explaining their structure, how they are created, and the security implications of using them. It highlights the simplicity and stateless nature of JWT while also addressing the risks of data exposure and brute force attacks. The author emphasizes using strong secrets for signing JWTs and the importance of not including sensitive information in the payload.
![bijection (int) (string)
if we sort all the possible strings over an alphabet
Alphabet = [a,b]
0 âś (empty string)
1 âś a
2 âś b
3 âś aa
4 âś ab
5 âś ba
6 âś bb
7 âś aaa
8 âś aab
9 âś aba
10 âś abb
11 âś baa
12 âś bab
13 âś bba
14 âś bbb
15 âś aaaa
16 âś aaab
17 âś aaba
18 âś aabb
...
50](https://image.slidesharecdn.com/cracking-jwt-tokens-a-tale-of-magic-nodejs-and-parallel-computing-wroclaw-171213164431/85/Cracking-JWT-tokens-a-tale-of-magic-Node-js-and-parallel-computing-Code-Europe-Wroclaw-December-2017-50-320.jpg)
![The first client connects
{
"cursor": 3,
"clients": {
"client1": [0,2]
}
}
[0,2]
55](https://image.slidesharecdn.com/cracking-jwt-tokens-a-tale-of-magic-nodejs-and-parallel-computing-wroclaw-171213164431/85/Cracking-JWT-tokens-a-tale-of-magic-Node-js-and-parallel-computing-Code-Europe-Wroclaw-December-2017-55-320.jpg)
![{
"cursor": 9,
"clients": {
"client1": [0,2],
"client2": [3,5],
"client3": [6,8]
}
}
Other clients connect
[0,2]
[3,5] [6,8]
56](https://image.slidesharecdn.com/cracking-jwt-tokens-a-tale-of-magic-nodejs-and-parallel-computing-wroclaw-171213164431/85/Cracking-JWT-tokens-a-tale-of-magic-Node-js-and-parallel-computing-Code-Europe-Wroclaw-December-2017-56-320.jpg)
![Client 2 finishes its job
{
"cursor": 12,
"clients": {
"client1": [0,2],
"client2": [9,11],
"client3": [6,8]
}
}
[0,2]
[9,11] [6,8]
57](https://image.slidesharecdn.com/cracking-jwt-tokens-a-tale-of-magic-nodejs-and-parallel-computing-wroclaw-171213164431/85/Cracking-JWT-tokens-a-tale-of-magic-Node-js-and-parallel-computing-Code-Europe-Wroclaw-December-2017-57-320.jpg)
![let cursor = 0
const clients = new Map()
const assignNextBatch = client => {
const from = cursor
const to = cursor + batchSize - 1
const batch = [from, to]
cursor = cursor + batchSize
client.currentBatch = batch
client.currentBatchStartedAt = new Date()
return batch
}
const addClient = channel => {
const id = channel.toString('hex')
const client = {id, channel, joinedAt: new Date()}
assignNextBatch(client)
clients.set(id, client)
return client
} Server
58](https://image.slidesharecdn.com/cracking-jwt-tokens-a-tale-of-magic-nodejs-and-parallel-computing-wroclaw-171213164431/85/Cracking-JWT-tokens-a-tale-of-magic-Node-js-and-parallel-computing-Code-Europe-Wroclaw-December-2017-58-320.jpg)
![const router = (channel, rawMessage) => {
const msg = JSON.parse(rawMessage.toString())
switch (msg.type) {
case 'join': {
const client = addClient(channel)
const response = {
type: 'start',
id: client.id,
batch: client.currentBatch,
alphabet,
token
}
batchSocket.send([channel, JSON.stringify(response)])
break
}
case 'next': {
const batch = assignNextBatch(clients.get(channel.toString('hex')))
batchSocket.send([channel, JSON.stringify({type: 'batch', batch})])
break
}
case 'success': {
const secret = msg.secret
// publish exit signal and closes the app
signalSocket.send(['exit', JSON.stringify({secret, client: channel.toString('hex')})], 0, () => {
batchSocket.close()
signalSocket.close()
exit(0)
})
break
}
}
}
Server
60](https://image.slidesharecdn.com/cracking-jwt-tokens-a-tale-of-magic-nodejs-and-parallel-computing-wroclaw-171213164431/85/Cracking-JWT-tokens-a-tale-of-magic-Node-js-and-parallel-computing-Code-Europe-Wroclaw-December-2017-60-320.jpg)
![How a chunk is processed
Given chunk [3,6] over alphabet "ab"
[3,6]
3 âś aa
4 âś ab
5 âś ba
6 âś bb
â check if one of the
strings is the secret
that validates the
current token
62](https://image.slidesharecdn.com/cracking-jwt-tokens-a-tale-of-magic-nodejs-and-parallel-computing-wroclaw-171213164431/85/Cracking-JWT-tokens-a-tale-of-magic-Node-js-and-parallel-computing-Code-Europe-Wroclaw-December-2017-62-320.jpg)
Cracking JWT tokens: a tale of magic, Node.js and parallel computing - Code Europe Wroclaw December 2017
- 1. Cracking JWT tokens a tale of magic, Node.js and parallel computing Wroclaw - 13 DEC 2017 Luciano Mammino ( )@loige loige.link/jwt-crack-wroclaw 1
- 3. Luciano... who!? Visit my castles: (@loige) (lmammino) Twitter GitHub Linkedin https://loige.co Yet another "Fullstack" engineer 3
- 4. Based on prior work Chapters 10 & 11 in (book) 2-parts article on RisingStack: " " Node.js design patterns ZeroMQ & Node.js Tutorial - Cracking JWT Tokens github.com/lmammino/jwt-cracker github.com/lmammino/distributed-jwt-cracker 4
- 5. Agenda What's JWT How it works Testing JWT tokens Brute-forcing a token! 5
- 6. â RFC 7519 is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. JSON Web Token (JWT) 6
- 8. OK Let's try to make it simpler... 8
- 9. JWT is... An URL safe, stateless protocol for transferring claims 9
- 11. URL Safe... It's a string that can be safely used as part of a URL (it doesn't contain URL separators like "=", "/", "#" or "?") unicorntube.pl/?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... 11
- 12. Stateless? Token validity can be verified without having to interrogate a third-party service (Sometimes also defined as "self-contained") 12
- 13. What is a claim? 13
- 14. some information to transfer identity (login session) authorisation to perform actions (api key) ownership (a ticket belongs to somebody) 14
- 15. also... validity constraints token time constraints (dont' use before/after) audience (a ticket only for a specific concert) issuer identity (a ticket issued by a specific reseller) 15
- 16. also... protocol information Type of token Algorithm 16
- 17. In general All the bits of information transferred with the token 17
- 21. Header and Payload are encoded let's decode them! Base64Url 21
- 22. HEADER: The decoded info is JSON! PAYLOAD: {"alg":"HS256","typ":"JWT"} {"message":"hello Wroclaw"} 22
- 23. HEADER: {"alg":"HS256","typ":"JWT"} alg: the kind of algorithm used "HS256" HMACSHA256 Signature (secret based hashing) "RS256" RSASHA256 Signature (public/private key hashing) "none" NO SIGNATURE! (This is " ")infamous 23
- 24. PAYLOAD: {"message":"hello Wroclaw"} Payload can be anything that you can express in JSON 24
- 25. PAYLOAD: "registered" (or standard) claims: iss: issuer ID ("auth0") sub: subject ID ("[email protected]") aud: audience ID ("https://someapp.com") exp: expiration time ("1510047437793") nbf: not before ("1510046471284") iat: issue time ("1510045471284") 25
- 26. PAYLOAD: "registered" (or standard) claims: { "iss": "auth0", "sub": "[email protected]", "aud": "https://someapp.com", "exp": "1510047437793", "nbf": "1510046471284", "iat": "1510045471284" } 26
- 27. So far it's just metadata... What makes it safe? 27
- 28. SIGNATURE: ZvoTYTP6RrnOYWY_5n1BAff 7P3WEEEbgdzCAJ8kPQLA A Base64URL encoded cryptographic signature of the header and the payload 28
- 29. With HS256 signature = HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret ) header payload secret SIGNATURE+ + = 29
- 30. If a system knows the secret It can verify the authenticity of the token With HS256 30
- 31. Let's create a token from scratch runkit.com/lmammino/create-jwt-token 31
- 35. Browser 1. POST /login 2. generate session id:"Y4sHySEPWAjc" user:"luciano" user:"luciano" pass:"mariobros" 3. session cookie SID:"Y4sHySEPWAjc" 4. GET /profile 5. query id:"Y4sHySEPWAjc" 6. record id:"Y4sHySEPWAjc" user:"luciano" 7. (page) <h1>hello luciano</h1> Server 35 Sessions Database id:"Y4sHySEPWAjc" user:"luciano"SID:"Y4sHySEPWAjc"
- 37. Browser 1. POST /login 3. JWT Token {"sub":"luciano"} user:"luciano" pass:"mariobros" 6. (page) <h1>hello luciano</h1> Server eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ zdWIiOiJsdWNpYW5vIn0.V92iQaqMrBUhkgEAyRa CY7pezgH-Kls85DY8wHnFrk4 4. GET /profile eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ zdWIiOiJsdWNpYW5vIn0.V92iQaqMrBUhkgEAyRa CY7pezgH-Kls85DY8wHnFrk4 Token says this is "luciano" Signature looks OK 5. verify Create Token for "luciano" Add signature 2. create JWT Note: Only the server knows the secret 37
- 38. Cookie/session Needs a database to store the session data The database is queried for every request to fetch the session A session is identified only by a randomly generated string (session ID) No data attached Sessions can be invalidated at any moment JWT Doesn't need a session database The session data is embedded in the token For every request the token signature is verified Attached metadata is readable Sessions can't be invalidated, but tokens might have an expiry flag VS 38
- 39. JWT LOOKS GREAT! But there are pitfalls... 39
- 40. Data is public! If you have a token, you can easily read the claims! You only have to Base64Url-decode the token header and payload and you have a readable JSON 40
- 41. There's no token database... ...if I can forge a token nobody will know it's not authentic! 41
- 42. DEMO JWT based web app github.com/lmammino/sample-jwt-webapp BUILT WITH 42
- 43. Given an HS256 signed JWT We can try to "guess" the secret! 43
- 44. How difficult can it be? 44
- 45. Let's build a distributed JWT token cracker! npm.im/distributed-jwt-cracker 45
- 46. The idea... YOU CAN NOW CREATE AND SIGN ANY JWT TOKEN FOR THIS APPLICATION! if the token is validated, then you found the secret! try to "guess" the secret and validate the token against it Take a valid JWT token 46
- 48. ZeroMQ an open source embeddable networking library and a concurrency framework 48
- 49. The brute force problem "virtually infinite" solutions space all the strings (of any length) that can be generated within a given alphabet (empty string), a, b, c, 1, aa, ab, ac, a1, ba, bb, bc, b1, ca, cb, cc, c1, 1a, 1b, 1c, 11, aaa, aab, aac, aa1, aba, ... 49
- 50. bijection (int) (string) if we sort all the possible strings over an alphabet Alphabet = [a,b] 0 âś (empty string) 1 âś a 2 âś b 3 âś aa 4 âś ab 5 âś ba 6 âś bb 7 âś aaa 8 âś aab 9 âś aba 10 âś abb 11 âś baa 12 âś bab 13 âś bba 14 âś bbb 15 âś aaaa 16 âś aaab 17 âś aaba 18 âś aabb ... 50
- 51. Architecture Server Client Initialised with a valid JWT token and an alphabet coordinates the brute force attempts among connected clients knows how to verify a token against a given secret receives ranges of secrets to check 51
- 52. Networking patterns Router channels: dispatch jobs receive results Pub/Sub channel: termination signal 52
- 53. Server state the solution space can be sliced into chunks of fixed length (batch size) 0 ...batch 1 batch 2 batch 3 3 6 9 ... 53
- 54. Initial server state { "cursor": 0, "clients": {} } 54
- 55. The first client connects { "cursor": 3, "clients": { "client1": [0,2] } } [0,2] 55
- 56. { "cursor": 9, "clients": { "client1": [0,2], "client2": [3,5], "client3": [6,8] } } Other clients connect [0,2] [3,5] [6,8] 56
- 57. Client 2 finishes its job { "cursor": 12, "clients": { "client1": [0,2], "client2": [9,11], "client3": [6,8] } } [0,2] [9,11] [6,8] 57
- 58. let cursor = 0 const clients = new Map() const assignNextBatch = client => { const from = cursor const to = cursor + batchSize - 1 const batch = [from, to] cursor = cursor + batchSize client.currentBatch = batch client.currentBatchStartedAt = new Date() return batch } const addClient = channel => { const id = channel.toString('hex') const client = {id, channel, joinedAt: new Date()} assignNextBatch(client) clients.set(id, client) return client } Server 58
- 59. Messages flow JWT Cracker Server JWT Cracker Client 1. JOIN 2. START {token, alphabet, firstBatch} 3. NEXT 4. BATCH {nextBatch} 5. SUCCESS {secret} 59
- 60. const router = (channel, rawMessage) => { const msg = JSON.parse(rawMessage.toString()) switch (msg.type) { case 'join': { const client = addClient(channel) const response = { type: 'start', id: client.id, batch: client.currentBatch, alphabet, token } batchSocket.send([channel, JSON.stringify(response)]) break } case 'next': { const batch = assignNextBatch(clients.get(channel.toString('hex'))) batchSocket.send([channel, JSON.stringify({type: 'batch', batch})]) break } case 'success': { const secret = msg.secret // publish exit signal and closes the app signalSocket.send(['exit', JSON.stringify({secret, client: channel.toString('hex')})], 0, () => { batchSocket.close() signalSocket.close() exit(0) }) break } } } Server 60
- 61. let id, variations, token const dealer = rawMessage => { const msg = JSON.parse(rawMessage.toString()) const start = msg => { id = msg.id variations = generator(msg.alphabet) token = msg.token } const batch = msg => { processBatch(token, variations, msg.batch, (secret, index) => { if (typeof secret === 'undefined') { // request next batch batchSocket.send(JSON.stringify({type: 'next'})) } else { // propagate success batchSocket.send(JSON.stringify({type: 'success', secret, index})) exit(0) } }) } switch (msg.type) { case 'start': start(msg) batch(msg) break case 'batch': batch(msg) break } } Client 61
- 62. How a chunk is processed Given chunk [3,6] over alphabet "ab" [3,6] 3 âś aa 4 âś ab 5 âś ba 6 âś bb â check if one of the strings is the secret that validates the current token 62
- 63. const jwt = require('jsonwebtoken') const generator = require('indexed-string-variation').generator; const variations = generator('someAlphabet') const processChunk = (token, from, to) => { let secret for (let i = from; i < to; i++) { try { secret = variations(i) jwt.verify(token, pwd, { ignoreExpiration: true, ignoreNotBefore: true }) // finished, password found return ({found: secret}) } catch (err) {} // password not found, keep looping } // finished, password not found return null } Client 63
- 64. Demo 64
- 65. Closing off 65
- 66. Is JWT safe to use? 66
- 68. but... 68
- 69. Use a strong (âlong) secret and keep it SAFE! Or, even better Use RS256 (RSA public/private key pair) signature Use it wisely! 69
- 70. But, what if I create only short lived tokens... 70
- 71. JWT is STATELESS! the expiry time is contained in the token... if you can edit tokens, you can extend the expiry time as needed! 71
- 72. Should I be worried about brute force? 72
- 73. Not really ... As long as you know the basic rules (and the priorities) to defend yourself 73
- 74. TLDR; JWT is a cool & stateless⢠way to transfer claims! Choose the right Algorithm With HS256, choose a good secret and keep it safe Don't disclose sensitive information in the payload Don't be too worried about brute force, but understand how it works! 74
- 76. Credits vector images designed by freepik an heartfelt thank you to: @AlleviTommaso @andreaman87 @cirpo @katavic_d @Podgeypoos79 @quasi_modal 76