Skip to content

Gmail just logged me in as someone else

UPDATE: After doing extensive checking with extended family, this has proven to be legitimate (though very unexpected). Please ignore the post and move along, Gmail is still secure for now! My sincere apologies for raising an alarm.

This morning I opened my laptop and went to to check my email, but was a little confused at first. The first email was from Amazon Local Deals, which I was pretty sure I had unsubscribed from a while ago, and furthermore it was from an area I used to live in, but have since moved from. Then I saw that two people that I did not know had circled me on Google+, not completely unusual but still unexpected. Then the kicker… my name was gone from the top right, and instead I was inside of Sarah Jenkins’ account (name changed).

At that point I shot back to the inbox, and sure enough, I was in a completely different person’s account. All the emails were completely foreign, the chat list was full of people I did not know, and the +You name in the top right was definitely +Sarah, not +Joshua. I quickly checked Chrome’s Web Inspector and looked at the cookies. Indeed, everything appeared as if I were her, almost as if it was a Firesheep session, but it most certainly was not.

I certainly got out of her account as quickly as I could, but did take a quick screenshot and saved the network data (and corresponding cookie information) strictly for evidence in hopefully helping the Gmail team should they need debugging evidence. I would never want to violate this other person’s privacy, just as I would not want mine violated.

And that is what scared me: this happened to me, being in someone else’s account. But what if a different person in the meantime has been in mine? Email is the gateway to everything online, and I would never want anyone in my account that shouldn’t be there. An incredibly bizarre and potentially dangerous situation.



  • I had not logged in, I had just opened Gmail in a new tab.
  • I use multi-login, and am normally logged into two other accounts at the same time. Neither of these accounts were available, just the other individuals.
  • I also use 2-step authentication (thankfully!), not sure if this would affect my account.
  • The cookie looked completely like her identification, nothing to do with mine.

One of the oddest things is that the stranger was 90% random, but based on their apparent location and a few email subjects, I could have in theory at least formerly lived near this person.


My best hypothesis right now is that there was a networking-based error that occurred somewhere along the way, where traffic destined for me/her was switched somewhere along the lines. Otherwise the culprit would have to be in Gmail’s systems. Either scenario is scary; this should never happen. Being in someone else’s account is like having the key to their kingdom. I could have read all of her emails, looked at her Youtube subscriptions or posted something as her, reset other possible accounts that send email password reminders or reset links–everything short of actually changing her Gmail password (which thankfully would have required me to actually know her existing password). In general, Google authentication is quite secure, but what happened today made me very nervous about my own account’s safety, and about the infrastructure in general.

If you are on the Gmail team and can follow up on this, please contact me. I will try and examine the .HAR files I exported when I get a chance, and if I have any updates I’ll report back here.

Published inTechnology


  1. This seems to me as a session collision. You looked at the cookie, so you know something about how these things work, but just to be sure I’m going to explain it in basic terms. Keep in mind that this is just *my* theory, I’m not not affiliated with Google and have never experienced this myself.

    When you log in, on pretty much any website, it generates a session. This session must be unpredictable so that others can’t guess what your session is, so there is some random generator involved. An example session could be 7583 (in practice it will be a much larger number, usually with letters or even special characters involved).

    When someone else logs in, they will also have a session generated for them. If the random generator happens to pick the same number, it might overwrite your session. If you then open the tab (and your browser remembers the session to keep you logged in), you will appear to be logged in as someone else.

    This should never happen. The server should check whether the generated number is already in use. However, the odds of this are incredibly low. With 64-bit sessions, the odds of having two people have the same session is 1 in approximately 18446744073709551616. Even with a billion users logging in, substract 9 decimal positions from that and it’s still one in eighteen billion. But it might just happen.

    With the millions of users that Gmail has, it might take a lot of resources to check if the session exists somewhere in the world. Or perhaps your session had expired and has been removed, and then someone else logged in and got the session that you were previously assigned. Your browser, not knowing that its session cookie had expired, simply used it.

    The odds of this are just *so* incredibly low, it’s very surprising that it happened – if this is what happened. It would perfectly fit your explanation though. Looking at Gmail’s cookie, I can’t really figure out how many bits of randomness they use. The length is 194 bytes when base64-decoding it, so that would be 1.58*(10^467) possibilities. But I think they simply store some more data there, not just your session.

    Hmm, writing this down and looking at the numbers, it’s actually more likely that something else messed up, especially considering the complexity of Google’s network. Anyhow, a very interesting bug.

    • RandomPerson RandomPerson

      Interesting theory. Except, assuming you are correct ( dont know if you are ), *imo* the odds are not as low as you’ve calculated. I believe that you can apply the idea behind a ‘birthday’ attack here. If both Josh and Sarah login at the SAME time, the odds that they have the same random value are 1 in sqrt(N) where N is the ‘random’ session number they use. Just my theory.

      • You are right! This was also commented by someone on Hacker News (or perhaps you). Still, with a little bit larger sessions you could avoid this problem. I’m sure Google had better analysts and cryptographers than me working on this to make it secure, so they should have chosen something sufficiently large.

    • Aaron Friel Aaron Friel

      I would like to expand on the other comment that actually the odds are quite a bit better than one in 2^64. The other poster is correct, a birthday attack is completely valid here. For those not aware, suppose everyone in a room has equal probability of being born on any particular day – like an ideal hash function with a range of 1 to 365 (we will ignore those weird leap day kids for now.)

      Now, the odds of you and someone else having the same birthday are plainly 1 in 365. However, you have to take into account that in a room with say, 23 other people, there are actually 253 pairs of individuals. If we give names A-W to these 23 individuals, there is “AB, AC, AD, … BC, BD, … VW” pairs of individuals. Each one has a 1/365 chance of having the same birthday, and so the cumulative probability that two individuals have the same birthday is greater than 50%. You can find all of this by searching for “birthday problem” or “birthday paradox”.

      Now, with 64-bit hashes the range is quite a bit larger, roughly 2^55 larger. However, for say, a 50% chance of two people having the same session, there would only have to be roughly 5,100,000,000 concurrent sessions. A bit large, but what’s required for a 50% chance. As in, on a day to day basis there’s fairly good odds that two sessions would end up logged in as the same person. But surely Google has say, 610,000,000 concurrent sessions on their servers, right? (They sell roughly that many Android devices a month right? – I jest.) That’s how many sessions would have to exist concurrently for a 1% chance of two sessions overlapping. Those are pretty good odds for something to go wrong.

      So let this be a warning to any web developers that read this: don’t assign sessions using a hash function. If at all possible, use unique user identifiers (with HMAC, of course! secure those cookies!) or some monotonically increasing or otherwise guaranteed-unique function.

  2. jifa jifa

    Btw, 2-factor auth doesn’t really help if you don’t protect your trusted devices, either physically or via ‘extra’ auth (user password on your laptop).

Comments are closed.