Exploring Rails 3.1 - ActiveModel::SecurePassword(bcardarella.com)
bcardarella.com
Exploring Rails 3.1 - ActiveModel::SecurePassword
http://bcardarella.com/post/4668842452/exploring-rails-3-1-activemodel-securepassword
2 comments
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?
>> hash = BCrypt::Password.create '123456'
=> "$2a$10$khoJWZR3hVA8Qcm3lW6sp.BQGOFKGo2xHCeH2YfDcQVRltEGCJe0S"
>> [hash.salt, hash.checksum]
=> ["$2a$10$khoJWZR3hVA8Qcm3lW6sp.", "BQGOFKGo2xHCeH2YfDcQVRltEGCJe0S"]
=> "$2a$10$khoJWZR3hVA8Qcm3lW6sp.BQGOFKGo2xHCeH2YfDcQVRltEGCJe0S"
>> [hash.salt, hash.checksum]
=> ["$2a$10$khoJWZR3hVA8Qcm3lW6sp.", "BQGOFKGo2xHCeH2YfDcQVRltEGCJe0S"]
I believe, but I'd have to go check bcrypt to make sure, that the salt is stored as part of the digest.
Edit:
Actually, after minimal research, I see that salting the password is handled by the bcrypt ruby gem.
Edit:
Actually, after minimal research, I see that salting the password is handled by the bcrypt ruby gem.
bcrypt stores the salt alongside the hash, so a single field is sufficient.
Wouldn't this make gems like Devise irrelevant?
This still doesn't handle email verification, multiple roles, remember me tokens, and a slew of other features Devise offers.
This is really just some Rails sugar around bcrypt-ruby.
This is really just some Rails sugar around bcrypt-ruby.
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.
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.
I hope so. It's a real pain to switch gems when the auth of the week is left for dead.
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.
That reminds me, which is the auth gem of the week currently, Devise?
Devise is excellent. Jose Valim's gems tend to become standards pretty quickly.
for large values of "week", the railscast for devise is more than year old, and it had already gained quite a lot of mind share by then
Devise with omniauth if you want multiple logins