Hacker News Reader

Comment by donatj | Hacker News Reader

Many comments here vastly overstate the seriousness of this. For it to be used as an attack, the attacker needs general write access to your database. You probably have much bigger issues on your hands if that is the case.

If they have write access they can already just set the hash to a known value for the same result.

It’s a bug certainly but of very little practical security concern.

View on HN

I think you're understating it. You're imagining a scenario where an attacker spears a specific row in the database. A much more likely failure mode is that a bungled database migration simply leaves the doors wide open: all users can now log in with any password.

Hmm… You make a very interesting point.

I wonder how long it would take for someone to spot and report “I entered my password wrong and it worked anyway”

I was thinking of an attacker with specific goals of accessing things who doesn’t want to be found out.

Your hypothetical attacker would be more of a general chaos agent.

I have certainly encountered far more of the latter.

As @TimWolla commented somewhere else: https://stackoverflow.com/questions/75519073/password-verify...

Note: The hash in the SO question is not vulnerable, because it is too long. The issue exists specifically for hashes that both contain a `$` and are too short. The “too short” is necessary for the trailing NUL byte of the input to be copied into the output and thus to truncate early because of the `strlen()`.

Reply on news.ycombinator.com