back to article Google bakes new cookie strategy that will leave crooks with a bad taste

Google reckons that cookie theft is a problem for users, and is seeking to address it with a mechanism to tie authentication data to a specific device, rendering any stolen cookies useless. Cookies are still widely used by websites, which get the browser to save information on a session locally to a small file (the cookie) …

  1. Anonymous Coward
    Anonymous Coward

    Seriously, author?

    The Microsoft Edge browser is Chrome...

    Also, how is Chrome going to get write access to the TPM? Am I going to have to repeatedly lock and unlock the TPM to allow Chrome (which is configured to clear the cache on exit) to create a new keypair every time its restarted?

    Additionally, for those users who don't clear their cache on exit, won't having a single for-Chome public/private key pair make user tracking so much easier?

    Sounds to me like this is the LAST thing any sane person would want.

    1. xyz Silver badge

      Re: Seriously, author?

      Would that be an advertising id by another name?

      1. Mark 65

        Re: Seriously, author?

        My first thought was that this sounds like a better way to track you across sites with a security sales pitch

    2. Charlie Clark Silver badge

      Re: Seriously, author?

      Edge is based on Chromium; Chrome itself contains all kinds of Google-specific stuff.

      I'm not 100% confident but the implementation looks like a reasonable mitigation against session-stealing. I don't think that a single pair of keys is the idea: amongst other things, this would make tracking a lot easier. But also, if the validation is happening on the client then public keys are only exposed when the cookie is first set up. However, it might still be possible to cause trouble if the public key can be intercepted and, therefore, reused at the right moment.

      And, if the implementation degrades reasonably, it can be provided when supported, dropping down to other mechanisms when its not.

    3. abend0c4 Silver badge

      Re: Seriously, author?

      There's a little more detail here.

      The proposal is essentially that at the point at which a user "logs in" (or equivalent) to a website (it doesn't apply to unauthenticated sessions) the browser is prompted to generate a private key which is used to secure session cookies. That private key is then destroyed when the user "logs out" (or equivalent) or when the browser quits. Since the private key isn't reused, then there shouldn't be a privacy issue - however, since the key is tied to a "log in", then you're not talking about an anonymous user in any case so that's all really moot.

      There's nothing inherently that requires a TPM - it would clearly have some potential benefit simply using a software key vault of some kind, but with greater risk of malware exfiltrating the keys and transparently continuing the session on another device. Though TPMs are not quite as inflexible as might be supposed by the time the OS has built an environment around them - assuming you have one to hand.

      I think the big problem with the Google proposal is that it's essentially a hack: it requires the browser to periodically refresh its credentials (to prove it still has the private key) by making an http request to a specific URL associated with the application. Unlike, for example, Token Binding which is a proposed extension to TLS that is transaparent in that it doesn't depend on upper-layer application behaviour. The somewhat questionable justification for Google's approach is that in typical web application infrastructures, the security context (TLS connection) has been stripped by some border device and is unavailable to the web application code. And justifying your security hack on the basis that you junked all the security data you had at the earliest possible moment is very typical of modern practice, but I can't help feeling a better solution might be available.

      1. v13

        Re: Seriously, author?

        This is a good explanation but tying e2e credentials to TLS isn't something that would work on the modern Internet. It'd require the Application layer and HTTP to have information from and interact with the TLS session. That would make all cloud-based load balancers that terminate TLS (most of the Internet nowadays) incompatible. It also gets tricky to handle mid-session where the session cookie is actually being created or destroyed.

        Overall, binding cookies to a device is certainly the way to go. Even without a TPM, having a device-specific storage (like a service in Linux running as a different user) would be a big leap. And for the cases where you can't trust the local system, you'll need a TPM-like solution.

        1. MrXonTR
          Boffin

          Re: Seriously, author?

          Termination proxies already communicate that sort of information with "X-Forwarded-For", "X-Forwarded-Host", and "X-Forwarded-Proto" HTTP headers. I can't imagine it difficult to have one more header that carries some session data. Or perhaps the proxy can be in charge of confirming sessions on behalf of the application, which only needs to know who a user is after authentication.

        2. abend0c4 Silver badge

          Re: Seriously, author?

          I think that readers will have noticed that I used the word "modern" pejoratively and that you used it in a more positive - or at least neutral - way.

          The explanation is perhaps that, being (very) old, I've heard similar arguments made a lot - we are where we are and we need to get the job done. But next year we'll be somewhere else and the point of standards is to lead us towards a stable and rational objective, not to codify current practice in a way that leads to stagnation or, worse, continuous and directionless change according to the latest whim. The architecture should specify how it ideally would work in the long run, before considering the transitional arrangements - which are undeniably necessary - to deal with present reality. However, here, at least in my estimation, we seem to have started with present reality and worked backwards. It will do for now and another proposal will come along later. It must make for an exhausting life.

        3. Anonymous Coward
          Anonymous Coward

          Re: Seriously, author?

          They all keep flogging the TPM Horse ….

          How about tying Chrome and cookies to Google Authenticator and the 2FA can secure and no new TPM PC needed.

          1. Missing Semicolon Silver badge

            Re: Seriously, author?

            If you keep writing application keys in the TPM, the flash will die pretty soon.

      2. Charlie Clark Silver badge

        Re: Seriously, author?

        Great additional explanation. I think the privacy concerns are related to other sites attempting to get the device's and hence user's public key for tracking purposes, so single use is reasonable.

        I agree that better solutions might be possible but think we should welcome the idea and potential proof of concept: it's certainly an improvement on the current situation and the rising risk.

  2. Doctor Syntax Silver badge

    I thought the idea of cookies was to maintain state on the client so that the server could be stateless. if the server is now having to maintain state (half of a key pair) why use anything else on the client? Or is that the whole point and I've missed it somewhere?

    1. Tom 38

      Session ID cookies (mostly) operate in the exact opposite way, they provide a key to a server side session store, and are the most common way of providing a user login. You can use client side sessions, where the session data is encoded and stored in a cookie, but this has limits on state size, and the state is visible to the end user - they can't modify the state, as it will be signed/protected by hashing the encoded session data combined with a server side secret.

    2. Charlie Clark Silver badge

      http was traditionally stateless to save resources: connections were never intended to be persistent. However, as soon as logging in was required, persistence was required and we got sessions. These don't have to be secured by cookies, but the alternatives: session ids in the URL were even easier to steal, especially before everything was encrypted.

      http/2 isn't really stateless any more as connections are often persistent (servers are much, much beefier and the protocol has been adapted to suit multiple requests from the same device) but the rest of the stack is still required and as more and more "important stuff" goes over http, the desire to obtain credentials for nefarious tasks rises.

  3. alkasetzer

    Hmmm, what about if I store my home folder on a NAS and want to use the same browser profile on different machines (same thing as opening two browser instances)?

    1. Throatwarbler Mangrove Silver badge
      Holmes

      Presumably, if you start a session on computer A using that profile and then want to switch to computer B, the server will send a message saying that your session is invalid and that you may be a victim of a MitM attack.

    2. Charlie Clark Silver badge

      You might want the same profile but do you really want the same sessions? This would be handing over the session data to anyone else on the network.

  4. DS999 Silver badge

    Wait, what?

    Didn't we read a bunch of articles over the last few years about how Google was getting rid of cookies entirely?

    I mean obviously Google wasn't going to stop tracking you, but I thought they were trying to fool people with the claims about eliminating cookies. Did enough people see through that they have abandoned the "we are eliminating cookies" and are now saying "we are bringing you Cookies 2.0" - now cryptographically linked to your device so even better at personally identifying you! But don't worry, that's for your own good *wink wink*

    1. Sora2566 Silver badge

      Re: Wait, what?

      They were (and are) getting rid of third-party cookies, not first-party cookies; which are essential to any website with a log-in page.

  5. Just an old bloke

    Any change Google makes is primarily for the benefit of Google. Improvements in user experience are happy coincidence.

    1. Charlie Clark Silver badge

      By all means go after Google for being a massive slurper of personal data but don't let this blind you to what it does get right. Google has a pretty good record on security and was proactive on it years before it became fashionable and it took a lot of flak for its project zero, which has, however, now become standard. This may all be good business including polishing its reputation but I also think they're aware of the potential financial risk when systems become compromised: these could be customers losing data but it could also apply to its own employees.

      1. Claptrap314 Silver badge

        When I was a Google (2015-6), I would definitely NOT agree that they were good at security. Their culture was strongly built around the free flow of information, and getting GCP up to outside corporate standards was a huge and painful undertaking.

        It is true that Google has a decent record regarding application security--when it suits them. But they have clearly prioritized the inbound data flow just like Adobe, and this is why Chrome will continue to be a rich source of CVEs.

  6. xanadu42

    A more simple solution...

    Unless I am totally misunderstanding this issue there seems to me to be a very simple way to bypass this sort of "hack" - one that I have used for a number of years on some of the websites I operate...

    I tie some visitor cookies (specifically related to those that are sellers [the site members] or buyers) to the IP address of the visitor when the visit is initiated - if the IP address changes during the interaction the visitor is advised that an error occurred and to re-try and the cookie is reset...

    So far no complaints

    So am I really dumb on relying on such an idea, or have I missed the point?

    1. Charlie Clark Silver badge

      Re: A more simple solution...

      Your approach doesn't defend against MITM attacks which gives user and thief the same ip-address; this approach uses cryptographic signing to enforce the device-specific nature of the session.

      1. Nick Ryan Silver badge

        Re: A more simple solution...

        SSL sessions, for example HTTPS, prevent MiTM attacks - particularly if linked to other schemes to try and ensure that the MiTM isn't replacing the SSL certificate and acting as a straight relay.

  7. Anonymous Coward
    Anonymous Coward

    more bandaids for legacy tech

    or, how to fail forever. Goog is an evil greed driven company. yeah, everyone knows it. so Lets not let them dictate what tech people use.

    It's long past time to get away from evil companies spying. Letting them dictate what tech people use only "ensures" that data will be taken from people.

    If this crap keeps up, internet will become like 8-track tapes, to annoying to use.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like