Wholeheartedly agree, however The Changelog Podcast helped shift my perspective on this. It's really about not having the responsibility of storing and maintaining passwords.

▲

AndroTux 9 days ago | parent | next [-]

You should never store passwords anyways. You store hashes. I don’t see the issue. If you don’t trust yourself to keep a hash, maybe don’t store user information at all.

▲

benrutter 9 days ago | parent [-]

That's still not perfect though!

Most leaked passwords online come initially from leaked hashes, which bad actors use tools like hashcat to crack.

If your user has a password like "password123" and the hash gets out, then the password is effectively out too, since people can easily lookup the hash of previous cracked passwords like "password123".

▲

csnover 9 days ago | parent | next [-]

No. This is why salts[0] are used.

[0] https://en.wikipedia.org/wiki/Salt_(cryptography)

	▲	integralid 9 days ago \| parent \| next [-]
		This is how it should be done. But it still doesn't protect users fully, because attacker can try to brute-force passwords their interested in. It requires much more effort though.
	▲	incorrecthorse 9 days ago \| parent \| prev [-]
		And compute-intensive hash functions. Computers this day are powerful enough to hashcat each individual pwd+salt if a fast hashing function is used.

▲

Macha 9 days ago | parent | prev [-]

Salting already fixed this decades ago, and most modern password libraries will automatically generate and verify against a hash like <method>$salt$saltedhash if you use them instead of rolling your own.

▲

daemin 9 days ago | parent | prev | next [-]

So if they don't want to store your passwords because they do not want the responsibility of keeping it safe, should you trust your credit card and other personal information with them?

▲

internetter 9 days ago | parent | prev | next [-]

I feel like this is going to bite me in the ass 15 years from now but like bcrypt is really really hard to screw up

▲

FabHK 9 days ago | parent [-]

Latacora, 2018: In order of preference, use scrypt, argon2, bcrypt, and then if nothing else is available PBKDF2.

So even 7 years ago bcrypt was only the 3rd recommended option.

	▲	internetter 9 days ago \| parent \| next [-]
		You'll find that opinion is still divided among these three options. And bcrypt is harder to mess up. It has less parameters (it doesn't fall apart as easy) and salting is built in, whereas its not for scrypt and argon2. If, knowing nothing else about the competency of the programmer, I had to choose between an application using scrypt, argon2 and bcrypt, I'd pick bcrypt any day.
	▲	LVB 9 days ago \| parent \| prev [-]
		They follow with: "But, seriously: you can throw a dart at a wall to pick one of these... In practice, it mostly matters that you use a real secure password hash, and not as much which one you use.

▲

augunrik 9 days ago | parent | prev | next [-]

Kinda weird when they secure shop sites where you enter your payment information into. IKEA does this, for example.

▲

adastra22 9 days ago | parent | prev [-]

So? They don’t want to store my password, so instead they immensely weaken the security of my account?

This is not good for the user.