Google Says Some G Suite User Passwords Were Stored In Plaintext Since 2005

Google says a small number of its enterprise customers mistakenly had their passwords stored on its systems in plaintext. The exact number was not disclosed. "We recently notified a subset of our enterprise G Suite customers that some passwords were stored in our encrypted internal systems unhashed," said Google vice president of engineering Suzanne Frey.

Slashdot reader pegdhcp appears to be one of the users impacted by this security lapse: I am sharing a message that I received from G Suite, redacted. They are having some serious problem... If you missed the message or somehow tend to ignore sometimes extremely frequent and unnecessary G Suite messages like I do, this one can be important depending on your settings. [You can read the full email message (with redactions) below:]

Dear G Suite Administrator,

We are writing to inform you that due to legacy functionality that enabled customer Domain Admins to view passwords, some of your users' passwords were stored in our encrypted systems in an unhashed format. This primarily impacted system generated or admin generated passwords intended for one-time use.

We have reviewed the login information for the user account(s) and have found no evidence that the unhashed passwords were misused.

The following is the list of users impacted in your domain(s):

[e-mail]

Google Planned Action: for your security, starting tomorrow Wednesday May 22, 2019 PT we will force a password change unless it has already been changed prior to that time.

Our password update methodology is as follows:

Users With Single Sign On: We will reset their password by changing it to a randomly generated secure value. Please note that this will have no effect on their ability to log in using their Single Sign On credentials.
Other Users and Super Admins: We will terminate their sessions and prompt users to change their password at their next login.
In addition, starting Wednesday, May 29, 2019 PT we will reset the password for users that have not yet selected a new password or have not had a password reset. These users will need to follow your organization's password recovery process. Super Admins will not be impacted. For information on password recovery options please refer to the following Help Center Article.

For further questions please contact Google Support and reference issue number XXXXXXXX.

Sincerely,

The G Suite Team

Sorry, no ...

[Anonymous Coward]

Google says a small number of its enterprise customers mistakenly had their passwords stored on its systems in plaintext. The exact number was not disclosed. "We recently notified a subset of our enterprise G Suite customers that some passwords were stored in our encrypted internal systems unhashed"

I'm sorry, but that's not "mistakenly", that's "incompetently".

This isn't an oops, this is a multi-billion dollar company failing at basic security and not finding it for 15 years.

Sorry, Google, you don't get to claim anything but your own fucking incompetence and stupidity.

Re: Sorry, no ...

[Anonymous Coward]

Why mod parent down? I talked to Google about their collaboration platform back in 07 or 08 and their response was something along the lines of it is secure because the data is randomly distributed across a bunch of computers in a bunch of data centers so there was nothing to worry about.

Which was a pathetic response to a fortune 25 security team. We did nothing with them and now my veto is validated.

Re:

[jrumney]

Yeah. Definitely not a mistake, it was due to incompetent design decisions:

due to legacy functionality that enabled customer Domain Admins to view passwords

Re:

[jrumney]

Judging by the statement due to legacy functionality that enabled customer Domain Admins to view passwords, I'm guessing it is all passwords for accounts registered before a certain date when that functionality was dropped.

Re:

[pegdhcp]

That unfortunately is not the case in one of my domains. I have received warning for an account while some older and one or two newer accounts was not mentioned. I naturally reset all passwords in all my domains, regardless of warning status. However I doubt and afraid their problem pattern, whatever it actually is, not something very simple.

Re:

[parkinglot777]

The company said since January it was improperly storing “a subset” of unhashed G Suite passwords on its internal systems for up to two weeks. Those systems, Google said, were only accessible to a limited number of authorized Google staff, the company said.

The word "subset" is NOT THE SAME as "small number"! Do you know what subset mean? It mean there exists at least one member up to all members of the group but one. In other words, a set of 1 (only one member) or n-1 (one less member) is still a subset of n (the whole group). If they are using the word "subset", then I would see that the substituted word of "small number" is inappropriate.

Viewing passwords?

[Anonymous Coward]

We are writing to inform you that due to legacy functionality that enabled customer Domain Admins to view passwords, some of your users' passwords were stored in our encrypted systems in an unhashed format.

Why in the ever-loving-fuck would it be appropriate for administrators to be able to view passwords?

Re:

[pegdhcp]

There is only one instant that I know in G Suite, when domain manager can see a user's password. That is when a forcible password reset occurs, it is on the fly and as far as I can tell not available retroactively. Thus, while it is also not proper, such an application must not require cleartext storage.

I frankly do not remember when I have created account that caused me to receive notification as it is not a domain wide warning but account specific, maybe some years ago they had a retroactive password con

Re:

[pavon]

Based on the next sentence

This primarily impacted system generated or admin generated passwords intended for one-time use.

This reminds me of enterprise apps that allow you to get an API key/token from the web UI. Good enterprise systems will show you this key once, when you generate it, and then it is never possible to see again (have to revoke and reissue if you loose it). Bad ones will let you view keys you have previously generated. So maybe it was something like that.

Misleading headline

[neurojab]

The note specifically says "encrypted internal systems" so the passwords were not stored "in the clear" - they just were not hashed. Yes passwords should always be hashed, but encrypted is not the same as in the clear.

The actual lapse here is the product requirement to allow domain admins to recover and view the generated passwords. That is not a good idea, because it specifically means that the password can't be hashed.

Re:

[Anonymous Coward]

The note specifically says "encrypted internal systems" so the passwords were not stored "in the clear" - they just were not hashed. Yes passwords should always be hashed, but encrypted is not the same as in the clear.

Encrypted in a way that Google can readily decrypt is pretty much the same as in the clear.

Unless you are saying you 100% trust Google with your passwords ... if you are, you're a fucking idiot.

I'm just not prepared to give Google a pass on this one, it's way too big of a fuck up to be waved a

Re:

[jrumney]

It depends exactly what "encrypted systems" means. Probably it means that raw access to the disk without the key is not going to get you the password, but access into the running system will. So it depends on what level the attacker breaks into the system as to how easily they can access these plain text passwords.

Re:

[pegdhcp]

If anybody/any automated system has the decryption key it is cleartext equivalent. If there is no decryption key/method it can be treated as a hash. As they explicitly stated passwords are not hashed but encrypted, that means it was possible to a process to access cleartext original passwords, so the security risk. Broadcasting such an advisory makes it obvious there was a security risk...

From the data owner's perspective, encrypted is not so much different than cleartext if data owner does not have keys b

Re:

[Bert64]

That's assuming that the data is encrypted using the super admin's password as a key, otherwise "only the super admin has access" is simply a piece of logic running on the backend which decides who should be displayed the password - if you have access to the backend you can circumvent this logic without knowing the password for the super admin user.

Re:

[neurojab]

Wow. I never said there was no security risk. Only that "hashed" and "encrypted" and "in the clear" are different things. Slashdot used to be a bit more cordial..

Question for those in the know

[Entrope]

I got that email. The list of affected accounts only listed one: [e-mail] (where example.com stands in for the actual donation name). I never set up an account with a dot for the name. How am I supposed to interpret that? That Google can't get their form emails right?

Re:

[Keramos]

Go into your admin console and check for the existence of an account with a dot as the user id. Cut and paste the dot from the csv if you need to for a search, just in case it's a unicode glyph rather than the standard period symbol.

If you find something, take whatever action is required in your circumstance to determine if it's a malicious or accidental account creation.

If you can't find anything, contact google support with the reference issue number provided in the email (last paragraph before the G Suit

Not just for old accounts

[dborod]

I received one of these emails for a user account that was created in a brand new G Suite account last month. Hmmm.

Re:

[micheas]

It seems like it was passwords that were generated by the account admin and not changed.

I'm basing this on the one domain I deal with that was hit by this, while all of the domains that required users to change their password after the administrator set it were not hit by it.

Re:

[dborod]

Here's the beginning of the email I received yesterday:

Dear G Suite Administrator,

We are writing to inform you that between January 13, 2019 and May 9, 2019, an internal system that logged account signup information for diagnostic purposes, inadvertently stored one of your user account passwords in our encrypted systems in an unhashed format. This impacted the user account password provided during the initial account signup process. The log information was retained for 14 days following the signup process,