~1 min read

JWT tokens - Brute-force attack!!

Have you thought about using JSON Web Tokens (JWT) instead of cookies? šŸ¤” Let me tell you, JWTs are NOT ANY BETTER than session cookies... they are just applicable in different use-cases (with their own pros and cons). Let's look at one important risk that comes with using the JWT tokens šŸ‘‰ The Brute-force attack!!

Ok, what is JWT?

JSON Web Tokens are stateless tokens that clients use to authenticate requests. These tokens have a signature attached so the server can verify their authenticity and integrity at each request.

What's the problem here? The cryptographic signature to be generated requires a secret key. In a Web applications scenario, this secret key should be known only to confidential server-side code. The problem is that if it's too weak (too short), it may be guessed! Like a regular password. And it may be guessed with powerful cloud infrastructure without any additional calls to attacked backed. šŸ˜±

Look below at the screenshot from jwt.io website.

jwt.jpeg

On the left, we have the encoded JWT. It's just simple Base64. On the right side, we can see the Header, Payload, and Signature of this token. The secret key used to sign this token is "secret123", which is not known at the front end.

What now? The attacker uses any kind of automated tool to find this secret key with brute-force fashion** trying every possible character combination**. And if the secret key is found, the attacker may generate ANY VALID tokens, actually being able to impersonate any user.

ā€‹ The solution? Actually, there is a simple solution. Use a STRONG secret, so that brute-force attack would take even hundreds of years on the most powerful infrastructure.

So what is strong enough? According to Auth0.com: Make sure to pick a shared-key as long as the length of the hash. For HS256 that would be a 256-bit key (or 32 bytes) minimum.