CODEWITHSUNDEEP
node.jssecurityjwt
user234562
user234562

Reputation: 627

JSON web token - password in the payload?

If I create a JWT token what data should be in the payload? I looked online for some examples and explanations, some people place the password in the JWT, some don't.

Right now I am passing the following data:

{ 
  id: 57,
  username: 'test',
  email: '[email protected]',
  password: '[HASHED PASSWORD]',
  iat: 1529992818 
}

It doesn't feel right to put the hashed password into the JWT payload, because the JWT will be placed in the front-end application. Should it be there?

What are the best practices?

Upvotes: 4

Views: 4493

Answers (2)

al3xand3r96
al3xand3r96

Reputation: 85

Storing the password could actually have some use, but it requires some imagination.

Assume that an attacker obtains the private key (which is being used to sign the JWT) but not the hashed passwords, which is a possible (albeit not probable) scenario, since they are probably not stored in the same way/place. If you only include the username (and other predictable data) in the JWT, the hacker will now be able to impersonate any user of whom he knows the username, since he can modify the username in the json-web-token and create a valid signature himself.

However, if you include the password-hash (and obviously, check for it's correctness anytime the user performs some access-control protected action), our attacker won't be able to impersonate the user... well, unless he becomes a better hacker and also gets his hands on the password-hashes.

I admit, that doing something like that would cause some overhead (as you are validating the hash in many places) and possibly even performance issues, but in a safety-critical application, it could be worth consideration. I personally don't do it and you probably don't need to do it either, especially if other parts of your app are (seemingly?) secure, but telling others that there is no purpose in doing it is just short-sighted.

Upvotes: 5

jps
jps

Reputation: 22575

Usually, I would say no, don't put the password into the token!

If you do, do it only if it has really a purpose, that means if you are actually going to check it in the backend/middleware, e.g. in a scencario described in the al3xand3r96's answer. But then also the performance has to be considered.

For normal use-cases it is not required, and you should not put the password or anything into the payload only because others do the same.

RFC7519 section 4 lists some mandatory and some optional claims and the password is not among them and I don't know any framework that would require it.

Which claims are useful or needed for your purpose can't be answered here and depends also on the authorization framework/middleware/server. Generally, avoid sensitive information and keep the token as short as possible.

Regarding your example, besides the password, it's ok like this. But only put the extra information into the token if you really need it.

Upvotes: 1

Related Questions