[HN Gopher] You need to plan for token revocation ___________________________________________________________________ You need to plan for token revocation Author : geal Score : 41 points Date : 2023-07-04 20:02 UTC (2 hours ago) (HTM) web link (www.biscuitsec.org) (TXT) w3m dump (www.biscuitsec.org) | FrenchyJiby wrote: | Biscuit has been one of those pieces of tech that makes me re- | think the way we organize our stack, with a couple of key ideas | that make us more user-centric and enable decentralized systems. | | Granted I haven't used it, on toy project or in anger, but it | sounds really neat. | sverhagen wrote: | I'm still skeptical whether expiration times wouldn't be adequate | for many applications, assuming these times are short enough, | like five minutes? | Etheryte wrote: | This approach doesn't really solve anything. If you have | expiration times that short you will need a mechanism for | renewing tokens and a compromised token can be renewed all the | same. All you have is slightly higher server load because your | regular users need to renew their tokens all the time. | sisve wrote: | If your access token is compromised, you would normally need | your refresh token to get a new access token? So it would | increase security, but if you lose your refresh token, you | def have the same problem. | | Or am I missing some context? | ravenstine wrote: | A malicious actor can do quite a lot in 5 minutes. And now | you've got to have your users/services renew their | authentication at least every 5 minutes, meaning there has to | be some central authentication authority to be renewing | through... which completely defeats the whole decentralization | thing and is more complicated than just issuing randomized | tokens and keeping hashes of those in Redis. | | At best, you've got a system where a malicious actor doesn't | think to renew their token fast enough. | [deleted] ___________________________________________________________________ (page generated 2023-07-04 23:00 UTC)