[madsbuch]

> If the attacker has the ability to set a hash, they can just set the hash to a known password.

That requires the attacker top also have access to the salt

I smell an underlying sentiment of "if the attacker has access to the DB, then it is broken anyways". This is not entirely true. Think a gateway service that lets the user to something on another service with access without access to the database immediately giving access to the system.

This is definitely a security bug.

[donatj]

Nope. Blowfish doesn’t use a manually defined salt. It generates one itself randomly every time and includes it in the hash result string which you generally store the entire string in the database. No secret salt involved.

[amalcon]

> That requires the attacker top also have access to the salt

Which you must presume they do. If any part of your security relies on the salt being secret, that's a much bigger vulnerability than this.

That said, I do think there's a potential vulnerability here, because it allows you to break in if you can only corrupt another user's password hash (rather than controlling it entirely). Think a rowhammer attack or something.

[bawolff]

> I smell an underlying sentiment of "if the attacker has access to the DB, then it is broken anyways"

To be more clear, my position is - if the service allows you to set the password for an arbitrary user, then it is broken anyways.

[madsbuch]

Again, not necessarily. This depends on the hashing scheme you use. Eg. if setting a correct password hash relies on you having access to private keys.

[bawolff]

No it does not.

Either you allow bcrypt hashes, or this bug is inapplicable. If you are encrypting your hashes or something, then this bug cannot be leveraged.

[madsbuch]

Yes, for this very specific bug. This thread taked about having access to the database as a general attack vector.