Rails, authentication, & bcrypt

Second only to credit card hacks, one of the most common concerns of a web application user is password security. Luckily, for us rails devs, there are a plethora of gems that do this heavy lifting for us. If you look under the hood of some of these gems you’ll find a beauty of an algorithm called bcrypt. Now, if you’re like me and began developing rails within the last half-decade or so, it is very possible you first heard about this algorithm in Michael Hartl’s “Rails Tutorial” book. Hartl doesn’t go into detail about what the exact benefits are of bcrypt so in this post I’ll look at how it works its magic.

A simple but effective rails authentication gem is ‘bcrypt-ruby’. Once installed, the requirements to utilize this authentication is to simply add a :password_digest attribute and the line ‘has_secure_password’ to your user model. Thats it. Amazingly simple. The gem exposes the #authenticate method, which compares its argument to the database-saved digest of the users password. If a match, it returns true. But lets ask what does this do for us in terms of security?

The answer is a essential two-fold benefit for a modern web application. The primary function of bcrypt is to create an encryption for the user’s password. It does this by generating a hash value from the original string and then applying this value to an encrypting algorithm. In doing this, the encrypted string can be saved to the database instead of the actual password, preventing database breaches from exposing the user’s password directly. However, this alone would not prevent a hacker from hacking a database, collecting all the encrypted passwords, and iterating over a table of words until a match to the user’s encypted password is found.

The average Macbook can perform this type of trial and error approach to finding a match at an alarming rate. Bespoke built machines can do it at rates in order of several magnitudes faster. In comes bcrypt. The magic behind bcrypt is setting up and running the algorithm responsible for crafting the hashes takes considerable time. The average bcrypt hash run probably takes about half to a full second, not long by the human perspective, but a massive amount of time from the computational standpoint. Once this is factored in, the time it takes to perform the same kind of trial and error approach goes from a few seconds up to hundreds of years.

Now, if you’re very clever, you may be thinking along the lines of, “what will happen when computers are ever faster than they are when bcrypt was crafted?” Fortunately, the crafters of bcrypt are also very clever. The computational load can actually be increased and decreased, just like shifting gears in a car. (In fact, many devs crank it all the way down during development to save time.) So developers using bcrypt will be able to simply turn up the processing load of the encryption to compensate for faster future processors. Its truly genius, if you ask me.

So thats what the basic story is behind bcrypt. If you’d like to learn more, I’d recommend checking out this dev-famous blog post by Coda Hale: http://codahale.com/how-to-safely-store-a-password/

And, of course, if you haven’t gone through Michael Hartl’s book, I highly recommend it at: https://www.railstutorial.org/

And lastly, follow me on twitter to keep up with future blog posts!