has_secure_password with Rails 4.1

I just started a new project with Rails 4.1 and explored the has_secure_password feature. Really awesome stuff!

I hope you are not storing passwords in clear text to your database! You should always store some kind of hashed values instead of clear text passwords. In case somebody steals your database he/she still doesn’t has the passwords.

There are a couple good tutorials how to hash and store passwords in a secure way. I implemented it a couples times by myself with Ruby.

A more sophisticated solution is devise, a very robust gem for security and authentication.

However. Since Rails 3.1 you can take advantage of has_secure_password. This mechanism in Rails takes care of password validation and encryption. It requires a field ‘password_digest’ in your model, where it will store the encrypted password. Let’s generate a simple model.

rails g model user username:string password_digest:string

Let’s add this line to the user model.

has_secure_password

This will add an attribute `password` and `password_confirmation` to your model. This 2 fields are now part of your model but not part of the database schema! Because we don’t want to store cleartext passwords.

Let’s add some tests.

require 'spec_helper'
describe User do
it "fails because no passwrod" do
User.new({:username => "hans"}).save.should be_false
end
it "fails because passwrod to short" do
User.new({:username => "hans",
:password => 'han'}).save.should be_false
end
it "succeeds because password is long enough" do
User.new({:username => "hans",
:password => 'hansohanso'}).save.should be_true
end
end

3 very simple tests. Persisting a new user without password should fail. Persisting a new user with too short password should fail as well. And creating a new user with a long password should succeed. If you run this tests with RSpec the 2nd test will fail. By default Rails doesn’t has a validation for the length of the password. So let’s add it to our user model.

If you run the tests again, they will be green. If you take a look into your database you will see that the user table/collection has a column `password_digest` with a very cryptical value. But there are no columns for password! That’s exactly what we wanted.

Now lets do the authentication. Assume a new user signed up at your portal and now he wants to login. This is how you authenticate him.

If the username and the clear text password from the HTTP Request is correct it will return a valid user from the database. Otherwise it will return nil!

`has_secure_password` validates the password on creation time, the very first time you persist it. It doesn’t check the password field after that, for updates for example. And that’s OK. Because that means you can load a user later from db, change it and persist it without knowing the password.

Another feature of this mechanism is password confirmation. `has_secure_password` also adds an attribute `password_confirmation` to your model. This attribute gets only validated if it’s not nil. If it’s not nil it must be equal to the password attribute. Let’s add 2 more tests for that one.

2 thoughts on “has_secure_password with Rails 4.1”

I was wondering about the actual implementation of `has_secure_password`, took a look at the source code and recognized it didn’t store any salt. I wondered, because I thought using salts is a best practice. It turned out that the bcrypt algorithm used to hash the password works differently than I thought it would work. Here is a great explanation: http://stackoverflow.com/a/6833165/104959