Hacker News Reader

Comment by jadengis | Hacker News Reader

This is obviously a huge mistake by Okta (for the love of God understand how your crypto functions work before you apply them) but at the same time, a crypto function with a maximum input length that also auto-truncates the data sounds like bad API design. You are basically asking for someone to goof up and make a mistake. It's much better to implement these things defensively so that the caller doesn't inadvertently make a mistake. Especially with a hashing algorithm, because there is no way to verify that the result is correct.

View on HN

Agree with the spirit of the argument, but I disagree about the bad design. BCrypt has its trade-offs, you are expected to know how to use it when using it, specially if by choice.

It's like complaining about how dangerous an axe is because it's super sharp. You don't complain, you just don't grab the blade section, you grab it by the handle. And

If your crypto library works like an Axe and the methods aren’t prefixed with “unsafe_”, the library is bad. I would expect an exception when a hashing function gets an argument that’s too long, not just dropping of the excess input. Who thinks that’s the best choice?

If passing more than 72 bytes to a function makes it silently fail, it IS bad design, especially for a sensitive, security-related function. The first condition in the function should be `if len(input) > 72 then explicitly fail`

Not letting people use your API incorrectly is API design 101.

To be clear this is not the fault of the bcrypt algorithm, all algorithms have their limitations. This is the fault of bcrypt libs everywhere, when they implement bcrypt, they should add this check, and maybe offer an unsafe_ alternative without the check.

There is no other answer than this. Silent failures are never acceptable, even if documented. Because despite what we want to believe about the world, people don’t read the docs, or read them and forget, or read them and misunderstand.

Passing something that isn’t a password + salt into bcrypt is the mistake here.

Even that sounds potentially dangerous to me now, since it effectively means that some extra-long "correct horse battery stapler"-style passwords could be left effectively unsalted. I mean yeah, 78 chars is an awfully long password but for some famous book or movie quotes maybe not outside the realm of possibility. Or if languages using double-byte characters effectively halve that cutoff then it really becomes an issue...

Reply on news.ycombinator.com