that's still "storing the passwords", though. no one said it should be stored in plain text.

No a one-way hash is not "the password". If you have the hash you can't use it to login or reverse it to a password without brute force comparison which is why you always store a hash with salt using slow hashing algo, and not "the password", this has been best practice for years so a DB breach does not mean the password are compromised.

Right, but if someone mentions passwords in a non-technical context like a random Twitter threat, it's possible they mean the hashes.

I agree, but it's still the password in that it's the secret set of characters needed to be compared against to login. It's just not the same text a user would enter when prompted for the password.

Keeps in mind these hackers are the ones saying they have passwords and this is Microsoft. Most likely hashes.

I disagree you cannot use the hash to login, therefore it is not a password. Is a digital signature the item it is signing?

The whole point of hashing passwords is so if the DB containing them is breached the passwords are not compromised.

Be warned that this makes your authentication system less secure because it caps the maximum entropy of the password to the entropy of the hash function.

You need crazy long passwords for that to become the limiting factor. With random printable characters on the keyboard there are a bit less than 7 bits per character (unless a crazy amount of different accents are used). So you need passwords longer than 18 characters to surpass the entropy of even MD5.

What would you suggest instead?

A simple change if you don't want to change it too much eg. moving away from passwords would be to use a sponge function instead of a hash and and squeeze out the same number of bits as the plaintext.

A cryptographic sponge function has a fixed capacity just like a the fixed state size of a cryptographic hash function…

Good point. How about splitting the password into chunks, then use a key streching algorthim on each chunk with difficulty tuned to be easier based off the total amount of chunks, and concatenating them.

That sounds like the kind of homebrew crypto that one should never do in production. I'll stick to my boring but proven salted hashes, thanks.