2

I'm weighing the pros and cons of using "Authentication from Scratch" (as implemented in this Railscast) vs. using Devise.

I'm using a custom datastore, so using Devise isn't as simple as just following the README. It would require writing a custom ORM adaptor, which is far from trivial.

Given all this, the Railscast Auth from scratch seems much easier to implement.

So how secure is it?

Update: I should have pointed out that I'm using Parse.com as my datastore. This means they take care of hashing passwords and constraining uniqueness of usernames.

Community
  • 1
  • 1
user94154
  • 16,176
  • 20
  • 77
  • 116
  • Are you using Rails 3.1? If so, it's even easier: http://railscasts.com/episodes/270-authentication-in-rails-3-1. I find it difficult to answer your question about how secure it is. What kind of answer do you expect? – Mischa Dec 22 '11 at 01:08
  • I'm not sure what kind of answer to expect. This is one of those "unknown unknowns" type of questions. – user94154 Dec 22 '11 at 01:56

2 Answers2

5

They both work by using bcrypt to generate a salted hash of the password, the only difference is that devise (by default) uses a higher cost for the hash (i.e. it would take more cpu cycles to brute force it), but of course you could easily add that to the railscast code, so roughly equivalent in that respect.

The railscast version does seem to be vulnerable to timing attacks as just doing == won't give you a constant time compare operation. In a nutshell a timing attack works because a password where the hash was completely wrong would take less time for == to reject than a password where first half of the bytes were correct (and so == had to consider more bytes before bailing). It may seem that any such difference would be erased by noise from variations in network latency and so on but people have mounted real attacks to recover keys using these approaches.

You could obviously borrow the secure compare bit from devise though, but it does go to show that there are non obvious issues involved.

Obviously devise gives you a lot more than just authentication!

Frederick Cheung
  • 83,189
  • 8
  • 152
  • 174
  • 2
    Quick q about the timing attack you've described here... as I understand it, timing attacks require you to to be able to iterate on the compared input, so if you get the first n chars right, you should be able to modify just the n+1th char to make a subsequent guess. Maybe I'm missing something but how would that work here? If the password is being hashed (using *any* hashing algo) you can't simply modify the n+1th char to iterate on the attack. Doing so would net you a totally new hash. Since you're not comparing the attacker-controlled input, I'm not sure how the timing attack would work. – Ali Aug 23 '13 at 11:04
  • Perhaps it wouldn't, not sure to be honest. – Frederick Cheung Aug 23 '13 at 12:46
  • But you may well be right - could be an overreaction on my part – Frederick Cheung Aug 23 '13 at 13:19
2

That screencast uses the bcrypt-ruby library, which is a Ruby implementation of bcrypt, which is based on the Blowfish cipher. The benefit of bcrypt is that it's computationally expensive to crack a password generated by this system, and that the cost of generating these passwords can be increased as required in order to make it more secure, at the expense of the computation time it would take to generate time.

For more information, check out the BCrypt::Password RDoc.

Ryan Bigg
  • 106,965
  • 23
  • 235
  • 261