My first Rails complaint: What, no authentication?
Okay, it’s time for my first gripe about Ruby.
There’s no built-in authentication system.
There’s built-in everything else, but when it comes to authentication, for some reason we’re left to the mercy of generators/plugins/engines/etc., all of which are written by people with very limited experience with cryptography.
MD5? SHA-1? Seriously? Are people still writing new applications using these algorithms? Are people still writing applications based on hash algorithms without building in any algorithm agility? Sweet mother of God, why?
I’m supposed to not only take seriously but also use the product of someone who spells it “cypher?” (Quick tip, kids: Cypher is the weasely guy from the Matrix moves. Cipher is the cryptographic thingy.) Oh Lord take me now.
The best I’ve found so far is Bruce Peren’s ModelSecurity, which is really, really ugly. Butt-ugly. So ugly you’d pronounce it “yoo-gly.”
For anyone listening, here are crucial points to consider when designing an authentication system.
- Do not use MD5 or SHA-1. These are seriously flawed algorithms, so much so that it’s putting that entire family of algorithms in doubt. MD5 was considered broken last year, and SHA-1 looks just as bad. Bottom line?
Don’t make Bruce Schneier come kick your ass.
- Salts are best used on a per-entry basis. If you’re going to use a random salt to store a user’s password with (e.g.
hash(salt + password)), you might as well go the extra five minutes and do it on a per-user basis, not a per-site basis. The whole point is to increase the computational cost of a rainbow table/offline bruce force attack, not fudge the hash function it uses a little bit. - Keep it simple, jackass. Don’t make it the all-singing, all-dancing spaz-mo-tronic wonderblunderbubblebuggy. Remember why you like Rails: it provides you with meaningful defaults. It doesn’t do everything for you.
I’m going to have to implement my own, aren’t I?
June 13th, 2006 at 9:32pm
I know exactly what you mean. I can recall wanting to use a generator to do authentication and having to deal with localization. When I want to localize my application I’ll do so, thankyouverymuch.
September 14th, 2006 at 4:42pm
Ey. There are known collision attacks on SHA-1. That’s not the same game as reversing the hmac. Stoopid.
September 14th, 2006 at 4:56pm
Cypher–Do attacks get better or worse over time? What is the additional cost of using SHA2? Is using SHA2 recommended by a majority of the cryptographic field? Yes, nothing (in the context of web applications), and yes. More bluntly, if the integrity of your cryptographic primitives are not an issue to you, then why not stick with CRC32?
September 14th, 2006 at 5:21pm
Coda, it’s XOR for me. Ok, seriously CRC like DES is easily cracked today. SHA-1 isn’t. Always using the latest isn’t the solution. Be sure to check the intended application first.Well it’s possible to compute a collision for SHA-1 but that 10k+ chunk of bits won’t fit in any password field then.
Sorry, but basicly you sound like those “gosh you still use 128bit AES, I have 1024bit PGP” people.
September 14th, 2006 at 5:37pm
I’ll ask it again: what is the additional cost of using SHA2? I’m really failing to see why we shouldn’t tell people to avoid hash functions with known, public, and major flaws. This isn’t a “omfg sky falling!one!21!one” situation, but rather a calm suggestion: MD5 and SHA-1 are done, if you’re building a new system, move along. This is practically consensus now.
If I really wanted to get people on the bleeding edge, I’d advise them to use Whirlpool. But that’s too much risk, and Whirlpool hasn’t seen as much full, concerted analysis as SHA2.
Also, I’m not worried about online attacks, I’m worried about disclosure of sensitive financial information during an insider/offline attack.
November 19th, 2006 at 1:01pm
Hi Coda,
I am totally agreed with you… I have also came through the same that “attacks have been found on SHA-1″.
In my last project on rails — a loan management application which holds some crucial data and supposed to be secure enough, we decided to go for SHA-2(precisely SHA-256) for the encryptions whole through the application. We even have encrypted the passwords on client side by Javascript Encryptions… so that making it less probable that a raw data can even reach the server.