Splitting out some of the authentication code into “authenticators” has worked out great so far. More importantly, its more or less a blueprint for people to extend Authlogic and provide alternate authentication solutions (openid, facebook connect, oauth, etc.).

The last major change I’ve been making is removing validations in the acts_as_authentic module. Validations add some clutter to authlogic, some might say its a necessary clutter, but I’m leaning towards leaving it out. Validation is such an easy thing to do. ActiveRecord provides very simple methods for doing this, I also feel like its gets in the way for certain edge cases. Authlogic will still provide some nice methods to make your life easier, like validating the format of an email address, the main difference being that you have to explicitly implement this validation. No validations will be automatically added. Lastly, this makes ORM abstraction a little easier.

So that’s that. I’ll keep you updated when I start to push out some code and what not. I’m probably going to label this release as v3, because of the validation changes and some of the other major changes that might break backwards compatibility.

In my opinion generators are meant to be a starting point for repetitive tasks that have no sustainable pattern. By repetitive, I mean repetitive in a single application. Ex: multiple controllers, multiple models, etc. 95% of applications are going to create 1 Authlogic model and 1 controller for that model. If they are creating more than one, it is mostly likely for a highly unique situation where a generator would be of no use. Which leads me to my question:

Why not just create your own personalized base application or template that you can start from when you need to start a new application?

This is exactly why rails templates were created. They were created for this exact problem. A generator is never going to please everyone, and if it does, it would have a million options and be extremely complicated. Also, I don’t know about you, but I am extremely picky about my code. Even if my code and someone else’s code does the exact same thing, I want my code formatted a certain way. This is a big reason why I dislike restful_authentication. All of this code, that I do not like, gets inserted into my application. It just feels dirty. I’d much rather build my own authentication solution into a base app, that I like, and use that in my next application.

I just haven’t been convinced that creating a generator for Authlogic is a good use of my time. If you can convince me otherwise I’ll gladly do it. It’s not that I don’t want to spend the time, its that I truly feel a base app or a rails template is a better solution.

What do you think?

Use the same password algorithm as restful_authentication

# app/models/user.rb
class User < ActiveRecord::Base
  acts_as_authentic do |c|
    c.act_like_restful_authentication = true
  end
end

Transition to one of Authlogic password algorithms

The first thing you need to do is make sure your database field “crypted_password” and “salt” allow for the storage of at least 128 characters (assuming you are migrating to Sha512). restful_authentication uses Sha1 which is 40 characters. If you are limiting the size, you need to create a migration that looks similar to.

change_column :users, :crypted_password, :string, :limit => 128,
  :null => false, :default => ""

change_column :users, :salt, :string, :limit => 128,
  :null => false, :default => ""

Now just tell acts_as_authentic what you are doing:

# app/models/user.rb
class User
  acts_as_authentic do |c|
    c.transition_from_restful_authentication = true
  end
end

You could pass an optional argument to transition to any password algorithm you want. By default Authlogic uses the Sha512 algorithm, but let’s say you wanted to transition to the BCrypt algorithm. No problem

# app/models/user.rb
class User < ActiveRecord::Base
  acts_as_authentic :transition_from_restful_authentication => true,
    :crypto_provider => Authlogic::CryptoProviders::BCrypt
end

For more information on BCrypt checkout my blog post about it.

What’s the difference?

act_like_restful_authentication will not change a thing, your users passwords will remain in the same format. From your database’s perspective, it will be as if you are using restful_authentication.

transition_from_restful_authentication starts changing your users passwords using the Authlogic passwords system that you specify with the :crypto_provider option. How does it do this? It’s simple, every time a user successfully logs in and their password is encrypted with the restful_authentication algorithm it will update their password with the Authlogic algorithm. When a new account is created it will use the Authlogic algorithm. This allows your user base to slowly transition and allowing them to still be able to log in.

That’s it. I’m not going to go into the Authlogic set up because I already have a tutorial on this.

Let me know what you think or if you have any questions.

Migrating to another password algorithm within Authlogic

I recently released BCrypt as an optional crypto provider for Authlogic, let’s say you are using the default crypto provider Sha512 and want to start using BCrypt. No problem:

# app/models/user.rb
class User < ActiveRecord::Base
  acts_as_authentic do |c|
    c.transition_from_crypto_providers = Authlogic::CryptoProviders::Sha512,
    c.crypto_provider = Authlogic::CryptoProviders::BCrypt
  end
end

All of your users will be migrated to the new BCrypt method when they log in next or when a user creates a new account.

Let’s pretend a new algorithm came out called “CCrypt”, and its better than BCrypt, and you want to use it. You’re users are in the middle of transitioning from Sha512 to BCrypt. Oh no!

Not to worry, because Authlogic can transition your users from more than one algorithm. Just pass an array to :transition_from_crypto_provider:

# app/models/user.rb
class User < ActiveRecord::Base
  acts_as_authentic do |c|
    c.transition_from_crypto_providers = [Authlogic::CryptoProviders::Sha512, Authlogic::CryptoProviders::BCrypt],
    c.crypto_provider = CCrypt
  end
end

That’s it. You can specify as many as you want. When your users login or create a new account their passwords will be encrypted with the CCrypt algorithm.

Migrating from any other password algorithm

All that you need to do is create a crypto provider that represents how your passwords are encrypted. Believe it or not, it’s dead simple. Sometimes the easiest way to explain something is by using code example, so please checkout the Authlogic::CryptoProviders module and sub classes in the documentation. All that you need to do is create a class with a class level encrypt and matches? method:

# lib/my_awesome_crypto_provider.rb
class MyAwesomeCryptoProvider
  def self.encrypt(*tokens)
    # encrypt your password here
  end

  def self.matches?(crypted_password, *tokens)
    # return true if the tokens match the crypted_password
  end
end

Transition to a new algorithm doesn’t get any easier than that.

Part of Authlogic’s responsibility to is to keep you on the cutting edge when it comes to security. Afterall, that is part of the reason you use Authlogic, so you don”t have to deal with it. Your app can use the latest and great security techniques just by updating the Authlogic gem.

That being said, today I released Authlogic 1.3.2. With this came a new optional crypto provider: BCrypt. According the to BCrypt website:

“There are two kinds of cryptography in this world: cryptography that will stop your kid sister from reading your files, and cryptography that will stop major governments from reading your files.”

My personal opinion is that the default Sha512 encryption that Authlogic uses is plenty secure, emphasis on plenty. Authlogic uses salted Sha512 with multiple stretches. Hell, the majority of apps use Sha1, because that’s what restful_authentication uses, and Sha1 is much less secure. I don’t want to link to these resources directly, but there are a number of resources available to perform reverse lookups on Sha1. I don’t want to paint the wrong picture here by saying Sha1 is insecure. It’s all in how you use it. As long as you are salting it and doing a number of stretches, which restful_authenticaton is doing, you are fine. But if you are storing extremely sensitive information in your app, such as nuclear launch codes, then you might consider something a little more secure.

What makes BCrypt more secure?

For one, BCrypt provides it’s own salting, then Authlogic provides salting as well. Double salting!

Secondly, when it comes to hashing algorithms, security mostly deals with the amount of time it takes to generate the hash. Take a dictionary attack on a Sha1 algorithm. A decent computer could fly through a list of every dictionary word in a relatively fast amount of time compared to BCrypt. Let me show you wish some benchmarks:

Benchmark.bm(18) do |x|
  x.report("BCrypt (cost = 10:") { 100.times { BCrypt::Password.create("mypass", :cost => 10) } }
  x.report("BCrypt (cost = 2:") { 100.times { BCrypt::Password.create("mypass", :cost => 2) } }
  x.report("Sha512:") { 100.times { Digest::SHA512.hexdigest("mypass") } }
  x.report("Sha1:") { 100.times { Digest::SHA1.hexdigest("mypass") } }
end

#                         user     system      total        real
# BCrypt (cost = 10): 10.780000   0.060000  10.840000 ( 11.100289)
# BCrypt (cost = 2):  0.180000   0.000000   0.180000 (  0.181914)
# Sha512:             0.000000   0.000000   0.000000 (  0.000829)
# Sha1:               0.000000   0.000000   0.000000 (  0.000395)

That my friend is a huge difference. There is a trade off between security and performance. If you are willing to take the performance hit then go for it. Play with the :cost option to get that perfect balance between performance and security. By default the BCrypt library uses a cost of 10.

Easily upgrade encryption and transition your users

As I mentioned above, the cost can be adjusted. So let’s say 5 years from now a cost of 10 isn’t as effective as it used to be, because computers are now faster, things have advanced, etc. No problem, just bump the cost up to whatever is now suitable. Your old passwords will continue to work, while the new passwords will be much stronger.

Here’s why using a library like Authlogic is so nice. As your users start to log in, Authlogic will handle upgrading their passwords to the new and improved cost.

Now your app can move with the times and constantly stay on the cutting edge of security, and you don’t have to worry about breaking all of your users passwords.

This is a cool feature, but nothing to go crazy about. The average app will probably never need to upgrade their encryption algorithm. If your app is around long enough, maybe you will upgrade it once. Even then, it’s probably not necessary because of the salting and stretches. Regardless, Authlogic will assist you in your upgrade if you choose to do so.

Lastly, you can get this feature with any encryption algorithm, including Sha. Checkout the “Upgrading encryption methods” in the Authlogic README. It’s very simple.

How do I use this?

It’s simple:

$ sudo gem install bcrypt-ruby

Starting a new app?

# app/models/user.rb
class User < ActiveRecord::Base
  acts_as_authentic do |c|
    crypto_provider = Authlogic::CryptoProviders::BCrypt
  end
end

Looking to switch to BCrypt?:

class User < ActiveRecord::Base
  acts_as_authentic do |c|
    c.crypto_provider = Authlogic::CryptoProviders::BCrypt
    c.transition_from_crypto_provider = Authlogic::CryptoProviders::Sha512
  end
end

The transition_from_crypto_provider is whatever crypto provider you are currently using. Check out my blog posts about transitioning to another crypto provider:

• Upgrade passwords easily with Authlogic
• Easily migrating from restful_authentication to Authlogic

What about [insert encryption method here]?

Check out the Authlogic::CryptoProviders module and the subclasses within. You can add you own method just by creating a simple class and letting acts_as_authentic know about. Authlogic bundles some common methods as a convenience to you, there is nothing wrong with adding your own if you feel its necessary.

Why isn’t this the default encryption method for Authlogic?

I have heard of people having issues with the BCrypt library on windows. I have not used windows in years, so don’t take my word for it, but approach it with some caution. I decided to go with Sha512 since that is part of the ruby core and works wherever ruby can be installed.

Then again, using a library like bcrypt on windows is somewhat ironic. If you are very concerned with security I doubt you will be putting your app on windows. To me using BCrypt on Windows is like putting a state of the art lock on a cardboard box.

Final thoughts

The level of security your app provides is really up to you. Unless you are writing apps for the pentagon, the default Sha512 is fine. Regardless, Authlogic shouldn’t get in your way or make decisions for you, so if you feel BCrypt is necessary then go for it.

What am I about to read?

You are going to read a tutorial on how to reset passwords the RESTful way. I am going to pick up where I left off on the Authlogic basic setup tutorial, so if you have not read that I highly recommend doing so.

Want to see it in action before you start? Check it out for yourself:

A live example of this tutorial

Before we begin, let me walk you through the basic process of resetting a password as I see it:

1. A user requests a password reset
2. An email is sent to them with a link to reset their password
3. The user verifies their identity be using the link we emailed them
4. They are presented with a basic form to change their password
5. After they change their password we log them in, redirect them to their account, and expire the URL we just sent them

That seems pretty simple, right? So let’s get started…

Helpful links

Before we start I want give you some helpful / related links:

• Tutorial: Authlogic basic setup
• Live example of the this tutorial
• Source code of this tutorial
• Authlogic repository
• Authlogic documentation

1. Add in the reset_password_token and email fields

I am going to pick up from the Authlogic basic setup tutorial, so I am assuming you are familiar with Authlogic and the basic setup.

With this tutorial I am introducing a new field in your database called perishable_token. Authlogic will take care of maintaining this for you. Here is how:

1. The token gets set to a unique value before validation, which constantly changes the token. The value is a “friendly” value, something like: 4LiXF7FiGUppIPubBPey, not as long or as hardcore as a Sha512 hash, so it doesn’t cause problems when emailed or copying and pasting into a browser.
2. After a session is successfully saved (aka logged in) the the token will be reset. This makes the email we sent them before no longer usable.

Generate your migration:

$ script/generate migration add_users_password_reset_fields

Now update the migration:

class AddUsersPasswordResetFields < ActiveRecord::Migration
def self.up
add_column :users, :perishable_token, :string, :default => "", :null => false
add_column :users, :email, :string, :default => "", :null => false

add_index :users, :perishable_token
add_index :users, :email
end

def self.down
remove_column :users, :perishable_token
remove_column :users, :email
end
end

Migrate your database:

$ rake db:migrate

When adding the email field Authlogic will notice this and validate it for you, making sure the email is unique and a valid email address. If you wish to disable this just pass the :validate_email_field => false option to acts_as_authentic. You can also have it ignore the email field all together by passing the :email_field => nil option.

2. Let users request a password reset

We need to know if users lost their password, why not create another resource for this?

$ script/generate controller password_resets

Let’s fill out this controller with some actions (I will explain them below):

Now update your routes:

# app/controllers/password_resets_controller.rb
class PasswordResetsController < ApplicationController
def new
render
end

def create
@user = User.find_by_email(params[:email])
if @user
@user.deliver_password_reset_instructions!
flash[:notice] = "Instructions to reset your password have been emailed to you. " +
"Please check your email."
redirect_to root_url
else
flash[:notice] = "No user was found with that email address"
render :action => :new
end
end
end

What did I just do?

The deliver_password_reset_instructions! is a method I added, you can call it whatever you want. All that it does is reset the password reset token and send an email.

Here is what I did in my own application:

# app/models/user.rb
class User < ActiveRecord::Base
def deliver_password_reset_instructions!
reset_perishable_token!
Notifier.deliver_password_reset_instructions(self)
end
end

The reset_perishable_token! is a handy method Authlogic gives you. It basically resets the field to a unique “friendly” token and then saves the record.

My Notifier action looks like this:

# app/models/notifier.rb
class Notifier < ActionMailer::Base
default_url_options[:host] = "authlogic_example.binarylogic.com"

def password_reset_instructions(user)
subject       "Password Reset Instructions"
from          "Binary Logic Notifier "
recipients    user.email
sent_on       Time.now
body          :edit_password_reset_url => edit_password_reset_url(user.perishable_token)
end
end

Then the email looks like:

# app/views/notifier/password_reset_instructions.erb
A request to reset your password has been made.
If you did not make this request, simply ignore this email.
If you did make this request just click the link below:

If the above URL does not work try copying and pasting it into your browser.
If you continue to have problem please feel free to contact us.

You can do the above any way you want. I actually recommend creating a text and html version of this email, but for the sake of brevity I only included the text version.

3. Let users reset their password

Once they get that email and click the link in it, it needs to take them somewhere. So let’s add some methods to our PasswordResetsController:

# app/controllers/password_resets_controller.rb
before_filter :load_user_using_perishable_token, :only => [:edit, :update]

def edit
render
end

def update
@user.password = params[:user][:password]
@user.password_confirmation = params[:user][: password_confirmation]
if @user.save
flash[:notice] = "Password successfully updated"
redirect_to account_url
else
render :action => :edit
end
end

private
def load_user_using_perishable_token
@user = User.find_using_perishable_token(params[:id])
unless @user
flash[:notice] = "We're sorry, but we could not locate your account. " +
"If you are having issues try copying and pasting the URL " +
"from your email into your browser or restarting the " +
"reset password process."
redirect_to root_url
end
end

What did I just do?

1. You really don’t need to add the edit method because its a blank method, the before_filter takes care of everything we need to do there. There is only a view for this method.
2. The update method is nice, because if the user is successfully saved, Authlogic will automatically log them in, keeping your PasswordResetsController focused on resetting passwords, not sessions.
3. The load_user_using_perishable_token has a unique method: find_using_perishable_token. This is a special method that Authlogic gives you. Here is what it does for extra security:
   1. Ignores blank tokens
   2. Only finds records that match the token and have an updated_at (if present) value that is not older than 10 minutes. This way, if someone gets the data in your database any valid perishable tokens will expire in 10 minutes. Chances are they will expire quicker because the token is changing during user activity as well.

4. Restrict access

Now we just need to make sure the user is logged out when accessing these methods. Modify your before filters in your PasswordResetsController to look like:

before_filter :require_no_user

Where are the views?

Instead of cluttering up this tutorial with a bunch of basic views, I left them out. There is nothing crazy going on in the views, nor do I really need to explain anything. If you noticed in the helpful links section I have a live example of this tutorial.

Here is a direct link to the users views source code, you can copy the views over from here

Why not reset passwords this way…?

If you care, here are my thoughts behind this tutorial and ultimately why I recommend resetting passwords this way…

My goal with Authlogic was to stay away from generating code and give you the proper tools so that you could easily and effectively write the code yourself. If you noticed, in this tutorial, all that we really did was add a simple PasswordResetsController. Most of this tutorial was explaining what was going on, so you could understand what you were doing. I can’t write that controller for you, because it is application specific. I want to keep the authentication logic in Authlogic and your application logic in your application. The tutorial above produces simpler and cleaner code than a generator. The most important part is that you understand what is going on and it works the way you want. I am basically laying out tools for you to use and explaining them. You get to use them how you wish. There is no “Surprise! Here are hundreds of lines of code, hope you like it”. If you want to change passwords a different way, go for it, you now know how Authlogic can assist you in your journey to resetting passwords.

Lastly, I know there are a few other common ways to reset passwords, so I will address those and why I decided against them:

1. Changing / randomizing the password during the first step and then emailing them their new password
   You should NEVER change anyone’s password until they have proven they are that user. What if Billy 13 year old starts typing in random logins and resetting peoples passwords? Those people aren’t going to be happy.
2. Using an already existing token that is not unique or perishable
   A lot of people are tempted to use the remember_token, single_access_token, or even the crypted_password for authenticating the user for a password change. There is a reason we have all of these and none of these should be used for resetting password. What if Billy 13 year old gets ahold of any of these, he will have full access to resetting that user’s password, and then have full access to their account. If for some reason he gets any of these things, your users should still be protected, which is why we need a unique and perishable token.

I think this is just the beginning though, here are my thoughts….

The Big Picture

Thanks to things like Rack, the MVC design pattern, and ActiveRecord / DataMapper, all of these frameworks look very similar. They all have a similar pattern, which is the inherent nature of the MVC design pattern. So I decided to take advantage of this with Authlogic. Any specific framework implementation is extracted out into an adapter. Similar to how ActiveRecord has an adapter for each database type, except the Authlogic adapters are much simpler.

Probably the main reason these adapters are so simple / similar is because of Rack. Thanks to Rack, there is a request standard across all of these frameworks. “But Ben, why not skip all of this nonsense and implement this right into Rack?”. The reason I didn’t go right into Rack is…

1. Not every “Rack compatible” framework uses the Rack libraries. After digging through the rails internals I found that the RackRequest class extends AbstractRequest, which has nothing to do with Rack. Lastly, older versions of rails aren’t rack compatible.
2. I need to hook into the controller anyways with a before_filter
3. With my implementation you get the best of both worlds. I designed the AbstractAdapter to conform to the rack standards, and any framework specific implementation can subclass this and do it’s magic.

So what’s the big picture here? The big picture is that there is no reason Authlogic can’t be an authentication solution for virtually any ruby framework out there. Why reinvent the wheel for every framework?

What about framework X?

Since writing adapters for rails and merb was so simple, why not keep going? Here are a few frameworks I plan to write an adapter for:

1. Mack
2. Ramaze
3. Sinatra

If you are feeling generous and want to write an adapter for a framework other than rails or merb, please do so. Let me know about it and I will add it into the source.

Final thoughts

Authlogic loves you regardless of your framework

What if you could have authentication up and running in minutes without having to run a generator? All because it’s simple, like everything else in rails.

What if creating a user session could be as simple as…

UserSession.create(params[:user])

What if your user sessions controller could look just like your other controllers…

class UserSessionsController < ApplicationController
  def new
    @user_session = UserSession.new
  end

  def create
    @user_session = UserSession.new(params[:user_session])
    if @user_session.create
      redirect_to account_url
    else
      render :action => :new
    end
  end

  def destroy
    current_user_session.destroy
  end
end

Look familiar? If you didn’t know any better, you would think UserSession was an ActiveRecord model. I think that’s pretty cool. Why is that cool? Because it fits nicely into the RESTful development pattern and its a style we all know and love. Wouldn’t this be cool too…

<%= error_messages_for "user_session" %>
<% form_for @user_session do |f| %>
  <%= f.label :login %><br />
  <%= f.text_field :login %><br />
  <br />
  <%= f.label :password %><br />
  <%= f.password_field :password %><br />
  <br />
  <%= f.submit "Login" %>
<% end %>

Or what about persisting the session…

class ApplicationController
  helper_method :current_user_session, :current_user

  protected
    def current_user_session
      return @current_user_session if defined?(@current_user_session)
      @current_user_session = UserSession.find
    end

    def current_user
      return @current_user if defined?(@current_user)
      @current_user = current_user_session && current_user_session.user
    end
end

Authlogic makes this a reality.

Reclaim your UsersController

This is one of my favorite features that I think its pretty cool. It’s things like this that make a library great and let you know you are on the right track.

Just to clear up any confusion, Authlogic does not store the plain id in the session. It stores a token. This token changes with the password, this way stale sessions can not be persisted.

That being said..What if a user changes their password? You have to re-log them in with the new password, recreate the session, etc, pain in the ass. Or what if a user creates a new user account? You have to do the same thing. Here’s an even better one: what if a user is in the admin area and changes his own password? There might even be another place passwords can change. It shouldn’t matter, your code should be written in a way where you don’t have to remember to do this.

Instead of updating sessions all over the place, doesn’t it make sense to do this at a lower level? Like the User model? You’re saying “but Ben, models can’t mess around with sessions and cookies”. True…but Authlogic can, and you can access Authlogic just like a model. I know in most situations it’s not good practice to do this but I view this in the same class as sweepers, and feel like it actually is good practice here. User sessions are directly tied to users, they should be connected on the model level.

Fear not, because the acts_as_authentic method you call in your model takes care of this for you, by adding an after_create and after_update callback to automatically keep the session up to date. You don’t have to worry about it anymore. Don’t even think about it. Let your UsersController deal with users, not users AND sessions. ANYTIME the user changes his password in ANY way, his session will be updated.

Here is basically what is done…

class User < ActiveRecord::Base
  after_save :maintain_sessions!

  private
    def create_sessions!
      # create a new UserSession if they are not logged in
    end

    def maintain_sessions!
      # If we aren't logged in at all and the password was changed, go ahead and log the user in
      # If we are logged in and the password has change, update the sessions
    end
end

Obviously there is a little more to it than this, but hopefully this clarifies any confusion.

When things come together like this I think its a sign that you are doing something right. Put that in your pipe and smoke it!

Authlogic arouses me

That’s great, here are some resources:

• Repository: http://github.com/binarylogic/authlogic
• Documentation: http://authlogic.rubyforge.org/
• Tutorial: coming soon…