Handmade Rails Authentication
kswope.wordpress.com
kswope.wordpress.com
Still, always good to see how others approach authentication code (personally, I use Clearance).
It's the same issue I have with RSpec, actually. Too much code.
Now, authorization is a radically different story; unfortunately, though, there's no good Rails solution for getting "off-the-shelf" access control and permissioning, so you may be kind of stuck anyways.
(Pet peeve of mine? Mixing up authorization and authentication.)
For anyone that's confused:
Authentication: Is the user who they are they are?
Authorization: Is the user allowed to do this?
Try this: http://www.google.com/search?q=bcrypt+tptacek+site%3Anews.yc...
Find all his warnings, and don't make any of the mistakes he mentions, and I'll bet you will be fine.
* The session token you come up with will be insecure, like PHP's have been as recently as (I think?) this year
* That you'll end up reinventing session fixation vulnerabilities
* That you'll screw up session timeouts and logouts and succumb to "permanent" session hijacking flaws
* That you'll try to encode encrypted information into the session cookie itself, rather than just an opaque random token, and open that whole kettle of worms.
I'm not interesting in changing the world of password hashing with my trivial rails plugin by using anything other than the most secure of the common hashing algorithms, SHA2. I'm also under the impression that SHA2 is now the most widely recommended security hash.
None of that has anything to do with the security that SHA256 provides to your application. SHA256 knows how to take care of itself. It doesn't know a damn thing about passwords. SHA256 isn't a secure password hash.
You already know that, because you're not just using SHA256; you're also adding a random salt to it. That's because if you didn't do that, attackers could just aim a precomputed dictionary at your database rows and smite it. So your hash isn't SHA256; it's a construction called "salted SHA256" (or "SHA256 with a nonce").
Nonced SHA256 still sucks, though, because SHA256 is lightning fast. Attackers can't throw precomputed dictionaries at your password hash, because you randomized them. But they can take each hash in turn and run a large dictionary against each hash. This is a brute force attack, but it's not a brute force against the 256 bits of the hash; it's an attack against the (low) entropy of the passwords themselves.
This is how all password cracking got done in the '90s, which was a bit of a golden age for password cracking. It's how John the Ripper (the most famous password cracker) works. John the Ripper is extraordinarily fast against Unix password hashes, which are slower (by a lot) than SHA256. Incremental crackers tear through naked SHA256 hashes like a knife through butter.
That you don't know any of this --- and I say this respectfully --- tells me that maybe you should be using someone else's password hashing library instead of reinventing your own. But you're welcome anyways for the quick and dirty lesson in password hashing.
(Please correct any of this if I'm wrong. IANACryptographer.)
Use a password hiding method that's slow to compute (slow being "this operation isn't implemented in hardware or optimized assembly") which is what bcrypt or scrypt provides.
Differences in speed/effort are mentioned at http://www.tarsnap.com/scrypt.html -- scrypt enc is approximately 100 billion times more than the cost of cracking the same password on a file encrypted by openssl enc
The slowness of an algorithm like bcrypt is a tunable property of the key expansion algorithm. A step in this process will be repeated 2^n times, where n can be configured by the user.
If a password function was only slow because it wasn't implemented in assembly on your server, an attacker would obviously just go implement it in assembly for his brute-force crack.
So because I haven't yet offered other hashing algorithm options yet, since this plugin is about a week old and nobody has used it, and nobody has requested options, I have no right to be offering this solution for public use and scrutiny?
Looks like authlogic uses sha512 by default and clearance and devise use SHA1 by default. If these are their defaults, as you would say, I say this respectfully, maybe those guys should be using somebody else's password hashing library.
Also, could I not continue using SHA2 256, and add an option to specify the number of hashing repetitions, which would increase the time to compute, as well as frustrate dictionary attacks?
The best practice in password hashing schemes is well understood by the security community, so you have to understand that it can be frustrating to watch the same mistakes made over and over again.
As tptacek pointed out, the correct answer is "use bcrypt". He's not telling you not to offer your library for public use, he's just pointing out that there is absolutely no reason to roll your own password hashing scheme.
"Also, could I not continue using SHA2 256, and add an option to specify the number of hashing repetitions, which would increase the time to compute, as well as frustrate dictionary attacks?"
Are you sure there is no inherent property of SHA256 that would allow an attacker to shortcut the computation of successive hashes? I'm not saying there is, but simply that cryptographers have already solved this problem and considered all the angles. Why are you trying to start from scratch?
I also wondered if there was an characteristic to sha256 that would make repeating it pointless. I did see it mentioned someplace however, thats why I asked.
Oh and he is pointing out I shouldn't be doing this, and this somehow comes off as arrogant, especially considering a few of the other plugins default to SHA1
"That you don't know any of this --- and I say this respectfully --- tells me that maybe you should be using someone else's password hashing library instead of reinventing your own"
The rest of your library is the part you want to spend your effort on. Make it easy to use, make it flexible, put in some great features like a user admin panel. That stuff is the domain of the webapp library builder. Just trust the crypto part to the cryptographers, and use bcrypt/scrypt.
auto_hash is just a plugin that wraps a call to ruby's Digest library in a convenient rails plugin, the entire "crypto" part are these two lines:
salt = ActiveSupport::SecureRandom.hex(10)
Digest::SHA2.new.update(value + salt).to_s
Which is was I was absolutely baffled by comments such as "auto_hash is an inferior password hash" and "tells me that maybe you should be using someone else's password hashing library instead of reinventing your own"
Looks suspiciously like most of the criticism was from those who didn't give more than a glance to the plugin before criticizing it. Maybe the name auto_hash was confusing some people, thinking it was a hashing algorithm rather than just a silly little rails plugin.
Again, the core of your misunderstanding here is your belief that SHA256 is a security function. It isn't.
Also, you believe you're simply using SHA256. You're not. You're using SHA256(nonce, password), which is a construction, not an algorithm.
There's nothing wrong with constructions; every security protocol uses them. But you need to recognize the merits and problems with the construction you've ended up using. Your construction is terribly vulnerable to incremental brute force cracking. There are much better constructions that don't have this problem; scrypt and bcrypt are among them. There's also PBKDF2 and "stretched" SHA256.
But, and this will annoy you to hear: security-critical code isn't something you should "learn on the job". Take someone else's secure system (in Ruby, use ruby-bcrypt, which is excellent) and build on that instead.
But its baffling that you are saying this is not something I should "learn on the job", since I'm doing exactly what the other alternative libraries are doing, except a few offer more configuration. Authlogic, Clearance and Devise all are doing what I'm doing, some a little better, by offering bcrypt, some much worse, by defaulting to SHA1. I hope that, although it looks like you are singling out my humble plugin for criticism, you are actually criticizing most existing plugins. If you want to do that, its your call, but I'm just offering an alternative.
In fact I was going to use bcrypt, but I discovered that it require some installation to use, and I didn't want to make a simple plugin more complicated. Why did I think this was ok? Because, as I mentioned before, I did a little digging and found almost nothing warning about using sha2 for hashing passwords, so I assumed it was still considered good enough.
I really sounds like you are criticizing auto_hash as some poorly attempted one way hashing function but its only a plugin with a single line, that does anything crypto.
Digest::SHA2.new.update(value + salt)
BCrypt::Password.create(value + salt)
AMENDMENT: Not a simple 1 line drop in, but I'm getting there :)
Thanks to everybody voting me down for no reason I can see.
The fact that the mistake you made is only one line of code has nothing to do with anything. A single-line coding error (blindly offsetting malloc's return) broke all of Flash. Every line counts.
If that sucks and feels unfair, I agree with you. You can mitigate this problem by not writing security code.
His point: His plugin is a wrapper that provides a basic framework for handling authentication. He's not implementing his own cryptography. He happens to use an SHA256 construction as part of it because that's what he's seen as one of the standard ways of handling passwords.
Your point: Don't use salted SHA256 for passwords. Use bcrypt.
I think this whole conversation could have been snipped off if you had started with "change auto_hash to use bcrypt instead of SHA256 since it's more secure".
Just be aware that once he replaces auto_hash with bcrypt, auto_hash has literally no functionality anymore; bcrypt-ruby already does all of what auto_hash does, better.
But its not true it wont have any functionality, it does what it claims to do, which isn't much, but its something.
Putting
auto_hash :password, :field2, :field3
Then it will give you a dynamic accessors like user.password_match?, user.field2_match?
This saves lines of ugly code I don't want to look it, and also frees up the models before_save hook.
Amendment: I think this will make auto_hash the only auth related plugin that defaults to, and only offers, bcrypt
Here is bcrypt-ruby
class User < ActiveRecord::Base
include BCrypt
def password
@password ||= Password.new(password_hash)
end
def password=(new_password)
@password = Password.create(new_password)
self.password_hash = @password
end
end
class User < ActiveRecord::Base
auto_hash :password
end