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?
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?
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:
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...