4 ms·

Are there really many web services where an attacker having long-lived access gives them much more power than short lived access? If someone gets short lived a

Are there really many web services where an attacker having long-lived access gives them much more power than short lived access? If someone gets short lived access to a control panel for something, there are normally ways to twiddle settings to, for example, create more user accounts, or slacken permissions. If someone gets short lived access to a datastore, they can download all the data. etc.

thayne 2y ago
One way you could potentially combat that is to make it so that a single short lived token isn't enough to accomplish more dangerous tasks like that. Many sites already have some protections against that by for example requiring you to enter your password and/or 2fa code to disable 2fa, change privacy settings, update an email address, etc.
fc417fc802 2y ago
Not more power in the sense of greater access but nonetheless gaining persistence is a huge advantage for an attacker. In the case of bearer tokens there are many cases where attackers have managed to steal them without achieving full device compromise. Since it's literally sending the key in plaintext (horribly insecure) all it takes is tricking the client software into sending the header to the wrong place a single time.
arnarbi 2y ago
This is a very good point, and one the DBSC team thinks about a lot. In the short term it's about economics: Infostealer malware today scales really well because it can a) exfiltrate cookies quickly and clean it self up, mostly evading any client based detection, and b) sit on large stashes of long-lived cookies and carefully "cash them in" in ways that evade server side detections. A short-lived cookie forces different behavior for b, which we think will make it more detectable server side, and binding in general will force malware to act more locally, which will make it (far) more detectable locally. In the long term, DBSC also is designed so that the session management and key registration is somewhat decoupled from that short-term cookie business. If and when we can sign more often (perhaps every request), I believe the DBSC API will still be useful for websites to manage the session key and lifetime.

thayne 2y ago

One way you could potentially combat that is to make it so that a single short lived token isn't enough to accomplish more dangerous tasks like that. Many sites already have some protections against that by for example requiring you to enter your password and/or 2fa code to disable 2fa, change privacy settings, update an email address, etc.

fc417fc802 2y ago

Not more power in the sense of greater access but nonetheless gaining persistence is a huge advantage for an attacker. In the case of bearer tokens there are many cases where attackers have managed to steal them without achieving full device compromise. Since it's literally sending the key in plaintext (horribly insecure) all it takes is tricking the client software into sending the header to the wrong place a single time.

arnarbi 2y ago

This is a very good point, and one the DBSC team thinks about a lot. In the short term it's about economics: Infostealer malware today scales really well because it can a) exfiltrate cookies quickly and clean it self up, mostly evading any client based detection, and b) sit on large stashes of long-lived cookies and carefully "cash them in" in ways that evade server side detections. A short-lived cookie forces different behavior for b, which we think will make it more detectable server side, and binding in general will force malware to act more locally, which will make it (far) more detectable locally. In the long term, DBSC also is designed so that the session management and key registration is somewhat decoupled from that short-term cookie business. If and when we can sign more often (perhaps every request), I believe the DBSC API will still be useful for websites to manage the session key and lifetime.