An Excuse Not to Roll Your Own Authentication Scheme
has_secure_password: Dead-simple BCrypt-based passwords. Now there’s no excuse not to roll your own authentication scheme.
I will briefly provide an excuse.
"Simple BCrypt-based passwords" is a reasonable feature, but shouldn't be mistaken for end-to-end authentication, or even a substantial subset of that problem. Web site authentication in the real world is a far harder problem than salting and hashing a password -- which BCrypt does OK, as far as I know. You can prove this to yourself merely by observing that many frameworks which have correctly implemented salting and hashing have nonetheless had their authentication systems compromised by other means.
Having (correctly) validated a username and password, most web authentication frameworks use an encrypted authentication token stored in a cookie (or some other place) for future requests. This way the client (the browser) doesn't need to remember the password or repeatedly prompt the user for it. However, once the token has been issued, having a copy of it is as good as having the password (for a short period of time, anyway -- they typically expire). That's how tools like Firesheep work on un-secured networks. If you produce or handle this token incorrectly then may as well not bother doing username and password authentication in the first place!
Remember last year when the ASP.NET membership provider used in large numbers of ASP.NET sites was discovered to be vulnerable to a padding oracle attack? ASP.NET, as far as anyone knows, is salting and hashing its passwords correctly. But that's not enough to stop people from breaking into the system. The other links in the "security chain" have to be secure as well. In the case of ASP.NET, the server leaked information which was useful when attempting to break the encryption of the authentication token. This is sometimes called a side channel. Having succeeded in breaking the encryption, a client could then create a "fake" authentication token which the server would mistake for one it had issued itself. Hence, it was possible to break into a site without ever knowing the password. The authors of this exploit had formerly found similar vulnerabilities in JSF and other frameworks.
All of this adds up to old news: Security is hard. Even experts in the field make mistakes that other experts in the field overlook for years. Anyone can build a system which they themselves can't break into. The best solution for developers of sites not specifically intended to prototype new and potentially vulnerable security systems is to use proven, off-the-shelf authentication systems, and to instead put their efforts into delivering value to their end users!
Comments
-
Thursday, 26 May 2011I disagree - the fact that even the professionals can't get it right means that whatever "off the shelf" system you choose, your protection is gone once someone figures out how to break that system.
They won't necessarily be doing so specifically to get into your site or service. But if there is some more appealing or attractive site that gains a miscreants interest, they get your site hacked for free once they have hacked the site they are actually interested in.
Even if they aren't interested in breaking (or breaking into) your site, in the circles that such people circulate there may be someone who is, and once a system is broken the details of how to identify the sites using that system (I imagine off-the-shelf security systems are typically very easily identified) and how to violate them will be distributed quite quickly I imagine.
I think you are right in saying that delivering useful functionality should be the focus, not developing your own idea of a bulletproof security system. Depending on the nature of the information you are protecting, there may be other reasons for using an off-the-shelf solution, or for not even bothering with security in the first place.
If you need liability cover, then an off-the-shelf system which comes with it's own guarantees and indemnities is obviously attractive.
If the data involved is not especially sensitive however, then a home grown system with some unique idiosyncracies, on a site for which there will be little interest in hacking is going to be more than good enough I'd say.
It doesn't need to be complex and doesn't need to be bullet proof.
Some might call it "Security through Obscurity", a phrase usually uttered with a dismissive sneer, but which misses the point - that it is still "security".
Just imho, ymmv.
-
Thursday, 26 May 2011
Well IMHO it comes down in technical terms to "your own scheme" being weak against targeted attacks, and "off-the-shelf schemes" being weak against automated attacks.
And in terms of the blame game, "off-the-shelf" means you can't be blamed when your site comes down alongside a few thousand others, while "your own scheme" means you'll be in trouble if someone decides to pull a Sony on you. -
Tuesday, 7 June 2011
this post describes the very important issue that we should focus on the protection because the authentication is very necessary for the applications and I think you are right in saying that delivering useful functionality Depending on the nature of the information you are protecting, we should not bothering with security in the first place.
-
Please login first in order for you to submit comments
- Page :
- 1
Salting and hashing by themselves aren't even enough. What BCrypt does is adds a computational load to the password verification problem. A big pile of salted passwords hashed with MD5 isn't secure, because a password dictionary can similarly be salted and hashed cheaply to create a rainbow table specific to the salt employed, compromising some fraction of the accounts. Making the calculation of the hash of a password take a non-trivial amount of CPU time helps secure against this large-scale attack.