It's not just bad, it's a fundamental failure of security. The effect is the same as a password that can't be changed. It might still be possible for users to manually delete active sessions in some Google account management page, but nobody in the world would expect they'd need to do that after changing their password.
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.
But a (public key) certificate is not a public key. A cert is a public key A (to private key a), signed by another key b, of which public key B is known. To rotate a cert means resigning the public key A (which is still derived from the same private key a).
Ah, so basically just renewing before it's due, that makes sense. For some reason it didn't occur to me that rotate could mean that too.
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.
It's technically possible to reuse it, but letsencrypt / certbot do not reuse it by default. You have to go out of your way and do extra work to reuse a CSR when renewing a cert.
> 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.
Huh? You haven't "rotated" your credentials until the old ones are invalidated. Adding new credentials isn't a rotation.
I've hacked into your account and changed your password. Should all your cookies mean nothing for when you try to regain access to your account? Similarly, should knowledge if your old password contribute nothing towards allowing you back into your account?
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?
It's bad because when someone suspects unauthorized access to their account, the first thing anyone recommends is to change your password. If the old cookies keep working, changing your password doesn't help.
The easy and widespread solution to this issue is simply to ask the user if they would like to log out their other devices when they change their password.
I doubt google needs to use this as a feature for tracking.
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.
