[Pesthuf]

Not quite as unrealistic as it seems - I have colleagues I can’t convince that SHA-256 is NOT good for passwords.

They just don’t understand that it’s safe for larger binaries, but absolutely not for short ASCII strings like passwords. Also they find it convenient since most modern programming languages and databases directly support those hash functions, but not something like bcrypt or Argon2.

So I do think there are many passwords out there you can crack easily and quickly nowadays.

I’ll try convincing them again…

[ranger_danger]

> SHA-256 is NOT good for passwords

Can you define SHA-256? And not good? Using it with PBKDF2/bcrypt/etc. seems to be widely accepted, but we don't know if you were referring to a single unsalted round of SHA-256 or what. Also by "not good" do you mean "easy to reverse the hash itself" or "easy to bruteforce the resulting password"? I think these questions make a big difference, e.g. you could have the most complex hashing algorithm on Earth, but if they're bruteforcing a three digit password, it doesn't matter.

(something something bitcoin uses sha2)

[Pesthuf]

I thought it was obvious since I mentioned bcrypt and argon 2 later that I meant plain, simple, single round SHA-256. Usually salted, but there's one database where they're not, for some weird MySQL view compatibility hack that allows reusing the accounts and password hashes in a different legacy application that doesn't support salts whatsoever.

The reasons why this is terrible for storing password hashes are widely known, everyone else in the comments is already talking about how you're meant to use something like PBKDF2 or bcrypt instead, so I didn't see the need to put an explanation nobody needs in my comment.