Hi again, Before I go into a more lengthy response, a quick reply to Robert, because his question keeps popping up outside of this RFC too:
On Thu, Oct 1, 2026 at 1:43 AM Robert Chapin <[email protected]> wrote: > A developer might ask why the application is doing this, but the RFC > asks why is PHP doing this? Is the function named password_verify going > to verify the password or not? password_verify() remains unchanged on purpose, and that's a good thing. There is some natural compulsion to make it consistent with password_hash(), but it's a trap that would break old passwords for no benefit. I would oppose any such change. On Thu, Oct 1, 2026 at 12:26 AM Tim Düsterhus <[email protected]> wrote: > Even with a non-ASCII 2-byte per character diceware password you are at > roughly 50 bits of entropy in the 72 bytes, which makes the math go from > “an attacker that started at the big bang still wouldn't have cracked > it” to “a dedicated attacker with 20_000 GPUs at hand might be able to > crack a single password within a year” (given the current default BCrypt > cost of 12 and 1.5kH/s/GPU which is within the range you mentioned in > the Argon2 thread). And as further elaborated below, the RFC does not > change that ceiling and turns the “not a math problem” into a usability > problem. > See, but you keep claiming it's a usability problem while defending it as a math problem, and being very selective about it too - you alone keep bringing up diceware. It's not the only plausible way to exceed the limit. > I don't see an added SHALL violation; the RFC is only making an > > already-present limitation visible. > > I said that it would be trading a SHALL for a SHOULD, not that it would > add new SHALL violations. This is theoretically better when going purely > based on standard reading, but does not improve the real world > situation. > Sorry about my imprecise wording, but I did follow the logical consequence of the trade to mean that, in order to satisfy SHOULDs you'd be violating a SHALL. Maybe you meant it the other way around ... Unimportant, just wanted to clear the air. > > Might be true for CJK; not true for Cyrilic, Greek - halved in length > > and > > strength no matter how you look at it. And I'm not mentioning others > > simply > > because I'm not familiar with them, but there are multiple. > > The conclusion remains the same: The user picks a shorter password and > you are back to square 1. And of course telling the user “your password > may be at most 72 bytes in length” when they don't know what bytes are > and why some characters are more than 1 byte (so they can't even count > the number of bullets in the password input to check if their password > fits) will just lead to frustrated users picking much weaker passwords > instead. > That's sweeping a lot of details under the rug. - Saying that users will choose weaker passwords, while at the same time standing on the argument that length difference at that ceiling is irrelevant. I can see what you meant non-maliciously, but I'm sure you too can see how that's having it both ways and not a fair representation. - The average user, for whom we have observations and can make some assumptions about, is not the one choosing extreme-length passwords. The limit will be hit either by people who have an affinity for security OR by users who are *victims* of problems constructed upstream from them (such as prefixes added by developers and corporate IT staff, for reasons right or wrong). In the latter case, raising an error is the only way to make these these upstream issues visible. - While a poor way to construct passwords, some users will choose a constant prefix and then a suffix based on the domain name they're accessing (or functionally equivalent unique identifier). If the prefix is long enough, silent truncation is completely eliminating the user's ability to know that they no longer have unique passwords (however flawed their method was), in turn making them vulnerable to more types of attacks. Note that passwords get exposed in ways other than cracking hashes, like accidental (or even intentional) logging, so that's not a prerequisite. - We are (for obvious reasons) looking at the whole thing from a server-side perspective, but where any burden is shifted onto the end user, there is a client side and input field limits are very much a thing. How the 1-byte or 2-byte characters disctinction is handled, if at all possible, is indeed a real problem. Now we have progress! > Your interpretation is not quite correct. My position is roughly “it > sure would be better if BCrypt wouldn't have the truncation limit, but > that ship has sailed”. My main issue with this proposal is not the > “breaking existing applications” bit, but “forcing applications to > expose the byte limitation to the non-technical end user”. The RFC is > turning a theoretical security issue (for genuine passwords) into actual > usability issues for non-technical users who learned “longer = better”. Fair enough, though we'll have to agree to disagree on the ship sailed argument. On Thu, Oct 1, 2026 at 1:10 AM Tim Düsterhus <[email protected]> wrote: > My expectation is that developers who are “alerted” to the limitation > will just go with whatever solution makes the error message go away the > quickest instead of trying to understand the impact, leaving the overall > system in a less secure state. Silent truncation by PHP itself is no different in principle. Dressing up the same fallacy because we think we know better than the affected parties is just putting lipstick on a pig. On Thu, Oct 1, 2026 at 11:21 AM Tim Düsterhus <[email protected]> wrote: > To provide a constructive suggestion: Borrowing passlib’s > `bcrypt-sha256` > ( > https://passlib.readthedocs.io/en/stable/lib/passlib.hash.bcrypt_sha256.html) > > algorithm (including the output format) might be a valid option for a > well-defined pre-hashing solution. I am actually preparing something based on the same principle, but didn't want to bring it up prematurely. I think this RFC has merit on its own and have seen way too many proposals be killed on the promise of something else in the uncertain future. Cheers, Andrey.
