As Anne_Ominous wrote in the comments, this solution needs salts to be truly secure. One reply to Anne links to a sentence in the bcrypt-ruby docs: "bcrypt-ruby automatically handles the storage and generation of these salts for you.". However, there's something I don't understand. Where are the salts stored? The linked article mentions only that the model needs a password_digest field. If the salt is stored alongside it, shouldn't we need a password_salt field too? And if the salt is stored in a separate database, isn't that inefficient and unscaleable?
Which wasn't that hard to use unsugared. This move also signals to the community that bcrypt is considered a best practice, important enough that it's included by default. Rails benefits from this.
This move also signals to the community that bcrypt is considered a best practice, important enough that it's included by default.
bcrypt has been considered a best practice for quite a while. it's been openbsd's default password hashing scheme since 1997, and used in a number of php projects like drupal, phpbb, and wordpress for many years.
Yup. That hasn't stopped hordes of devs from doing stupid things with passwords. My point is that now, at least for Rails, bcrypt is harder to ignore. And that's a good thing.
Agreed. Switching authentication gems is incredibly painful. Sometimes I think the best solution is to use the "low-level" gems like warden and always craft an authentication system myself.
