5 ms·

It is really not difficult to use BCrypt or Argon2 with your backend of choice. Proper password and session management have been made accessible for many years

It is really not difficult to use BCrypt or Argon2 with your backend of choice. Proper password and session management have been made accessible for many years if you use any "modern" backend.

void_mint 5y ago
> Its really not difficult Good luck to you!
city41 5y ago
It's true the happy path and common error cases are easy to account for. But it just takes one overlooked bug or vulnerability either in your code or a library's code to send it all crashing down.
- arcbyte 5y ago
  This is true across the board. One tiny crack in a bridge might mean it will collapse. That doesn't mean we should stop building bridges.
  - void_mint 5y ago
    Sure, but it certainly means we should leave bridge building to those who are experts in that field.
bhaney 5y ago
> It is really not difficult to use BCrypt Something I once saw in production: An otherwise normal usage of bcrypt, that "prehashed" the password with sha512 before passing the resulting hash to bcrypt. This is conceptually reasonable (although not very useful) for reasons I don't think are worth going into, but had two critical problems. 1. It technically broke bcrypt's side-channel protection against timing attacks (bcrypt runs in constant time, while sha512 does not). 2. The much worse issue was that the binary hash was being passed to bcrypt. If bcrypt encounters a null byte in the input, it considers that to be the end of the input and ignores everything after, c-string style. Every byte of the binary hash had a 1/256 chance of being a null byte, which means 1/256 passwords result in a hash with the first byte being null, which means bcrypt will accept any of them as equivalent to the others. You could login to 0.4% of accounts by guessing ~256 completely random passwords (and a larger number of passwords were similarly but less extremely weakened) You can say "well that's their fault for mucking with the input to bcrypt" but I bet most people would believe that kind of operation was safe before it's explained to them why it's not. It's very easy to accidentally destroy the security of a crypto scheme without knowing it, and thinking that what you're doing is perfectly run of the mill and safe.
- arcbyte 5y ago
  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.
  - deleted 5y ago
    [deleted]
  - capableweb 5y ago
    > 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.
    - whakim 5y ago
      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.
  - bhaney 5y ago
    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.

It is really not difficult to use BCrypt or Argon2 with your backend of choice. Proper password and session management have been made accessible for many years if you use any "modern" backend.

void_mint 5y ago

> Its really not difficult Good luck to you!

city41 5y ago

It's true the happy path and common error cases are easy to account for. But it just takes one overlooked bug or vulnerability either in your code or a library's code to send it all crashing down.

arcbyte 5y ago
This is true across the board. One tiny crack in a bridge might mean it will collapse. That doesn't mean we should stop building bridges.
- void_mint 5y ago
  Sure, but it certainly means we should leave bridge building to those who are experts in that field.

bhaney 5y ago

> It is really not difficult to use BCrypt Something I once saw in production: An otherwise normal usage of bcrypt, that "prehashed" the password with sha512 before passing the resulting hash to bcrypt. This is conceptually reasonable (although not very useful) for reasons I don't think are worth going into, but had two critical problems. 1. It technically broke bcrypt's side-channel protection against timing attacks (bcrypt runs in constant time, while sha512 does not). 2. The much worse issue was that the binary hash was being passed to bcrypt. If bcrypt encounters a null byte in the input, it considers that to be the end of the input and ignores everything after, c-string style. Every byte of the binary hash had a 1/256 chance of being a null byte, which means 1/256 passwords result in a hash with the first byte being null, which means bcrypt will accept any of them as equivalent to the others. You could login to 0.4% of accounts by guessing ~256 completely random passwords (and a larger number of passwords were similarly but less extremely weakened) You can say "well that's their fault for mucking with the input to bcrypt" but I bet most people would believe that kind of operation was safe before it's explained to them why it's not. It's very easy to accidentally destroy the security of a crypto scheme without knowing it, and thinking that what you're doing is perfectly run of the mill and safe.

arcbyte 5y ago
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.
- deleted 5y ago
  [deleted]
- capableweb 5y ago
  > 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.
  - whakim 5y ago
    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.
- bhaney 5y ago
  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.