|
|
|
|
|
by brianpan
1079 days ago
|
|
They mention lifecycle at the top: logout now, log out specific devices (I forgot to logout of Netflix after I left the AirBnB), log out unknown/old devices. I don't know Biscuit, but this is just normal security design. Besides normal lifecycle, compromises can happen any number of ways. You won't know them all ahead of time, but having something like revocation designed into your system means you have one more mitigation option when something goes wrong. Examples: all user-side compromises would be covered by "lifecycle" (give them a way to logout if they accidentally pasted a cookie somewhere, logged in to a public computer, etc). On the application side: discovered a security flaw (CVSS bug in a library or you designed a flaw), discovered suspicious activity in your network, suspect some browser or other exploit is allowing tokens to be stolen. After deploying fixes, you might want to revoke some set of token immediately instead of waiting for them to expire out. Having revocation as an option might mean that you can make default expirations longer. Maybe we're ok with letting users be logged in for one week instead of 24 hours if we have the option to revoke. Otherwise if a token is compromised, an attacker has a whole week to play with the token. |
|