Hi, On Wed, Sep 30, 2026 at 7:56 PM Kamil Tekiela <[email protected]> wrote:
> > 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. > You can't base your argument on the premise that it's all fine because the algorithm itself is strong and at the same time claim that conflicts occur. Collision resistance underpins all security claims about hashing algorithms. > > >> 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. > ... and who's to say that the design is correct to begin with? Why are you assuming that a design from 1999 has seriously considered the problem at hand? Will a 32-bit UNIX timestamp be correct in 2038? It is very hard to respect your POV when it's based on circular logic. Cheers, Andrey.
