On Wed, 30 Sept 2026 at 17:40, Rowan Tommins [IMSoP]
<[email protected]> wrote:
>
> On 30 September 2026 16:13:58 BST, Kamil Tekiela <[email protected]> wrote:
> >We are not lying to them right now. They can set longer passwords.
>
>
> No, they can't. They can *input* longer passwords, but that input is not 
> *stored*.
>
> If I encountered a database that truncates names to 10 bytes, I would 
> describe it as not correctly handling longer names. Telling users that they 
> can set longer names, but never actually storing them, would be lying.

Passwords are not stored either. Only the hash is stored. The hash can
be a result of multiple distinct inputs. There is no guarantee that a
password will always produce a unique hash.

>
> >It will still match. A hash of 72-byte long password and a hash of
> >73-byte long password where the first 72 bytes are the same will
> >match. https://3v4l.org/o7dJq#v8.5.11
>
>
> Yes, and that is a false positive - the user provides the wrong password, and 
> the system lets them in.

It's still a valid password. As I said, conflicts occur, so you don't
have to provide the exact same password to be let in. Just one that
produces the same hash.

>
> >Because the password is just as strong as it would be if we didn't
> >ignore the unnecessary bytes. It would be corrupted if the password
> >got weaker or changed in a way that it could no longer be verified
> >against its hash.
>
>
> Of course it gets weaker - it's shorter!

Longer passwords are not automatically stronger. In fact, past a
certain length, they are either all the same strength or even weaker
because an attacker can guesstimate the used characters and structure,
e.g. Diceware

> >> Imagine if it truncated at 7 bytes; would you still call that "correct 
> >> handling", as long as it was documented behaviour?
> >
> >Obviously, yes. I don't understand your point.
>
>
> Then we are stuck. I can't imagine how "most of your password is silently 
> thrown away" can be considered "correctly handled". It can be *a known 
> limitation*, but from a user's point of view, it's very clearly *not doing 
> what they asked*, which was to set a longer password.

>From a user's POV, it doesn't, and I agree with that. But that's not
very important for what we are discussing here. If it works as
designed, then it works correctly.

Reply via email to