0

I want to implement PATs for an API I am creating and want to know if there are any security issues and might be a better way.

  1. User requests token, names it, and gives it permissions
  2. Token is generated on the server and returned for one-time display
  3. SHA of token is stored in the database tables with matching security
  4. API calls use SHA of the passed token to lookup in database to authorize

I'm trying to think of a way to salt the hash, but is that really necessary? As a long random string of characters it isn't really feasible to brute-force it, and there should be no duplicates or the same hashed value in any other system that would lead to an issue if the other system were hacked.

Just storing the hash makes it a quick database lookup. I thought about having some other identifier or piece of information be transferred as well, but I think that just complicates it and might lead to exposure of more information.

Jason Goemaat
  • 592
  • 3
  • 7
  • Use JWT and verify its signature in memory so that you don't have to make database lookup. – defalt May 05 '23 at 15:18
  • @defalt These are presumably long-lived tokens, since they are said to be named. Those are completely unsuitable for JWTs (can't securely revoke or modify them) and it's dangerous to suggest using them in such a scenario as they'd have to have lifetimes far longer than are safe for JWTs. – CBHacking Jan 31 '24 at 08:14

1 Answers1

1

This pattern is fine, yes. There's no need to use salted hashes, as salting is only necessary for either defeating rainbow tables (not relevant, as the tokens are far too large and randomly distributed to build a rainbow table) or avoiding easy detection of instances where two inputs have the same value (usually, two people have identical passwords); that's also irrelevant as the tokens are machine-generated and should have enough entropy that collisions are nonexistent (and you can verify this if desired). With that said, if you wanted to use salt, it'd be easy; just generate and store the salts server side (in plain text), and combine them with the PAT before hashing it. Note that this would require passing an identifier such as a user name/ID (to find the correct salt) as well as the token; in your design as described you only need the token.

Similarly, there is no need to for a slow hash, such as are used for passwords. Slow hashes are used to make brute-force attacks hard, but are only required with low-entropy inputs (such as passwords, which often have less than 40 bits of entropy - roughly a trillion values - and could be brute-forced in minutes-to-hours by modern hardware if using a fast hash). There's no reason for your tokens to be so weak; they should be at least 128 bits of cryptographically secure random data, such that even the best hardware in the world would take a period best measured in lifetimes-of-the-universe to brute-force it.

CBHacking
  • 48,401
  • 3
  • 90
  • 130