Do You Use Token-Based Authentication? Here’s a Security Vulnerability to Look out For.

Deji Atoyebi
Aug 19, 2019 · 3 min read

For what it’s worth, I love token-based authentication and think it trumps some of what session-based authentication has to offer. However, the stateless-ness associated with this authentication mechanism throws certain security vulnerabilities into the mix, some of which developers don’t really take into consideration. Here’s an example:

Imagine this…

You’ve created a non-trivial web application with thousands of users. Quite crucial, your web application needs to implement cutting-edge access control mechanisms as any security breach shall put your users at risk of losing money, data and whatnot.

Here’s a probable vulnerability which you possibly have never thought about:

If an account on your app gets hacked and the victim is notified to reset her password, since we are using tokens for authentication (not sessions — of which a session can be invalidated upon password reset), even if the victim resets her password immediately, the hacker would still have access to the account until the token expires, as long as she (the hacker) doesn’t try to re-authenticate on her own end.

Imagine the expiry time of a token is, say, 12 hours. Now, that’s jeopardy.

In fact, it really doesn’t matter how long a token lasts; the purpose of a password reset at the event of an attack is to reclaim one’s account and to immediately shut out an attacker (he or she shouldn’t have even a second more access — all API calls should return Forbidden upon password reset).

Ideally, what we want is for all prior connections emanating from an account to be forced to re-authenticate when a password reset is undertaken. This article provides a solution to this problem — and it’s quite simple.

First, always record the time of password creation.

For SQL databases, this is as easy as having a DATETIME column in your Users (or whatever) table. For our case, let’s name this column “password_created_at”.

Whenever a user resets her password, the password_created_at field for that account should be updated to the time the new password was generated.


Append password_created_at to tokens

When signing in a user, after verifying her details, we need to append not just id, name and whatnot to the payload of our token but also our password_created_at detail. Using Node.js as an example, our code will look something like this:

jwt.sign({ password_created_at: user.password_created_at }, secret, options})

Having password_created_at with other relevant data in our payload allows us to…

Make Comparisons

Remember: whenever there’s a password reset, we want to update our password_created_at column to the new time.

Now, what you’d want to do is to create a middleware that first decodes the password_created_at (PCA1) data in a token’s payload, and then compares it to the actual password_created_at detail (PCA2) of a user stored in database. If PCA1 != PCA2, then it means a password reset has occurred, and we must forbid the request from continuing.

Since a token is issued when a user signs in, we are sure that a hacker who signed in before a password reset would have his PCA1 < PCA2.

We can apply this middleware function to every critical route in our application. And that’s it.

It would be reasonable to make a case that this solution defeats one of the purposes of implementing a token-based authentication mechanism: to avoid calling the database or memory to verify a necessary detail for each request. However, I think this is a trade-off we have to make to ensure some security.

Do you have better solutions to this problem? Kindly share in the comments section.

You can follow me here on medium, on Twitter, or contact me via email:

Written by

Software developer with a keen eye for social products. Currently @theflutterwave.

More From Medium

Top on Medium

Top on Medium

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade