That conclusion doesn't necessarily follow, fwiw. If you find a password list, then you hash all the passwords and see if any match the hashes you store, now you know if the password found online belonged to someone on your system but at no point did you keep your own system password in plaintext.

Mind you with salt and pepper (roughly, ways to modify the hash and overcome rainbow tables) checking anything other than the very highest frequency passwords found would seem onerous.

They're probably just checking against a stolen passwords list when the user logs in.

That doesn't mean it's stored in plain text. They could be storing a nice hash, and then when the crawler finds your email and password on some site some where, it could try to hash it as if you were logging in and see if it matches.

Salting (which they absolutely should be doing precisely to make mass dictionary attacks computationally expensive) would make that infeasible.

More likely they're just checking against the stolen passwords database whenever the user logs in, as passwords are typically submitted in plain text.

Salting doesn't matter in this case. They're not finding a list of free-floating passwords and then seeing if anyone has that password; they're finding a list of accounts and associated passwords. So they only have to check that particular combination, just as they would for a regular login.

D’oh you’re right.

Do you know how computationally expensive it is to hash passwords?

It's computationally expensive to hash every single possible password, but given a proposed login/password combo, it's not expensive to check just the one. If Google, in crawling, finds a dump of several million accounts and their purported passwords, it's not a heavy lift to check each password.