That is such a rookie mistake. It's not some hidden information that bcrypt has a 72 char limit. Pretty widely documented in multiple implementations and languages.
How does a company whose only job is security screw that up so badly?
That is such a rookie mistake. It's not some hidden information that bcrypt has a 72 char limit. Pretty widely documented in multiple implementations and languages.
How does a company whose only job is security screw that up so badly?
> It's not some hidden information that bcrypt has a 72 char limit. Pretty widely documented in multiple implementations and languages.
One of the points of the article is that documentation isn’t enough: one cannot allow callers to misuse one’s API.
> How does a company whose only job is security screw that up so badly?
While I don't have any answers to this, I've realized that it's an ideal showcase of why fuzzy testing is useful.
On one hand, I have never heard of a password hashing algorithm that truncated to 72 characters. I assumed all one-way hashing functions were arbitrary length input. "arbitrary input -> fixed output" has always been part of the definition of hash, to me.
On the other hand, I'm not a security developer at Okta.
og crypt does the same shit but 8 characters. weird historical artifacts i suppose.
On the other hand, why not have implementations assert if they are given a string longer than 72 chars? It feels to me like no-one would ever do that on purpose, so it's a massive issue which is easy to accidentally make with a really important function.
Don't disagree there. I asked my self the same question the first few times I had to use it.
Silently truncating the data is about the worst way to deal with it from a security standpoint. No idea why that decision was made back in the day.
It is almost never I good idea to assert in a library, unless the error is truly unrecoverable. I think returning an error code\throwing an exception would be very reasonable and a much better API than failing silently though.
> almost never I good idea to assert in a library, unless the error is truly unrecoverable
Like getting an input that is too long? :)
I think a library asserting that the preconditions of its arguments are true is fine.
An exception is fine if the language has them. I don't think "assert" was meant super literally and exactly the way C does it.
An error code is risky.
Honestly, I would assert. Returning an error code just gives users another thing to ignore, and incorrectly use the return value (if implemented like C, where you usually get a single internet back, treating the error code as a hash would be even worse!)
Apps crashing with assets is awfully, but at least it screams at your when you failed to read the docs, target than incorrectly storing users data for the rest of time.