Introducing Authgasm: "Rails authentication done right".(binarylogic.com)
binarylogic.com
Introducing Authgasm: "Rails authentication done right".
http://www.binarylogic.com/2008/10/25/authgasm-released-rails-authentication-done-right
25 comments
Sigh. Just what we needed; another authentication plugin... that uses crackable salted SHA256 to store web passwords. Of course, it provides a plugin interface --- including, inexplicably, support for symmetrically (ie, recoverably) encrypting passwords. What it doesn't do is support bcrypt-ruby, which is the only correct answer to this problem.
You would know better than me and almost certainly keep more in tune with the cutting edge on this but how easy is it exactly to crack a salted SHA256 password?
You want your authentication hash to be slow. Password tests are never in your 80/20 performance hot spot. The faster a single password test is, the faster it is to run an entire dictionary through that test function looking for a matching hash.
SHA256 is slower than SHA1, which is slower than MD5. But in the grand scheme of things, SHA256 is fast. It's designed to be fast --- fast enough to run on a per-packet basis in secure network protocols.
Bcrypt is designed to be slow. So is "stretched" SHA256, which is simply SHA256 iterated thousands of times. Both these schemes are much harder to crack than simply hashing a password with SHA256.
The trouble I have here is that authentication is one part of your application you don't want to mess around with, but already someone here said "I'm going to try this just because the name is awesome". Forget the cosmetics. There's only one right answer to this problem.
SHA256 is slower than SHA1, which is slower than MD5. But in the grand scheme of things, SHA256 is fast. It's designed to be fast --- fast enough to run on a per-packet basis in secure network protocols.
Bcrypt is designed to be slow. So is "stretched" SHA256, which is simply SHA256 iterated thousands of times. Both these schemes are much harder to crack than simply hashing a password with SHA256.
The trouble I have here is that authentication is one part of your application you don't want to mess around with, but already someone here said "I'm going to try this just because the name is awesome". Forget the cosmetics. There's only one right answer to this problem.
I did a bit of looking into bcrypt-ruby after hearing about it here. It sounds good, I like the idea of the "cost" attribute.
However, I note that Coda Hale appears to have no interest in supporting his bcrypt-ruby gem for Windows. On his blog he says essentially that he doesn't use Windows and hence has no motivation to put any time into getting a pre-compiled bcrypt-ruby to work on Windows.
I can totally understand where he's coming from and as I do all my dev work on Debian Linux, it's not a problem for me personally. But my partner is a Windows user and it would be a problem for him.
The closest I have found to instructions on getting bcrypt-ruby compiled on Windows are from the bcrypt-ruby README:
You‘ll need a working compiler. (Win32 folks should use Cygwin or um, something else.)
So does this mean that my partner would then have to use the Cygwin environment for all his dev work from this point on?
And a random comment from Coda Hale's blog:
bcrypt seems to work with the Windows One-Click-Installer too. It was easy to compile it with MinGW (I just had to define the missing types u_int8_t, u_int16_t, and u_int32_t). All your tests pass. So you might consider to offer a precompiled version for us Windows users.
I am not a C programmer (getting more experience with a compiled language is on my todo list, just no time as yet) nor am I a security expert. My past experience with compiling stuff basically extends to typing "make" and "make install". I don't really understand what "I just had to define the missing types u_int8_t, u_int16_t, and u_int32_t" means.
So as much as I would like to try and incorporate bcrypt-ruby into my current Rails project, I can't really justify this added overhead of getting it to work on my partners Windows dev box with near zero support.
If anyone has more info, that would be great. But otherwise, I will - for now - be sticking with salted SHA256.
However, I note that Coda Hale appears to have no interest in supporting his bcrypt-ruby gem for Windows. On his blog he says essentially that he doesn't use Windows and hence has no motivation to put any time into getting a pre-compiled bcrypt-ruby to work on Windows.
I can totally understand where he's coming from and as I do all my dev work on Debian Linux, it's not a problem for me personally. But my partner is a Windows user and it would be a problem for him.
The closest I have found to instructions on getting bcrypt-ruby compiled on Windows are from the bcrypt-ruby README:
You‘ll need a working compiler. (Win32 folks should use Cygwin or um, something else.)
So does this mean that my partner would then have to use the Cygwin environment for all his dev work from this point on?
And a random comment from Coda Hale's blog:
bcrypt seems to work with the Windows One-Click-Installer too. It was easy to compile it with MinGW (I just had to define the missing types u_int8_t, u_int16_t, and u_int32_t). All your tests pass. So you might consider to offer a precompiled version for us Windows users.
I am not a C programmer (getting more experience with a compiled language is on my todo list, just no time as yet) nor am I a security expert. My past experience with compiling stuff basically extends to typing "make" and "make install". I don't really understand what "I just had to define the missing types u_int8_t, u_int16_t, and u_int32_t" means.
So as much as I would like to try and incorporate bcrypt-ruby into my current Rails project, I can't really justify this added overhead of getting it to work on my partners Windows dev box with near zero support.
If anyone has more info, that would be great. But otherwise, I will - for now - be sticking with salted SHA256.
I am the creator of this plugin.
Who cares about the name. I wanted something unique that would get people's attention and return unique content when searching. I also thought it was funny. People need to lighten up a little bit if the name bothers them. It's not like I put the name "authgasm" in helpers that you have to use all over your application. It sits in your plugin dir, that's all.
Anyways, regarding encryption. You can encrypt the password any way you want. Use bcrypt-ruby if you want. It would take no time at all to set up. Checkout the acts_as_authentic documentation. You can provide your own "crypto provider" and have it do whatever you want.
Lastly, I don't use Sha256 straight up. I add in salt. So reverse lookups are out of the question. Your last option is brute force. There is no encryption / hashing algorithm that is safe from brute force. Granted some might slow it down more than others, all that is doing is setting up more hurdles to jump, not 100% secure.
But I really like bcrypt, I'll look into it and maybe switch it to the default crypto provider. But, I really think for anything that is not being used in the NSA, Sha256 + salt would work just fine.
Who cares about the name. I wanted something unique that would get people's attention and return unique content when searching. I also thought it was funny. People need to lighten up a little bit if the name bothers them. It's not like I put the name "authgasm" in helpers that you have to use all over your application. It sits in your plugin dir, that's all.
Anyways, regarding encryption. You can encrypt the password any way you want. Use bcrypt-ruby if you want. It would take no time at all to set up. Checkout the acts_as_authentic documentation. You can provide your own "crypto provider" and have it do whatever you want.
Lastly, I don't use Sha256 straight up. I add in salt. So reverse lookups are out of the question. Your last option is brute force. There is no encryption / hashing algorithm that is safe from brute force. Granted some might slow it down more than others, all that is doing is setting up more hurdles to jump, not 100% secure.
But I really like bcrypt, I'll look into it and maybe switch it to the default crypto provider. But, I really think for anything that is not being used in the NSA, Sha256 + salt would work just fine.
I agree on all points. I like the name of your plugin(s).
The main issue I have with bcrypt-ruby as I said is that there is basically no Windows support for it that I can find. I know that most of us who develop with Ruby/Rails use a Mac or Linux/Unix but there are some, like my business partner, who still use Windows as their development environment. For a Rails plugin or Ruby gem, I think it would be really nice if at least some effort was made to keep it more easily cross-platform compatible for those of us who are not C coders.
But, I really think for anything that is not being used in the NSA, Sha256 + salt would work just fine.
As I said, I'm no security expert, but the reading I have done would lead me to agree with you. It's all about degrees of security with the trade-off always being more security means less convenience for someone, be it the developer or the end user. I've weighed the security/convenience issue for me at this point in time, and I'm sticking with salted SHA256.
The main issue I have with bcrypt-ruby as I said is that there is basically no Windows support for it that I can find. I know that most of us who develop with Ruby/Rails use a Mac or Linux/Unix but there are some, like my business partner, who still use Windows as their development environment. For a Rails plugin or Ruby gem, I think it would be really nice if at least some effort was made to keep it more easily cross-platform compatible for those of us who are not C coders.
But, I really think for anything that is not being used in the NSA, Sha256 + salt would work just fine.
As I said, I'm no security expert, but the reading I have done would lead me to agree with you. It's all about degrees of security with the trade-off always being more security means less convenience for someone, be it the developer or the end user. I've weighed the security/convenience issue for me at this point in time, and I'm sticking with salted SHA256.
The trade-off is indeed the security of your users versus the convenience of your developers.
That said, I don't so much care whether you store your passwords with a demonstrably inferior scheme like Authgasm's default or the 1-line-delta variant of it that resolves its biggest problem. It's fine to be ignorant about this stuff; it's not going to make you 1 extra dollar to do it right.
Just don't be militant about your ignorance.
That said, I don't so much care whether you store your passwords with a demonstrably inferior scheme like Authgasm's default or the 1-line-delta variant of it that resolves its biggest problem. It's fine to be ignorant about this stuff; it's not going to make you 1 extra dollar to do it right.
Just don't be militant about your ignorance.
Just for the record, I'm not using Authgasm, not because I have any problem with it, I just chose to write the login stuff for my current project myself for various reasons I won't go into and had done so long before I came across this post.
I don't think I'm being militant about anything... Just carrying on what was a reasonably pleasant and honest conversation. Yes, part of my decision was to do with that my partner is a Window's user and I can't do anything about this at the moment. But the other part of the calculation that you overlook is that my current project is not one that requires over the top, secret squirrel encryption on stored passwords. This consideration came into it as well.
You sound bitter, man. Maybe you should take a nap and stop being so militant yourself.
I don't think I'm being militant about anything... Just carrying on what was a reasonably pleasant and honest conversation. Yes, part of my decision was to do with that my partner is a Window's user and I can't do anything about this at the moment. But the other part of the calculation that you overlook is that my current project is not one that requires over the top, secret squirrel encryption on stored passwords. This consideration came into it as well.
You sound bitter, man. Maybe you should take a nap and stop being so militant yourself.
Why do you think your application doesn't require "over the top" encryption on stored passwords? Who are your users?
So what, I'm meant to reply with something like "Um, my users are people..." and then you say something like "Well people pick shit passwords..." and so on.
Did the SHA eat your babies or something? :P
Seriously though, probably "over the top" was not a good choice of term. In a perfect world, I agree with the unspoken point you're trying to lead me into, which seems to be that all applications should never compromise on their security regardless of convenience or who their users are etc. But surely you must agree that in the real world this isn't always viable. I don't have unlimited time at my disposal.
If my current situation allowed it, I would use bcrypt based solely on the fact that OpenBSD recommend it.
However, my current situation does not allow this. Therefore, I have made a pragmatic decision that will enable me to continue moving towards my goal. I'm not going to apologize to you or anyone else for this.
I appreciate that you are passionate about what I assume is your chosen field of expertise, but perhaps in the future you could try talking to people more so than down to them. You might just find it yields friendlier results.
Did the SHA eat your babies or something? :P
Seriously though, probably "over the top" was not a good choice of term. In a perfect world, I agree with the unspoken point you're trying to lead me into, which seems to be that all applications should never compromise on their security regardless of convenience or who their users are etc. But surely you must agree that in the real world this isn't always viable. I don't have unlimited time at my disposal.
If my current situation allowed it, I would use bcrypt based solely on the fact that OpenBSD recommend it.
However, my current situation does not allow this. Therefore, I have made a pragmatic decision that will enable me to continue moving towards my goal. I'm not going to apologize to you or anyone else for this.
I appreciate that you are passionate about what I assume is your chosen field of expertise, but perhaps in the future you could try talking to people more so than down to them. You might just find it yields friendlier results.
No, you've totally missed my point. I wanted to know, do you not have real users? Can arbitrary people not sign up for your application? Does it have a closed user base? Is it an enterprise product? Because, then, maybe password storage isn't an issue for you.
Otherwise, your users aren't simply giving you "shit passwords". They're giving you their bank password. Normal people do not make up 16 different passwords for all their web applications. If you take passwords from normal people on the Internet, and you ever get popular, you will come into possession of a large database of Bank of America credentials.
So yes, maybe you ought to consider being careful with them.
Otherwise, your users aren't simply giving you "shit passwords". They're giving you their bank password. Normal people do not make up 16 different passwords for all their web applications. If you take passwords from normal people on the Internet, and you ever get popular, you will come into possession of a large database of Bank of America credentials.
So yes, maybe you ought to consider being careful with them.
Doesn't using the same password everywhere (particularly if it's also your online banking password) qualify it as a "shit password" as I so eloquently put it? :)
In any case, I accept that there should be some degree of responsibility taken by the developer to try and protect their users information, lest we get the whole Reddit situation.
But as someone once said, you can't make the Internet idiot proof.
In any case, I accept that there should be some degree of responsibility taken by the developer to try and protect their users information, lest we get the whole Reddit situation.
But as someone once said, you can't make the Internet idiot proof.
"Salt" does nothing to address the primary way passwords have been cracked for the past 20 years, which is with incremental password crackers like Crack, L0phtcrack, and John the Ripper. Your comment about "anything not being used by the NSA" is silly, and misses the point entirely. Most Rails app users will entrust those apps with horribly bad passwords; bcrypt protects those passwords, and "salted SHA256" doesn't.
If you don't understand the problem you're trying to solve with this plugin, why are you promoting it?
If you don't understand the problem you're trying to solve with this plugin, why are you promoting it?
My comment about "anything not being used by the NSA" is not silly, it's true. Hell the NSA developed the Sha functions. I am not one to take security lightly, and salted Sha256 is not taking security lightly. I am not sure what kind of apps you write, but for 99% of the apps in the world, salted Sha256 is plenty secure. If it was as big of a problem as you said it would be highly discouraged, which it is not. The leading authentication solution in rails uses Sha1. Regardless, if you are extra paranoid, you can use any type of encryption you want with authgasm. So the argument is moot. Lastly, authgasm is not about promoting sha256, its about a style of authentication in rails. The method of encryption is just an option, which is what the crypto_provider option is all about. If you don't understand the subject which you are discussing, why are you discussing it?
I actually looked into bycrypt and it's great. But it would be silly of me to use a linux only encryption solution in a library available to the ruby public.
I actually looked into bycrypt and it's great. But it would be silly of me to use a linux only encryption solution in a library available to the ruby public.
Thanks, I'd not yet heard of bcrypt. But if the OpenBSD guys are down with it, then it must be worth a go. This stuff is why I come here. :)
could you use bcrypt instead of something like the
restful-authentication plugin ?
I would be very happy if they could move in some standard user authentication into rails. Tired of the stream of plugins that become abandonware in a couple of months.
Also, thanks to github, if a plugin is popular enough it never really gets abandoned. Look at the engines plugin. The author of that plugin rarely does anything to it, but people fork it and keep it up-to-date.
well most of the authentication plugins are only 100 lines of code or so. Even if the plugin author dies in a freak accident involving toothpicks, you should have no trouble maintaining the plugin yourself.
Are they all pretty much the same? Is there currently a reigning/most popular plugin floating around?
This discussion is moot since Authlogic easily supports BCrypt:
http://www.binarylogic.com/2008/11/22/storing-nuclear-launch...
http://www.binarylogic.com/2008/11/22/storing-nuclear-launch...
I really like the name. I may try it out just because of the name.
Authgasm.
Authgasm.
Awesome, you shouldn't even consider using a plugin / gem unless it has a good name. The same applies with books. Unless you like title / cover you shoudn't read it.