Hacker News Reader

Comment by IggleSniggle | Hacker News Reader

I’m confused by this. If you have the username, the hashed password, the salt, and the algorithm used, all present in the config file, then what’s the difference between doing what caddy does here and just having the plaintext password in the config file? Isn’t that just the same thing but with extra (known) steps?

Not trying to be intentionally dense, genuine confusion/question.

View on HN

If an attacker compromises your stored plaintext passwords, they can test those username+password pairs against other online services, since lots of users reuse passwords. If you store hashes instead of the actual passwords, the attacker doesn't get the user's credentials.

You have to use hash functions appropriate for passwords (like bcrypt; don't use hashes like sha256 for this). And if you hashed correctly, it's still practical for an attacker to brute-force simple/common passwords. But at least users with hard-to-guess passwords get protected from your breach facilitating credential stuffing attacks.

It's essentially impossible to reverse the hashed password. This is particularly helpful for users who reuse the same password for everything online.

> It's essentially impossible to reverse the hashed password.

It’s essentially a nontrivial unit of work to brute force the hash (or exploit collisions for a compromised hashing algo). That’s not impossible but it’s important not to overstate its safety too.

... for one account. It takes N times as many more resources to do that for N more accounts. The attacks are impractically expensive for most attackers.

It means that if someone sees your config file, they can't log into your sites and impersonate users (unless they have a LOT of money/resources and can reverse secure hashes -- one account at a time). It makes attacks impractically expensive.

Reply on news.ycombinator.com