What is the impact of an exposed secret key for a JWT token implementation?

Question

I am currently using JWT implementation for the authentication part of my APIs.
A private key is used to sign the token generated and used to make sure it's not tampered with when it's used later for other API.
My question is - What is the impact if this private key is leaked? What can the bad guy do with it?
From here, my understanding is that the payload can be altered. Hence, in that example, a normal user can be changed to admin. But in my scenario, I don't have any other important fields except expiration date.

So other than the bad guy able to forever extend his own token expiry date, what are the other impacts that I am facing?

phisch · Accepted Answer

Whoever possesses the private key can create valid tokens where your system simply can not distinguish between a legitimate token and a token created by the attacker.
I am guessing you are not just using the expiry field but also the subject field sub, which is in short terms the logged in user.
With the private key, I can create a token with any subject I want, thus sign in as any user of your system.
As you stated, I can also add any other claim and you system has no choice but trust it, as I was able to create a valid signature.
It can not be stressed enough, but JWT heavily relies on the private key to stay absolutely private. Losing the private key is the worst case scenario.

XjeaxaxX · Answer

I agree with the accepted answer above, except for it being the "worst case scenario".  I don't think you need to be quite that scared.  At worst, if your private key is leaked, you could just generate and use a new one.  Your users with tokens that were valid up until this point will now have invalid tokens... so they'll have to re-authenticate, etc.  It really depends on the context of what you use the tokens for in the first place.
Perhaps a scenario that is worse is if your private key were leaked and you didn't know about it.  And if your data is that sensitive, and especially if you can assume short-term expirations... it might not be a bad idea to generate and then update your private key on a regular basis when it's OK to kick users off the system.  That way a leaked private key is less likely to be damaging.
(Sorry... I know I shouldn't respond to another answer in my answer, but I can't actually add a comment to that answer, which is what I would prefer to do!)

WhiteHotLoveTiger · Answer

Having a leaked private key would be equivalent to issuing JWTs using only the header and payload sections, and trusting any such JWT a user sends you.
If the private key isn't private, there's no protection offered by the signature section anymore, so you might as well leave it off. Now you'll save bandwidth with smaller JWTs and you'll save CPU time from not having to generate or verify signatures! Nice. ;)
Without a signature section (either literally or effectively) a user can easily update the header and payload however they like, and you have to believe that what they're sending you is what you gave them in the first place.
Even if there's currently nothing particularly sensitive a malicious user could gain access to with your service, you might expand your capabilities in the future, and if you're still using that same leaked key, it's going to become a bigger problem.

What is the impact of an exposed secret key for a JWT token implementation?

3 Answers

Add your own answers!

Ask a Question