It is possible to add non-Google accounts to Gmail and retrieve their mail messages via POP or IMAP. As part of the setup process, one has to provide the login username and password for these accounts.

Since POP/IMAIL requires plaintext credentials, they must be stored by Google in a reversible manner.

Is there documentation on how these credentials are protected?

  • This depends on your e-mail client?
    – SEJPM
    Mar 9 '16 at 16:55
  • @SEJPM: no it does not. This is all contained within a SaaS (Gmail)
    – WoJ
    Mar 9 '16 at 16:59
  • WoJ - your question was a bit hard to follow. It's been edited, but I think the edit changed the meaning of the question. Can you clarify and re-edit as appropriate? Mar 9 '16 at 19:32
  • @NeilSmithline: OK, I simplified the wording and it will hopefully be easier to follow.
    – WoJ
    Mar 9 '16 at 19:43
  • 1
    Looks great now. Suspect that the answer to your question is that it's not documented beyond the usual "Stored using state-of-the-art security practices." sort of statements. Mar 9 '16 at 19:45

There's two sides here that some people may have confused. So let me keep them straight:

First of all, your password for your Gmail account (your actual Google password) is hashed responsibly. I haven't seen the details published publicly anywhere, so instead I'll just say that the people responsible for this care about security and have a very thorough understanding of what that entails.

But if you set up the "Mail Fetcher" to poll other mail services using POP3 and import their mail into your account, then yeah, obviously that utility needs to be able to get to the plain-text version of your password in order to log in as you and fetch mail on your behalf. This is a limitation inherent in any system that uses passwords, and it's unavoidable. Don't use that feature if this makes you uncomfortable.

I don't see anywhere any public documentation on how these credentials are protected, so unfortunately I can't comment on it. But again, I'll re-iterate my whole "smart engineers" sentiment.

Side note: Google has retrofitted OAuth2 into POP3 and IMAP specifically to solve this problem, allowing you to give a client access to your mail without giving them your login password. It also allows you to use your 2-factor setup with POP3 and IMAP. But so far it hasn't gained much popularity beyond Gmail, so it's not particularly useful for the mail fetcher tool.

Disclaimer: I work for Google.
Second Disclaimer: I do not speak for Google. These thoughts and opinions are my own (which I think makes them all the more valuable).

  • 1
    I have no doubts about the actual Google password. The "mail fetcher" one is the one I was hoping to find some documentation about.
    – WoJ
    Jun 8 '16 at 6:10
  • @WoJ I doubt you'll find specifics. Generally that level of security detail is only available on a need-to-know basis and under NDA.
    – tylerl
    Jun 8 '16 at 6:59
  • 1
    The reason I was hoping for a doc is that online companies are usually eager to explain how properly they store passwords (hash, salt, pepper, etc.) - in light of the various passwords leaks. There is no standard for reversible storage so I would expect someone who goes against best practices (because there is no choice, I understand that) to explain the measures taken to protect my credentials, beyond "trust us".
    – WoJ
    Jun 8 '16 at 7:08
  • 1
    @WoJ reversible encryption is well-understood and not the interesting part; what matters is key management. And that's the sort of detail that they wouldn't be keen on explaining to potential attackers. Honestly, though, the mail fetcher is a bit of a hack; a stop-gap measure. If your third-party mail service is important, then use forwarding (not POP3) to get the mail out of it.
    – tylerl
    Jun 8 '16 at 7:11
  • yes of course, this is what I meant
    – WoJ
    Jun 8 '16 at 7:12

I didn't find any such documentation. Hence I had to make internal communication about this vulnerability to my users.

Moreover, at time of (pop|imap)/tcp connection, these passwords are in clear within the Gmail servers (which are acting as clients in this process). They are also travelling the Internet in clear.

The inherent weakness of such a service should be better documented by Google, and appropriate warnings should be provided to users which are not security aware.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.