back to article G Suite'n'sour: Google resets passwords after storing some unhashed creds for months, years

Google admitted Tuesday its paid-for G Suite of cloudy apps aimed at businesses stored some user passwords in plaintext albeit in an encrypted form. Administrators of accounts affected by the security blunder were warned via email that, in certain circumstances, passwords had not been hashed. Hashing is a standard industry …

  1. ratfox

    Constant vigilance!

    It's only paranoia when no one is out to get you.

    1. CrazyOldCatMan Silver badge

      Re: Constant vigilance!

      It's only paranoia when no one is out to get you.

      IT is much like (motor)cycling - your lifespan is considerably shortened if you *don't* assume that everyone is out to get you..

      There are old bikers and bold bikers but there are no old, bold bikers..

      (Apart from Barry Sheene)

  2. Anonymous Coward
    Anonymous Coward

    ‘Encryption at rest’

    What are the odds that Google’s encryption at rest is just full disk encryption- i.e. worthless pretty much as soon as the disks are spinning and something wants to access the data?

    1. elvisimprsntr

      Re: ‘Encryption at rest’

      As you indicate, at rest likely means disk encryption. The follow up question is, what about in transit?

      Google != security | privacy

      1. GnuTzu

        Re: ‘Encryption at rest’

        Google != privacy && ...

        Yet, they've been pushing HTTPS like television evangelists. I guess Google's internal security culture isn't company wide.

    2. Claptrap314 Silver badge

      Re: ‘Encryption at rest’

      Pretty unlikely, I would say. When I was working there, they were serious about unauthorized data accesses.

      Yeah, the SRE teams had a ton of authorization. They need it. It's logged, though.

      But the process of code modification requires at least one approval. So you need to compromise two engineers with the right access. And that compromise is there in the source code for anyone to see.

  3. Roopee Bronze badge

    Not Necessarily...

    " skilled intruder, could still access the logged passwords as plaintext – they have to be decrypted at some stage"

    Surely if the passwords are encrypted separately then stored, then the typed password could be ecrypted and compared to the stored cipher text in the same way that typed passwords are hashed then compared to the stored hash, i e no need to decrypt the stored password.

    1. gnarlymarley

      Re: Not Necessarily...

      could be ecrypted and compared to the stored cipher text in the same way that typed passwords are hashed then compared to the stored hash, i e no need to decrypt the stored password.

      Which means an intruder does not need the original password! They just need something that can produce the correct hash.

  4. Anonymous Coward
    Anonymous Coward

    SQRL would have been handy...

    Secure Quick Reliable Login (SQRL) would be handy to be already available and with hardware versions for those that want that extra level of security, to stop once and for good these password nightmare where everyone seems to make a mess every now and then.

    I know about FIDO2, but they use the NIST P-256 elliptic curve that doesn't give that much confidence in its security unfortunately, and comes with its own problems too (like some attacker may be able to lock out the legit users by using a bigger counter number in the "fake key", if they somehow are able to get the private key... in a proper made dedicated hardware should be very very difficult, but if one is using some software solution... that can turn out to be a very real problem).

    1. Anonymous Coward
      Anonymous Coward

      Re: SQRL would have been handy...

      Your concerns around FIDO2 apply equally to SQRL - compromise of the keys that are stored on the FIDO2/SQRL servers and the user devices results in the compromise of all SQRL/FIDO2 access for that user. Much like using a single e-mail address/password combination across all sites.

      Also, this isn't about the encryption algorithms - this is effectively the same issue as client certificates for authentication. While certificates provide additional security, it presents scaleability issues with key issuing/management/revocation and the solutions result in the security issue moving from weak passwords to software bugs/key storage flaws. i.e. it's not an unworkable solution, but similar systems have not found wide spread favor for client authentication in the past due to operational challenges.

      The following has a good discussion of the points albeit from a number of years ago.:

  5. Dan 55 Silver badge

    This is printing the password to log files on an encrypted disk

    Google's PR know how to dress it up better than Facebook's.

  6. DropBear


    If you ever want to be able to _retrieve_ a password, which is what they said this was meant to do as a requested feature, hashing it would simply defeat the purpose. Arguably retrievable passwords are not the greatest idea ever for this exact reason (resetting would be preferable), but IF one sets out to provide that feature for whatever reason, this is the best that can be done: encrypting the passwords reversibly instead of hashing them. The exact details of what was encrypted and how do matter of course, but it's disingenuous to mention this anywhere in the same sentence as simply storing passwords in plaintext because you simply don't know better or just don't care.

  7. Anonymous Coward
    Anonymous Coward

    Now you know why...

    Google and Facebook have been busy hiring former government intelligence agents and attorneys.

    When they say that all these unhashed passwords could only be accessed by employees...well, you get my point.

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