3 ms·
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 proba
by donatj 4y ago
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.
- CGamesPlay 4y agoI 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.
- donatj 4y agoHmm… 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.
- pytness 4y agoAs @TimWolla commented somewhere else: https://stackoverflow.com/questions/75519073/password-verify-works-in-php-7-4-but-doesnt-work-in-php-8-2 https://stackoverflow.com/questions/75519073/password-verify...
- TimWolla 4y agoNote: 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()`.