An ultimate guide for securing JWT tokens (2024)

Most of applications now a days uses JWT authorisation, JWT is one of the best way of handling sessions and authorisation, but this comes up with its own problems. In this article we will discussing about what vulnerabilities JWT will create and how to avoid from getting your applications hacked.

JWTs can be best and secure but it is very secured only if it is used in the right way.

Initially let’s start discussing with the common mistakes we developers do like which will create chance for hackers to perform malicious stuff one such common vulnerabilities are listed below

1. Algorithm manipulation (Using None as the algorithm, Using symmetric encryption (HMAC) instead of asymmetric RSA)
2. Lack of signature validation
3. Secret keys leaking through another attack (like directory traversal, XXE, or SSRF)
4. Key ID (KID) manipulation (Directory traversals, SQL injections, Command injections)
5. JKU/JWK/x5u/x5c headers used sending rogue keys
6. Information leaks in JWT when developers forget that base64 encoding is not encrypting

The above are some of the most common mistakes developers do while implementing JWT, avoiding these can improve the security of your applications. Well most of the companies already might have took care of these common vulnerabilities but there are some vulnerabilities we should look into in making our applications more secured

Attacks like token stealing, XSS, Middle man attacks are still possible.

Imagine someone is using your application by using a public network (In a coffee shop, mall, airport, railway station etc) the router admin can have full access of the network transmissions happening from the connected devices (Mostly we believe the routers are secure which i mean we trust the public network but this can be a case if the owner of the public network is a hacker)and admin can also able to intercept these network calls, since the applications repeatedly send the JWT tokens on each request a hacker can able to steal JWT token of that particular user.

Similarly a hacker can also connect his device to same network and can fool other network devices and connects to hacker device and hacker device to the public network such techniques are called IP Spoofing

That’s how a middle man can enter in a network and can intercept & view all the sensitive tokens from the network can use someone else authorisation to illegal usage.

Next steps a hacker do after stealing a JWT is to change the account identifiers like mobile number and email id and can gain full access of someone’s account.

So, now the point comes on how to securely send/receive a JWT token

Take 5 mins or sometime and think on how you can handle this case…

You might have come up with an approach of using RSA like encrypting on the server side with a sending to client and decrypting there with the public key and on the client side for making a request we can encrypt the JWT with public key and server can decrypt with the private key, yes this will work! but this can increase the strength of your application yet still you are vulnerable to middle man attack, but how ?

RSA is one of the best and reliable encryption method with us for more than 20+ years and we mostly use, but RSA is also vulnerable to middle man attack.

Let’s discuss with an example,

Imagine some one is using your application in a public network and some hacker is also sitting in the same area connected to same network, let’s assume that the hacker performed IP Spoofing and he is now able to you track the users network activity.

So let’s assume that the user authenticated with his credentials and server on the backend is ready to send a token encrypted with the private key.

At this state the client application is expecting the hashed JWT, public key

So the hacker can see a hash in the response and he can decrypt with the public key and able to view the JWT token & what hacker can do is he can create his own public and private key-pair and encode the JWT (which he decrypted with public key) with his own private key and sends back his public key and encrypted hash (which is encrypted by the hacker with his own key pair). At this point the client app uses the public key received and tries decrypting the hash and the client gets the token… now you can observe that the middle man has created his position here in between the server and client.

Client application assuming the middle man as server and server is assuming that the middle man is the end user

So for all the further requests from the client application hacker can decrypt with his private key he can view and encrypts it with the server public key and sends back to server and this happens vice versa…

See Also

Session Tokens Vs. JWTs: Choosing Your Session Management Solution - DevOps.com

So, we have to think of something better which is more secured for exchanging token.

So how can we securely exchange the JWT, So the solution is to use the Diffie hellman key exchange

Diffie hellman key exchange, is one of the most popular and secured token exchange algorithm. End to end chat applications, modern browsers, SSH etc uses this algorithm to secure the network

The main concept of Diffie hellman algorithm is not to send the share the keys but to generate an symmetric key together(Which i mean client and server)

So this is how Diffie hellman key exchange works.

The process starts with choosing 2 right prime numbers, the big the prime number is the more harder the encryption will be to break.

the client app will create its own private key and the server creates its own private key.

Let’s use the help of a very popular example used for explaining this algorithm, The colour analogy

The common from the below diagram is the prime number combination that both parties are settled with.

Assume that Alice is client app and Bob as server.

Initially Bob will create a combination GY and sends it to Alice, and Alice will also creates a combination with his private key RY and sends its to Bob

Now Alice have GY (Which received from Bob) and his private key R and he will mix RY with his secret key and forms RGY

and Bob have RY and his private key G and he will mix RY and forms RGY

and now both the parties end up with a common secret key then both the parties uses that same key to encrypt and decrypt and send the encrypted data which no one can decrypt, and this is how Diffie hellman works.

The only keys to anyone in between can see is RY, GY and Ywhich it’s impossible to separate G and R since it will be mixed with Y which will be a massive set of prime number combination.

this style of adding stuff is called modular arithmetic.

Let’s get in to some math

To ensure security, it is recommended that the prime (p) is at least 2048 bits long, which is the binary equivalent of a decimal number of about this size:

415368757628736598425938247569843765827634879128375827365928736 84273684728938572983759283475934875938475928475928739587249587 29873958729835792875982795837529876348273685729843579348795827 93857928739548772397592837592478593867045986792384737826735267 3547623568734869386945673456827659498063849024875809603947902 7945982730187439759284620950293759287049502938058920983945872 0948602984912837502948019371092480193581037995810937501938507913 95710937597019385089103951073058710393701934701938091803984091804 98109380198501398401983509183501983091079180395810395190395180935 8109385019840193580193840198340918093851098309180019

To prevent anyone’s head from exploding, we’ll run this explanation through with much smaller numbers. Be aware that the Diffie-Hellman key exchange would be insecure if it used numbers as small as those in our example. We are only using such small numbers to demonstrate the concept in a simpler manner.

In the most basic form of the Diffie-Hellman key exchange, Alice and Bob begin by mutually deciding upon two numbers to start with, as opposed to the single common paint in the example above. These are the modulus (p) and the base (g).

In practical use, the modulus (p) is a very large prime number, while the base (g) is relatively small to simplify calculations. The base (g) is derived from a cyclic group (G) that is normally generated well before the other steps take place.

For our example, let’s say that the modulus (p) is 17, while the base (g) is 4.

Once they have mutually decided on these numbers, Alice settles on a secret number (a) for herself, while Bob chooses his own secret number (b). Let’s say that they choose:

a = 3

b = 6

Alice then performs the following calculation to give her the number that she will send to Bob:

A = ga mod p

In the above calculation, mod signifies a modulo operation. These are essentially calculations to figure out the remainder after dividing the left side by the right. As an example:

15 mod 4 = 3

If you understand how modulo operations work, you can do them yourself in the following calculations, otherwise you can use an online calculator.

So let’s put our numbers into the formula:

A = 43 mod 17

A = 64 mod 17

A = 13

When we do the same for Bob, we get:

B = 46 mod 17

B = 4096 mod 17

B = 16

Alice then sends her result (A) to Bob, while Bob sends his figure (B) to Alice. Alice then calculates the shared secret (s) using the number she received from Bob (B) and her secret number (a), using the following formula:

s = Ba mod p

s = 163 mod 17

s = 4,096 mod 17

s = 16

Bob then performs what is essentially the same calculation, but with the number that Alice sent him (A), as well as his own secret number (b):

s = Ab mod p

s = 136 mod 17

s = 4,826,809 mod 17

s = 16

As you can see, both parties ended up with the same result for s, 16. This is the shared secret, which only Alice and Bob know. They can then use this to set up a key for symmetric encryption, allowing them to safely send information between themselves in a way that only they can access it.

In the real world, the Diffie-Hellman key exchange is rarely used by itself. The main reason behind this is that it provides no authentication, which leaves users vulnerable to man-in-the-middle attacks.

These attacks can take place when the Diffie-Hellman key exchange is implemented by itself, because it has no means of verifying whether the other party in a connection is really who they say they are. Without any form of authentication, users may actually be connecting with attackers when they think they are communicating with a trusted party.

For this reason, the Diffie-Hellman key exchange is generally implemented alongside some means of authentication. This often involves using digital certificates and a public-key algorithm, such as RSA, to verify the identity of each party.

So let’s check an example on how we can implement Diffie hellman with RSA

Initially, Bob and Alice will settle up with a RSA private and public key-pair

So if we talk about our old example of R, G, Y… while Bob sending GY to Alice, bob will have to send additional parameter which is hashed with the private key, So bob will send GY, Hash(GY).

Alice on receiving GYuses the public key to decrypt and verifies weather the decrypted value is same as GYand if it is then Alice will take GY… This is how RSA can help us in verifying weather the request from server or through by a middle man.

Ultimately as we keep on digging we are adding more more layers of security with which it becomes harder and harder for hackers even for the modern computers to reverse the key combinations.

There are more better ways of key exchanges just like Diffie hellman called Elliptic curves which involves great math which eventually makes impossible for hackers and computers to decrypt.

We will be discussing about the ways encrypting with Elliptic curves in my next article… Stay tune for that!