4 ms·

Isn't the fundamental difference that a password needs checking against a stored per-user value such as password hash and therefore needs a database lookup, whi

Isn't the fundamental difference that a password needs checking against a stored per-user value such as password hash and therefore needs a database lookup, while a token can be validated through just the cryptographic signature and therefore avoids hitting the central database?

ptsneves 5y ago
Yes but then you add revocation and you are back at a centrally stored database to check against.
- xnorswap 5y ago
  That's correct. There are scenarios where it still makes sense. It's plausible that it would more efficient for some high traffic services to push (the somewhat rare) revocation notices out to endpoints as still being more efficient. For example imagine a whatsapp clone. People send thousands (probably tens of thousands) more messages than they issue password/auth resets. Having the incoming message endpoint maintain a cache of recently expired tokens would let you set a reasonably long (e.g. 24 hr) token expiry. You could have the app re-auth in the background on start-up and/or when it detects the expiration window is closing, while incoming messages avoid hitting the central DB for auth. Maintaining a cache of expired tokens pushed to endpoints would be vast orders of magnitude smaller than maintaining a cache of all session keys. I don't know for sure though, perhaps central session caches are just more practical and secure anyway for these kind of end-user endpoints. In some ways this is similar to the Certificate Revocation List handles certs. There are certificate revocation notices that are used instead of needing to check centrally the validity of all certificates. That said, the CRL has essentially been deprecated in preference of a lookup model.
  - heavenlyblue 5y ago
    Actually I never thought about this problem this way, but it seems like in an abstract way the difference between the password and the revocation lists is that of the size of the set: What is larger, the set of all passwords, or the set of all revoked users? In most cases the set of all revoked users would be multiple orders of magnitude smaller than the set of of all passwords. Thanks for writing this message, it made it click for me for some reason.
  - ptsneves 5y ago
    Then in this scenario it means you will trust the clients to honor the list of bad tokens is it not? Is this not the whole reason bearer authentication is insecure? Either you need to check in the server against a database or you need to trust your clients that they checked against the database..
soco 5y ago
I didn't think about this, nice feature, very useful in a very distributed system. From the end user (human) perspective on the other hand, it will be stored in a password manager and will need authorization calls and and and - so the only improvement I see is that you can't use "123456" as root account credentials anymore.
- xnorswap 5y ago
  I don't think a user should be able to tell the difference. The initial handshake would still use something like passwords or API keys to authenticate the user. The difference is post-login, where authentication can return for example a 'session key' or can return a JWT or other token that can then be used to say, "I've logged in, I'm xnorswap and I'm allowed in the system until 202204051200Z. I'm allowed access to view users and create reports".
  - soco 5y ago
    Post login scenario which can happen also after a password authentication :) I mean it already happens, in places... (but your point about distributed heavy duty systems still stands, to keep in mind)

ptsneves 5y ago

Yes but then you add revocation and you are back at a centrally stored database to check against.

xnorswap 5y ago
That's correct. There are scenarios where it still makes sense. It's plausible that it would more efficient for some high traffic services to push (the somewhat rare) revocation notices out to endpoints as still being more efficient. For example imagine a whatsapp clone. People send thousands (probably tens of thousands) more messages than they issue password/auth resets. Having the incoming message endpoint maintain a cache of recently expired tokens would let you set a reasonably long (e.g. 24 hr) token expiry. You could have the app re-auth in the background on start-up and/or when it detects the expiration window is closing, while incoming messages avoid hitting the central DB for auth. Maintaining a cache of expired tokens pushed to endpoints would be vast orders of magnitude smaller than maintaining a cache of all session keys. I don't know for sure though, perhaps central session caches are just more practical and secure anyway for these kind of end-user endpoints. In some ways this is similar to the Certificate Revocation List handles certs. There are certificate revocation notices that are used instead of needing to check centrally the validity of all certificates. That said, the CRL has essentially been deprecated in preference of a lookup model.
- heavenlyblue 5y ago
  Actually I never thought about this problem this way, but it seems like in an abstract way the difference between the password and the revocation lists is that of the size of the set: What is larger, the set of all passwords, or the set of all revoked users? In most cases the set of all revoked users would be multiple orders of magnitude smaller than the set of of all passwords. Thanks for writing this message, it made it click for me for some reason.
- ptsneves 5y ago
  Then in this scenario it means you will trust the clients to honor the list of bad tokens is it not? Is this not the whole reason bearer authentication is insecure? Either you need to check in the server against a database or you need to trust your clients that they checked against the database..

soco 5y ago

I didn't think about this, nice feature, very useful in a very distributed system. From the end user (human) perspective on the other hand, it will be stored in a password manager and will need authorization calls and and and - so the only improvement I see is that you can't use "123456" as root account credentials anymore.

xnorswap 5y ago
I don't think a user should be able to tell the difference. The initial handshake would still use something like passwords or API keys to authenticate the user. The difference is post-login, where authentication can return for example a 'session key' or can return a JWT or other token that can then be used to say, "I've logged in, I'm xnorswap and I'm allowed in the system until 202204051200Z. I'm allowed access to view users and create reports".
- soco 5y ago
  Post login scenario which can happen also after a password authentication :) I mean it already happens, in places... (but your point about distributed heavy duty systems still stands, to keep in mind)