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

schroeder
  • 123,438
  • 55
  • 284
  • 319
F1Linux
  • 207
  • 2
  • 6
  • 6
    Your premise is false: your ***UNhashed*** password was transmitted to Google. – Joseph Sible-Reinstate Monica May 23 '19 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 '19 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 '19 at 21:33

2 Answers2

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.
Chris
  • 81
  • 2
-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...

F1Linux
  • 207
  • 2
  • 6
  • 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 '19 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 '19 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-Reinstate Monica May 23 '19 at 17:42
  • 1
    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 '19 at 18:33
  • @F1Linux, the concern with client side hashing is that you need to give your clients the means to generate the hash. There is the risk here of giveing hackers exactly what they need to reverse engineer a crack. – Nosajimiki May 23 '19 at 19:06
  • @KevinMirsky if a hacker gains access to the database, then they have everyone's login credentials. Hashing passwords can prevent passwords from being discovered despite a database breach. – Nosajimiki May 23 '19 at 19:08
  • @Nosajimiki Right, but my question was specifically about *client-side* hashing, and not hashing in general. I want to understand F1's threat-model better of a bad Googler and how client-side hashing stops it. – Kevin Mirsky May 23 '19 at 19:19
  • @KevinMirsky The advantage of client side hashing is that your password never hits Google's servers. So, if google servers get infected, said virus cannot intercept the password between the process of decrypting the TLS data and Hashing it into the database. Both models have risks, and frankly hashing your data at both ends is probably best. – Nosajimiki May 23 '19 at 19:26
  • 3
    How do you salt if the hashing is client-side? – schroeder May 23 '19 at 20:23
  • @KevinMirsky The current system at not only Google, but apparently FB too, seems to be storing BOTH clear-text passwords AND their hashes! There is NO legitimate purpose for retaining passwords after a user has been authenticated. Were there, why bother with hashing at all? This pile of authentication data could be either used directly or sold on the dark web by a hooky employee and EVERY org has a some of these. Client-side hashing + a challenge would be a step up over what's happening now, which I can see sooner rather than later a large service being compromised. – F1Linux May 23 '19 at 22:25
  • `Were Google to have only received a hash of the password they could not have otherwise obtained a clear-text version of it.` Yes, but in that case the clear-text password is not anymore what an attacker is looking for, because now **the hash** is your password (the transmitted secret against which the server authenticates you). – sox with Monica Oct 07 '20 at 17:04