Seems bad that the cookies are still valid after password rotation.
Relatedly, is this another instance of HN serving as de-facto Google tech support/customer service?
Relatedly, is this another instance of HN serving as de-facto Google tech support/customer service?
I worked on a product that rotated the TLS certificate frequently. And it actually showed up a number of times in questions from customers or vendor security questionnaires about whether we rotated the certificates and how that happened.
But what we were never asked was whether old certificates were cancelled... which in that system they were not. So it didn't matter how many times we rotated our secrets, any old or leaked secret in a backup or elsewhere was still completely valid. But we had met the security theater that those rotations happened.
So I expect what you do, is that changing a password would cancel all sessions using that credential. But that's kind of hard to do, so we'll just leave that side buggy and untested, because we did the important part of the theater that said we can change passwords.
I'm confused, did you rotate your certs or your secrets?
Edit: relevant, especially flow2k's answer, which explains why this is _not_ just security theater https://security.stackexchange.com/questions/85963/what-is-t...
This does still leave the problem of the old certs being valid though. This only makes sense as a security practice if the certs are short-lived, which theirs apparently weren't. If the certs live much longer than the rotation window, this really is just security theatre.
I do think thaumasiotes has a point and GP's company probably misinterpreted the rotation requirements and short lifespans were implied in the requirement.
That's very true.
> and GP's company probably misinterpreted the rotation requirements and short lifespans were implied in the requirement.
Or GP didn't know that the company was indeed using short expiration times, and somehow confused it with certificate revocation (called "cancelled" in the post).
Huh? You haven't "rotated" your credentials until the old ones are invalidated. Adding new credentials isn't a rotation.
Which is more trustworthy, the same device/cookie I've seen logged into the account for the last <duration of retention period>, or some new one that just reset the password?
I won't pretend to understand Google's mechanisms or intentions, nor the workings of this exploit, but surely it is more complicated then simply invalidating all prior info upon password rotation?
Im all for terminating sessions if the user wants it, but there are valid reasons to change passwords without knowledge of a breach.
Fwiw, terminating old sessions can be pretty hard in SSO systems and similar, though.
I always wondered how they addressed the state problem of cookie bearer tokens.
Unless your Discord server is actually a spacebar server, in which case they are JWT: https://github.com/spacebarchat/server/blob/master/src/util/...
Thanks for the information, it's good to know that the token contains the user id inside of it.
Even if we argued that this was for tracking purposes, google could keep the cookie for tracking and just deny access to the services until a login flow was completed.