2

I'm building an authentication system that I want to be secure. I plan on using JWT tokens as the main authentication mechanism. When the token expires, the server will return a "401 unauthorized" response, and I would like the client to be able to perform a silent refresh. Typically this is done using a refresh token. I was wondering what the security implications would be of using the user's password hash as the refresh token?

In addition to doing this, I was planning to include the password hash within the JWT. When the JWT is verified, my app will check that the password hash in the JWT matches the user's current password hash. If they are different, the server will tell the client to log the user out.

Are there any security flaws in this process that I'm missing?

5

Well, you've converted your short-lived access token into a refresh token because you're storing the refresh token in the access token. That pretty much defeats the purpose of using an access token.

It's also usually unwise to send the password hash to the client because these things tend to get leaked through bugs or overzealous logging and that makes it possible to brute force the password offline (though you already have access to the client, so...). It also means you can't revoke the refresh without forcing a password change. That might be fine, but it's also potentially annoying for the user. The refresh should have an expiration too.

In general you should never reuse secrets for things that weren't their intended purpose. You should use a dedicated value for the refresh token, whether its a pointer to some value in the database, or a token itself signed by a secret key plus expiration. And you shouldn't store the refresh token in the access token.

All of that adds up to the usual recommendation of: don't roll your own. Find a library or service that already does this for you. There's plenty of them out there that are free or cheap, and many have excellent track records for security.

3
  • Thank you for your response. Regarding "you've converted your short-lived access token into a refresh token because you're storing the refresh token in the access token". I don't think this is the case. Clients can't decrypt JWT tokens (they are secured by a server-side secret).
    – SamB
    Apr 15 '20 at 23:47
  • 2
    @SamB JWTs generally aren't encrypted. They're signed using a server secret; that isn't the same as encryption. (It is possible to encrypt a JWT, of course, but it kind of defeats the purpose of using JWT in the first place). Apr 16 '20 at 0:10
  • For some reason I thought they were encrypted. Thank you.
    – SamB
    Apr 16 '20 at 4:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.