-4

Google has recently admitted they were storing "G Suite" users' passwords un-hashed on their systems.

But if a hashed password was transmitted to Google when I logged in to my account then how did my un-hashed password end up on their system?

closed as off-topic by schroeder May 23 at 21:14

  • This question does not appear to be about Information security within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 5
    Your premise is false: your UNhashed password was transmitted to Google. – Joseph Sible May 23 at 17:40
  • 2
    I'm voting to close this question as off-topic because it appears to have been asked as a strawman. The question is not honestly asked and is not set up as a canonical question. – schroeder May 23 at 21:14
  • @schroeder Question not meant to be a strawman: only to address the misconception that passwords are hashed (laypeople would believe "scrambled") prior to transmission. Google, FB and Instagram have all recently been caught storing their users' passwords unencrypted. Apologies if this was misconstrued as a "wind-up" though. Certainly not my intentions – F1Linux May 23 at 21:33
3

Your unhashed password ended up on their system because that's typically how authentication works, with credential information being sent to a server which then verifies it. It should never be an assumption or expectation you make as a user that your password is not available to the server. That is why it is typically considered best practice to use different passwords for every site you visit, aided by the use of a password manager.

Best practice for the server side of an authentication process is to ensure that passwords on the server side have undergone a one way transformation such that the original password cannot be recovered. Google's GSuite team was not following those practices. You can see the OWASP guidelines for password management here: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Password_Storage_Cheat_Sheet.md

The idea that the issue here is that they were not performing client side hashing is a straw man of a question and an argument. Arguments can certainly be made that there are benefits to client side hashing, but they're irrelevant when you're talking about an implementation that wasn't even hashing at all, because server side hashing is more important as a first order of business to begin with, and there are a number of logistical reasons that client side hashing can be complicated (it immediately means you cannot perform a basic HTTP Authentication without involving javascript, can no longer support authentication from clients that do not support your chosen hash method, cannot easily change the client side hash function...). Most importantly, if someone is being evangelized to about client side hashing who is unfamiliar enough with security they would ever ask or stumble upon the initial question here (as a non-rhetorical argument), they're being sent down a rabbit hole that could result in any number of mistakes due to an attempt to homebrew a crypto implementation.

If you're reading this question/answer because you're wondering what Google did wrong, or what you can do better, two points you should always, always keep in mind:

  • Passwords should always be stored securely, rather than in plaintext. This does not mean client side hashing, this means server side hashing. That doesn't mean you can't client side hash as well, but if you aren't sure what you are doing, you don't want to try to be clever.
  • When security is involved, do not reinvent the wheel. Use existing libraries, functions, and methods - never roll your own crypto.
-3

It's still true that hashes are one-way:

A hash can be computed from a password, but the inverse is not true: a password cannot be derived from its' hash.

So logically, that leaves us with only one possibility as to how Google came to capture their users passwords in clear-text: they were NOT being hashed BEFORE transmission.

Were Google to have only received a hash of the password they could not have otherwise obtained a clear-text version of it.

I'd consider such a practice of capturing clear-text passwords insecure, unnecessary and unethical. Although the password traverses the internet encrypted via TLS, the password could be potentially abused by a corrupt employee of Google with fierce admin privileges. Once authentication has been completed there is absolutely no reason to capture users passwords. Only bad things can happen...

  • 1
    Agreed. I don't understand why everyone is so against client-side hashing... it solves a number of potential issues like this one and it makes it transparent to people how their passwords are treated. – Luc May 23 at 16:58
  • Absolutely. Looks like FB does the same crap. That is the ONLY explanation as to how their users passwords keep getting hoovered up ;-) – F1Linux May 23 at 16:59
  • 2
    @Luc if you hash on the client side instead of on the server side, it's basically as bad as not hashing at all. In particular, an attacker could then impersonate you just by stealing your hash, without needing to try to break it. – Joseph Sible May 23 at 17:42
  • Can you elaborate on how a Google employee might abuse the password? I can see if your concern is because of password reuse, but if it's them using it to access your Google account, I don't see how client-side hashing changes things. If the server expects a hash for a login, you can still MITM it and replay it back. – Kevin Mirsky May 23 at 18:33
  • 2
    How do you salt if the hashing is client-side? – schroeder May 23 at 20:23

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