Given how many times I've heard of people being locked out of their Google accounts, and are only able to regain access because they're still logged in on some rarely used device, I imagine that Google would lose a bunch of users if they suddenly started to expire those cookies.
Back in the 2000’s, we were dreaming of what would come next from Google. Then, in the 2010’s, we started to wonder what would be discontinued. Now, in 2020’s, we dread being locked out of Google accounts. I closed mine during the lockdown. My school cancelled my huge Cryptomator backup on Google. Now, work provides me with one but I can no longer rely on Google for anything crucial.
I have been slowly migrating/backing up everything related to my Google account. I’m just not confident that the ghost in the machine won’t decide randomly one day I’m not worthy of continued access.
In another light, it’s a reminder that Google doesn’t really think of these accounts as ours, but theirs.
What spreadsheet tool do you use at work? I put my company on a competitor for Gmail, but then we still had to open Google accounts for Google Ads and Youtube and GDrive. Now I wonder whether I should officially subscribe, just for consistency.
A few years ago I started getting increasingly worried about my Gmail account being a single point of failure for basically my entire life. Along with Google’s evolution into an evil empire this prompted me to completely excise them from my life. It took a couple of years to transition all my less-used accounts to my new email but the peace of mind is worth it.
Yes it's trivial, but I'm asking for a commercial provider one can trust that uses software that doesn't suck horribly and one that doesn't just cut you off immediately if your payment to them fails, or locks your account until you phone them if you try the password too many times etc.
If I wanted to host my own I wouldn't ask about providers...
Email these days is about much more than just email. Calendar integration and sync between devices that lets you access email on said devices as well as resiliency one would want for an essential service mean just "hosting your own" is definitely not trivial.
I moved away a while ago. The only thing I still use would be youtube playlists. But even those are trash since they just say we've removed some because of whatever. Thanks I guess I would like to know which song you threw away!
I am not the poster you replied to, but I’ve dealt with this in various forms.
For a number of close family members Google has variously refused to accept valid recovery emails, valid recovery codes, and valid backup phone numbers in order to regain account access.
Despite how ridiculous it is from a consistency and security perspective, your MFA- or backup contact- enrolled phone number with SMS is still essentially Google’s gold standard for determining rightful access to an account.
Their auth and password reset processes are constantly changing and they have several steps that are automatically adaptive.
The only foolproof ways I’m aware of to always retain access to your Google account is to enroll in Advanced Protection, and/or to use a paid Google Workspace account.
Advanced protection is a good pointer. Seems like losing the hardware token device can be a disaster?
On the other hand giving a service money is dangerous. They would be making money from you which means stricter checks. I'm still semi banned on Github because they had my card with Russian billing address (for sponsoring) when Putler attacked Ukraine. Good I didn't pay for anything Google.
I have a paid Workspace account and I can’t view my payment information on the non-Workspace accounts site because they can’t “verify it’s me”.
This is with 2FA and a passkey, and multiple logged in devices. There’s a lot of idiocy going on there, I wouldn’t trust them with a single thing for any reason whatsoever.
I use a pw manager with a key and key file. We just had a house fire on xmas eve, and my DR plan of having a laptop in the garage with the important bits failed as I had just brought the laptop in to look over everything because it was so cold outside.
I was screwed as all of my PCs/laptops, Servers, tablets, etc...burned up or were flooded by fire dept. I found my phone 8 hours later on the basement floor where it had been submerged in 8" of water from the fire dept. Miraculously it was dead and just wanted to be charged. (Samsung s22, fwiw). I'm typing on that now and still have access to everything! Phew.... take your personal DR seriously.
Could they just...stop locking us out of our accounts? For some reason, even knowing the password, being on a device+network combination I've used a dozen times before and entering a login code generated on an already-logged-in device still isn't enough to prove my right to use the account these days...
The issue is account hijacking, and it's a matter of tradeoffs: the more relaxed your login process is the more unhappy ex-users you'll have losing their accounts to hackers (mostly reused passwords getting leaked), while the stricter you make it the more unhappy ex-users you'll have losing their accounts to lockouts (mostly stale recovery methods).
It's my account that's at risk of hijacking, so I should be able to decide. If I opted for no 2FA despite Google begging me to turn it on every login, that's my decision.
And the answer should never be just "sorry, we can't confirm your identity right now". If I pass every challenge Google throws at me, I should be let into the account, period. If they have more, sure, whatever, let's play the game, but if I did everything right and still can't get in, that's a broken authentication system.
> It's my account that's at risk of hijacking, so I should be able to decide. If I opted for no 2FA despite Google begging me to turn it on every login, that's my decision.
If that is your argument then it is their service. They can decide how to offer it. Services like this are designed for majority - and a majority are happy. If you don't prefer then you can find alternate services. Market is wide open.
This is stupid. You need to do some sort of delegation. If some one logins now in USA and 10 min later a login is detected from Singapore. And again if US login is detected - this will throw any security to bonkers.
May be you/your client needs a proper workflow. May be you need to run some security company/email service at the level of Google to see.
Sure, but said delegation abilities frequently don't exist, are locked behind a very substantial paywall, or are simply very difficult to set up. Account sharing is a fallback which bypasses all of those issues and so is commonly used, especially in shadow-IT and smaller companies which don't have the resources to invest in a solution with better security properties.
Oh interesting. I think I haven't noticed this because I'm trying to disconnect from Google lately. These days I login on an incognito tab and log out when I'm done. But just with a password.
I think if they have ever seen your account password in any password dump/leak (ie. if you reused the password elsewhere), then they effectively prevent password login. You have to have another already-active session.
It would make more sense to inform the user this, then enforce these checks until the user changes it.
Anecdotally, my Google account's password has never been in any dump (password manager, very long random alphanumeric, changes every 6 months) and I too deal with these annoying prompts.
In my case, the workflow requires a recovery token which was sent to an email account I have access to, authenticating with the token results in a security error.
Despite having access to the password, the recovery email account and an active session, I could not activate a new session.
It didn’t make sense, not that it matters when google refused to have a help desk or meaningful way to report bugs.
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.
> If the certs live much longer than the rotation window, this really is just security theatre.
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).
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.
The original poster didn't mention LE or anything else that uses ACME. It's pretty easy to reuse a key in a bespoke PKI setup; the X.509 builder APIs that I've used make it trivial. Which doesn't make it a good idea, of course.
> 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.
Multilogin continues to be the gift that keeps on giving for Google.
Google engineers weren't keen to implement the feature in the first place, and it's been kind of an unlimited well of headaches, confusion, and user issues ever since.
This is doubly bad for Google Cloud, as you can't use it without Google accounts. I'm not sure if it makes sense to remove Sign in with Google yet, though I'm not sure how much I can trust Google for delegating user auth now...
Interpreting that the basic problem is limited to a propriatary OAuth2 extension feature of Chrome designed by google to support google services.
It sounds related to an OAuth2 footgun around applying the expiry to refresh_tokens in addition to the access_token, which has an explicit expiry. Whereas the refresh_token expiry is only implied as something less than the access_token - if any.
In Google's sort of environments, access tokens have to be interpreted by the world (e.g. a zillion geographically distributed Google nodes), so it makes sense for them to be self-contained bundles of authorization policy decisions and quick-need attributes, with a time limit. This is the sort of thing that RFC 9068 was made for.
Exchanging an access token for a new one using a refresh token is a seldomly done operation (in comparison), with whatever amount of business logic that the company needs, evaluated in a more centralized environment belonging to a single business unit (e.g. the auth team).
So you'd expect access tokens to have some shorter-lived (6-60 minute) fixed lifetime to an expiry instant and to be non-revocable on their own, while refresh tokens are opaque to any software other than the central OAuth service. They might be good for a day or year, or each refresh may be a risk calculation based on signals received from elsewhere (such as a password change event).
In the case of a password rotation or signal from other parties that the password has been compromised, you would expect that the current access token would continue to work for some short period of time, after which the refresh would result in a failure (typically sending the user back to a login page in their browser).
Revoking a bearer token for multiple services is an open loop problem, where you can't know if all services have revoked it unless each service builds in some kind of guarantee signal, which would remove a lot of the integration efficiency of using bearer tokens in the first place.
That leaves threads to pull like the ones implied in the exploit. I've seen refresh tokens set to 6mo to a year in enterprise environments where they were reducing the number of 2FA logins required.
We're all speculating on the actual exploit still, I can see how something like this happened. Federating logins federates risk and aggregates it into something users can't reason about and is difficult to unwind. It's just the cost of progress.
> Revoking a bearer token for multiple services is an open loop problem, where you can't know if all services...
What is a service here? A bearer token is meant solely for the AS. Revocation of a bearer token only means something in the context of the AS.
Now if one wants to build some AS feature to go tell every protected resource "there's an access token good for another 15 minutes - I revoked its bearer token so don't honor that access token" one can build such a thing, but it is going to be some particular custom aspect of the implementation shared between the AS and resource servers.
Since OAuth only really profiled two patterns for interoperability between the two (stateless sharing via JWT, stateful endpoint via introspection service), the only real interoperable approach is to make a introspection call each time you evaluate the access token.
At a massive distributed scale like with someone like Google, such introspection decisions would have to be pushed closer to the nodes as a distributed system itself, which means it becomes eventually consistent. You have to decide whether a complex stateful system is worth it considering natural access token expiry on its own also essentially makes revocation eventually consistent.
A possible problem would be the refresh lasting longer than the access and remaining unexpired, instead of expiring at the same time - but tbh it's unclear to me whether it is the problem as described.
At the same time Google requires employees to log in (including touching U2F key) every single day, invalidating all sessions.
So this is schizophrenia - corporation is protected, but casual Gmail users are left to be hacked with no option to set the session expiration anywhere in the account settings.
Presumably cookies are "stolen" from Chrome by malware running under Windows.
I guess Mac and Android users are potential victims too. As much as I despise post-Wozniak Apple, at least an iPhone is reasonably secure (except from governments).
X for Doubt. There's almost no details that are useful in this article, and in this case, the authors indicating Google isn't doing anything about it is likely because this isn't actually true.
Of course maybe I'm wrong but short of some more compelling technical details (reply a link if there's a better source), I'm inclined to doubt the characterization of this article.
I generally believe it. Google's security team has been lax on cookie security. I reported an issue earlier this year about non-expiring session cookies; they said it was previously reported in 2019. The bug remains [1]. Sadly other Google projects use this code...
Historically they've been quick to patch things I've reported, so it feels like a decline.
Am I the only one who wants non-expiring sessions.
My browser cookie store ought to be a good place to store secrets. On Linux it is protected by the user keyring. I believe on windows it is protected by the system secret store which is eventually secured by the user logon password and the TPM.
So why not just let my cookies survive until I explicitly invalidate them by clearing my cookie store, hitting logout, or by changing my account password?
From a security perspective, someone who breaks into my cookie store has access to pretty much any website I use, whether the validity is 1 week or 1 century. Any prepared attacker can take full control of the account in a matter of minutes, so the validity doesn't make much of a difference.
I worry about a couple things. Many apps don't end other sessions when you log out or change passwords. My example above doesn't handle that.
Poorly written backends only check if a user is active during login. So a lingering session remains usable. Imagine an employee is fired, they are angry, their accounts is disabled, but they still have access. In some rare cases sessions for deleted users still work.
You'll see this most often with apps that rely on client side cookie expiration as sessions appear to expire, but they don't.
Personally, I want short sessions on things like my bank account. For stuff like HN, long is great.
The problem here is that the cookies don't expire even after changing the account password. The account owner must manually end each session from the accounts.google.com page.
