Hacker News Reader

Comment by arcbyte | Hacker News Reader

Thank you for sharing that experience. It was a very interesting read.

However, lest anyone get the wrong opinion, password hashing is a very simple, straightforward, solved problem and has been for years.

One person doing something monumentally stupid doesn't make Auth some kind of cryptic minefield.

View on HN

My point is precisely that it wasn't "monumentally stupid," but rather a pretty reasonable decision given what the average person would expect bcrypt to provide functionally. The behavior I described is an unexpected landmine that people using bcrypt need to be aware of. There are likely others, though probably not enough that I would describe it as a minefield.

I would wager that most people reading this, if earnestly asked by a coworker "do you think it's fine for me to hash a password before passing it to bcrypt? I want to be able to support passwords over 72 characters and bcrypt truncates its input." would answer something along the lines of "I don't see how it could hurt" rather than "that's dangerous because a binary hash would result in a large portion of the passwords being hashed as an empty string"

The engineers that originally implemented and reviewed this were not idiots, they just weren't security experts.

My answer would definitely be: I don't know, but why bother. We know bcrypt by itself works. We don't know whether it works combined with another hash, and it's extra code we need to maintain.

> Stop trying to make something sound difficult that isn't. Password hashing is a very simple, straightforward, solved problem and has been for years.

Try asking the following question on Twitter:

"While passing binary data, which example is safer for storing passwords?

[ ] $password | sha256 | bcrypt

[ ] $password | bcrypt"

What do you think the average programmer would say? Most would probably say they are either equal, or the first one, without knowing this specific thing, because most people don't implement their own password-hashing, they use library/framework provided ways that has been established as best practice already.

But, can't blame them really, the difference is marginal and innocent on the surface, but once you understand the implementation, you'll see the holes.

I think the question isn't particularly relevant because many programmers are just using bcrypt in a simple way that's very well documented. I think it's reasonable to expect people to know that "auth is dangerous, don't just do your own special thing and assume it'll be fine." If you want to do something that diverges from the simple case, then please don't try to roll your own auth.

It's monumentally stupid to think auth is easy. Yes there are standard cookbooks and checklists out there. The hubris to think that auth fails due to a crypto scheme choice is why average programmers consistently fail at it.

The yearly report of leaks in Fortune 500 companies should be proof enough of this.

EDIT: To elaborate. Crypto scheme is only one tiny facet of a successful authentication solution. Where do you store the hash? What language and stack are you using? What is the maturity of libraries available to you? What protocols? And many more seemingly tiny decisions. All it takes is a lazy developer that imports an insecure transient dependency or snoozes on a CVE.

Reply on news.ycombinator.com