Comment by Phil Nash on "Can we use user password as jwt secret key?"

This is an interesting question. It really depends on what you are using this JWT for and what your expected benefits are. Could you add a bit more detail?

The first thing that comes to mind for me is that JWTs allow you to store data with the token and verify it so that you don't have to look that data up in a database. But using a user's password hash (well, I presume you mean the the hash of their password as you should not be storing the password in plain text) means you need to look up the user record to retrieve that hash and verify the token.

One other side effect that comes to mind is that any user that updates their password will instantly invalidate any JWT signed with the old one. This may sign your user out across all open sessions, which could be a desirable effect, but worth considering.

what you are using this JWT for and what your expected benefits are.

Before, answering that question, I would like to ask what're the other way to create secure and better secretKey instead of writing some hard-coded text like: superSecretKey.

There're few ways I came up with, which can be worth considering but not sure they can really be implemented on production-side.

timestamp
userPassword (according to the post title)
OTP

One other side effect that comes to mind is that any user that updates their password will instantly invalidate any JWT signed with the old one. This may sign your user out across all open sessions

Hmm... Isn't that an expected behaviour, I mean if the user change password from one device (for instance), the token will be invalid and all other places where the user has signed in will be automatically sign out.

Yashu Mittal More things have occurred to me since writing this.

A secret key in an application should be a long, random key. Rails, for example, generates a 64 byte random string by default. Guessing a key like this is practically impossible, however guessing a user password is relatively easy, especially since so many users re-use passwords and so many sites have been compromised and leaked these passwords.

I don't think you can use a timestamp for this. OTPs require a shared secret in order to generate and validate the OTP. The only thing this would add would be time sensitivity and make the boundaries of OTP periods awkward.

The more I think about it, the more likely you are to be able to keep a long, random secret safe yourself than rely on users to keep their passwords secret. So I would prefer to stick with an application secret (or even, if you insist, a generated secret per user).

But you didn't tell me what your expected benefit of using the user password was, aside from increased security, which I refute.

Phil Nash

however guessing a user password is relatively easy, especially since so many users re-use passwords and so many sites have been compromised and leaked these passwords.

That certainly is true.

So I would prefer to stick with an application secret

What do you mean by application secret?

But you didn't tell me what your expected benefit of using the user password was, aside from increased security.

My expectations for using user password or timestamp to generate token was to get a unique secret key for every user.

or even, if you insist, a generated secret per user

You mean to say, generate a unique ID just like a userID and store it inside the database and then use it later for decode the userToken.

Yashu Mittal

What do you mean by application secret?

An application wide secret, your "secretKey" from the initial post.

My expectations for using user password or timestamp to generate token was to get a unique secret key for every user.

But what's the benefit here?

or even, if you insist, a generated secret per user

You mean to say, generate a unique ID just like a userID and store it inside the database and then use it later for decode the userToken.

If you absolutely need to have a unique way of signing JWTs per user, then I would generate a unique random key per user that had nothing to do with their password but was stored against their user record.

However, I would still question why you're doing this with a JWT if you still expect to look up the user in the database every time? Why not use a regular session cookie? Or, why not use an application level secret so that you don't have to hit the database to verify the JWT?

It really depends on what you are using this JWT for and what your expected benefits are.

I want use JWT token for user login/signup.

Search Hashnode