Auth Tokens should not be stored in plain text

[profhase]

An auth token for the API is the same as a password for a user.

IMHO it should not be saved plain text in the database, but rather a hash (similar to passwords).

I know that there are other apps that provide that, I think that the minimal implementation that DRF delivers
should be secure (or not being offered) as it is easily used in production causing security flaws

[RajalakshmiMadhavan]

@profhase Can I take up this bug of saving hashed auth token instead of plain text.

[RajalakshmiMadhavan]

Approach would be:

1. Generate a raw token and hash it using PBKDF2 + SHA-256 algorithm which provides string in format - <algorithm>$<iterations>$<salt>$<hash> and with a random salt.
2. When authenticating credentials, verify if plain key matches a hashed key or not.

[browniebroke]

An auth token for the API is the same as a password for a user.

I think it's more like a session ID. When users log in traditionally, they send username + password. We can lookup the username to find their account in the DB and then check the plain password against the hashed one from that user. If it matches, Django creates a session ID and store this in the DB (in plain text). For all subsequent requests, the browser sends the session ID, it doesn't send the username + password again. API tokens are similar, they first require the user to login with username + password, and a key is generated, which used to look up an open session.

Hashing a password is computationally expensive, doing this on every request is not very scalable

[profhase]

@browniebroke

The difference from the security view is that sessions are temporary by design but the API tokens are long running i.e. the API token does not have a mechanism to rotate -> analogously to the user password it should be protected

If an attacker gets e.g. an old backup the sessions are worthless. The API Keys most likely not.

About computationally expensive:

Considering the number of API requests I would not consider it expensive (compared to database lookups).
In other words: most APIs would not notice the performance impact but the security impact is always there. With high traffic APIs I would argue that the solution with DRF tokens is not sufficient anyway.

Thus it would be in my opinion a more sensible default to compromise potential performance over the security.
Also drf-knox does it by default

[browniebroke]

Also drf-knox does it by default

I've looked into their implementation and they use a single round of SHA-512, which is not what I had in mind when I was raising computationally expensive process. I was thinking of the user password hashing that is implemented in Django itself, which makes it harder to guess password by performing many iterations (doc).

Doing a single round of SHA512 is indeed not very expensive, which perhaps defies the point of hashing? It's apparently pretty easy to brute force a token hashed this way, precisely because it's not computationally expensive. Better than no hashing? Probably, adds more friction to an attack, but...

If an attacker gets e.g. an old backup the sessions are worthless. The API Keys most likely not.

If an attacker gets access to a backup, you might have bigger issues to worry about that API keys, they likely have all your data with potentially lots of PIIs in it. Maybe not if it's "old", but why keep an otherwise worthless backup around?

To be honest, at this point in DRF lifetime it might just too late for such a change, and from what you describe, it's a solved problem with drf-knox.

[peterthomassen]

A few points on hashes and iterations:

• Hash functions considered practical for cryptographic purposes do not have known ways of getting reversed. If a way to do that is discovered, the function is deprecated (as happened with MD5 and is happening with SHA1).
• If the hash input is random and long enough, it's infeasible to reverse a hash by brute forcing it (that is, going over the potential inputs, hashing them, and seeing which one matches) because the input space is so large. (That's the "security level" argument with "number of bits of entropy".)
• If the hash input is not random and the attacker knows the structure of the input space, it's feasible to just try out all possible inputs and then find the one that produces a given hash. For example, human-chosen passwords are highly structured (often, a few letters plus a few digits and an exclamation mark at the end, total of 10 characters or something).
• In that latter case, a matching hash input could be found quickly (e.g., in a day). To slow that down, hash iterations were introduced, so that for each check one would have to do (for example) 1 million hash computations. This increases the cost of the attacker from 1 day to 1 million days, which is an improvement. It also slows down log-ins by the same factor, but computing 1M hashes is on the order of a second, so it's fine for the occasional log-in.
• [Note that if a hash function is broken, then iterations don't help, because you can use the function's weakness to reverse all the iterations one after another. So, iterations conceptually don't make hashing stronger at all; they are a mediocre mitigation for a weak input.]

But: auth tokens are not human-chosen, and long enough to contain sufficient entropy. Searching the input space by brute force to find a match for a given hash is not feasible even with just one iteration. Therefore, no additional iterations are needed. On the other hand, the computational burden of hashing once is negligible in practice. There seem to be only good reasons for hashing tokens, and no good reasons for not doing so.

A word on salt: The purpose of salt is to "enrich" the hash input with something unique, so that two identical hash inputs will be transformed into two different hash inputs, yielding two different outputs. The point of that is that you can't tell which users have chosen the same password. (If you didn't use salt, those hashes would be the same, and with salt they look different.) If the input is random, then all the inputs are different, and this problem doesn't exist (no salt required for hashing tokens).

You can see an implementation of this, based on DRF's Token model, here: https://github.com/desec-io/desec-stack/blob/085bb991e63694ff473b2a21608abbd96a294497/api/desecapi/models/tokens.py#L152-L160

This implementation also does a lot of other things, but only these 9 lines are relevant for the question at hand. The cleartext token is stored in self.plain. Its entropy (164 bits) slightly exceeds that of the standard DRF tokens (160 bits). This is achieved with only 28 characters (instead of 40 in default DRF tokens), by using a more efficient alphabet (base 58) than hex (base 16). The alphabet choice is optimized for copy/paste and avoiding line-breaks.

[browniebroke]

Cross referencing some similar work in Django core for adding support for hashing session tokens (google group discussion):

• Fixed #21076 -- Store hashes of session keys in backends django/django#8736
• Fixed #21076 -- Session keys hashing django/django#12814
• Fixed #21076 -- Allowed session ID hashes to be stored in the session backend. django/django#17018

[realsuayip]

There are multiple issues with current auth token design in DRF and im afraid at this point it would make more sense to deprecate this backend in favor of third party extensions.