Revoke access token if user password is changed

[mahdirahimi1999]

In this pull request, I have added a new key to the JWT token payload called hash_password, which is generated through the following function:

def get_md5_hash_password(password: str) -> str:
    """
    Returns MD5 hash of the given password
    """
    return hashlib.md5(password.encode()).hexdigest().upper()

Then, during JWT token validation, I check if the current user password matches the value in the hash_password field of the JWT token payload. If these two values are not equal, it means that the user has changed their password.

Additionally, the tests related to JWT token validation have also been updated accordingly with these changes.

[mahdirahimi1999]

@Andrew-Chen-Wang
What should I do???

[Andrew-Chen-Wang]

you should run the tests locally and debug. Follow our docs

[mahdirahimi1999]

you should run the tests locally and debug. Follow our docs

OK

[mahdirahimi1999]

All tests passed.

@Andrew-Chen-Wang

[Andrew-Chen-Wang]

removing tests is not valid.

[mahdirahimi1999]

All tests passed.

I already added that line of the test to the test_get_user method, and these changes are implemented in the test_get_user_with_check_revoke_token.

[mahdirahimi1999]

All tests passed.

I already added that line of the test to the test_get_user method, and these changes are implemented in the test_get_user_with_check_revoke_token.

@Andrew-Chen-Wang

[Andrew-Chen-Wang]

sorry didn't notice; only read latest commit. Thanks again:)

[Andrew-Chen-Wang]

thanks again!

[thecarpetjasp]

Could you please change this from MD5 to SHA256?

MD5 is not considered secure and is considered a very fast hash to compute, so makes it more ideal for brute-force attempts.

I think given the level of importance to this data, which is normally secured in a database, is now outside, there is every more reason to use a much more secure hashing algorithm for this instead, such as SHA256.

Would be a very quick fix and would greatly appreciate.

[Andrew-Chen-Wang]

Though I'd agree, here are a few items to consider:

• User passwords should already be hashed with one of Django's recommended password hashers like argon2 or PBKDF. If the user decides not to use that...
• The JWTs should also already be encrypted. The claims are actually just part of the JWT payload which is encrypted by your RSA/HMAC keys. The only way to unencrypt the token is if your keys were leaked which is a much larger / system problem, and, even then, the pen testers would still need to break through the password hash which is only a problem if you allow users to set bad / haveibeenpwned passwords.
• SHA256 (at this point, why not SHA-3 or BLAKE2; not sure which are in hashlib?) would increase the CPU load on the server. I think it's unnecessary. Feel free to open the issue (and copy my comment) to field others' feedback.

There wouldn't be any breaking changes. A PR would only involve checking first the new hash function then the MD hash. Really, it's a performance thing, and a PR which should be small is always appreciated.

[thecarpetjasp]

Could you expand a little more on JWT being encrypted? As far as I'm aware, the JWT is only encoding with base64, which can easily be decoded.

I hear your point regarding SHA256 adding load on the CPU. I suppose I feel a little restless thinking that the users hashed password could potentially be leaked, given MD5 insecurities, which still isn't so devastating in itself, as the users password is still hashed, or should be as you mentioned.

Personally I would feel a lot better if it was something more recent than MD5 - but I do agree on the CPU load argument, which might make MD5 more suitable for this use. I guess this feature is also optional at the end of the day!

Thanks for considering the request and for your response!

[Andrew-Chen-Wang]

Could you expand a little more on JWT being encrypted? As far as I'm aware, the JWT is only encoding with base64, which can easily be decoded.

Different authentication systems create JWTs differently. With this library, we instruct users to create an HMAC or RSA (or other cryptography-supported algorithms) to encrypt our JWT. You can take a look at backend.py on how we use PyJWT and pass our algorithm to encrypt the JWT payload.

The final JWT is what you're thinking of being base64 encoded, but typically JWT payloads are encrypted.

As a note, the "payload" is a term for the middle segment of the JWT itself!