Re: [RFC] Throw error for passwords lo nger than 72 bytes in password_hash() with bcrypt

On 29 September 2026 13:04:21 BST, Kamil Tekiela <tekiela246@gmail.com> wrote: >By adding a ValueError which only fires when the input is too long, >you are introducing a silent failure vector that is difficult to catch >or test for. On the contrary, it turns a silent failure into a noisy one, prompting the developer to take action. > If an application doesn't limit user password length to >72 bytes, there will be users that will try such passwords and the >application will crash for them instead of working correctly as >before. Such a system was not working correctly before - it was accepting passwords that it could not verify later, and consequently accepting logins which did not match the user's intended password. > And since an overlong password is an acceptable input Why is it an acceptable input? If the algorithm can't correctly hash that input, why should it tell the user it has done so? It would be a problem if users who have *already* set passwords which they intended to be longer than 72 bytes are prevented from logging in, but the proposal covers that by leaving password_verify unchanged. > Both should be caught in a code review no a senior developer, not runtime. If every PHP login implementation was reviewed by an expert senior developer, we would not need the password_* API in the first place. The value of this API is that it makes doing the right thing easy, so that you *don't* need to be an expert in the underlying algorithms to use it safely. I support the RFC as currently proposed. Rowan Tommins [IMSoP]