I doubt that. They're led by probably the strongest Rails team anywhere, and they (DHH + team) wrote books on avoiding what RockYou just did.
EDIT: I'm specifically referring to DHH's "Agile Web Development With Rails", Chapter 11, Administration
EDIT: I'm specifically referring to DHH's "Agile Web Development With Rails", Chapter 11, Administration
We've covered 37signals poor approach to security before: http://news.ycombinator.com/item?id=804257
It's my understanding that they've since reformed.
I'd be interested in what books you think they've written that provide credible security advice. Blind "fanboyism" (if I may invent a word) is a bad thing.
def self.encrypted_password(password, salt)
string_to_hash = password + "wibble" + salt # 'wibble' makes it harder to guess
Digest::SHA1.hexdigest(string_to_hash)
end
EDIT: tptacek makes a good point. I haven't quite been fair. 37signals did what most companies never do when confronted with a security issue: they quickly acknowledged the problem, fixed it based on the suggestions of the security researchers, and moved on.
From what I understand however, AWDWR is only tangentially related to 37signals.
And, like I say every time this comes up, FedEx and several banks also store plaintext passwords.
37signals no longer stores easily attacked passwords.
I was intellectually honest. I explicitly said they didn't actually lose them.
37signals no longer stores easily attacked passwords.
I was under the impression that this was true as well. However I just checked and I got my Backpack password emailed to me in plain text. So at least the Backpack application is still incorrect.
The "honesty" comment wasn't directed to you, but it's obvious why you would think it was. Sorry.
Given your history of quality and logical posts, I pretty much knew the comment wasn't directed towards me. I just wanted to go on record to be sure. I'm sorry as well, I should have just let it fly.
Either they haven't gotten to you in the rollout yet, or they aren't doing Backpack (which would surprise me).
They're launching unified accounts soon for all services (you have to pick a new user name and password if I remember correctly). Perhaps this is when they'll roll out the password security? Seems like a logical time to me.
(NB: I'm friendly with several 37s people online, and I've talked to them about what they're doing, and while I'll leave it to them to talk up their security, I think they're OK on this issue now).
[ignore] The second link is about a security problem in ruby on rails. Unfortunately ruby doesn't have proper utf-8 support so ruby on rails needs to monkey-patch the ruby string classes to provide proper support. It is unsurprising that there was a bug in this patching. This is a framework issue that has nothing to do with 37signal's security practices. Hindsight is 20/20. Frameworks always end up with security issues. At least you can see that it's been fixed for some time.
Okay, issue was with the lack of a secure channel. Point taken. That was a mistake.
[Removed section on procedures and mistakes, as non-relavent.]
(Disclosure: I use ruby on rails)
Using symmetric encryption to encrypt passwords in a database would not be smart. Where are you going to keep the key? If the hacker gets the dbase, then they've probably got the key as well.
There's no point in dancing around this issue. The only acceptable way to store passwords is a slow one way hash. If you get your password in plaintext, the security is lax.
The second link is about a security problem in ruby on rails. Unfortunately ruby doesn't have proper utf-8 support so ruby on rails needs to monkey-patch the ruby string classes to provide proper support. It is unsurprising that there was a bug in this patching. This is a framework issue that has nothing to do with 37signal's security practices. Hindsight is 20/20. Frameworks always end up with security issues. At least you can see that it's been fixed for some time.
The bad part about the second link isn't that the vulnerability happened, its that 37signals had no infrastructure in place for security researchers to report problems. Of course vulnerabilities are going to happen. It's a certainty. But you need to have a system in place for the good guys to report problems. I'm not aware of any informed person that criticized them for the actual vulnerability. If you read the link I provided, you'll notice this quote:
"It is literally the-simplest-thing-not-to-fuck-up. Nobody's asking you not to have security vulnerabilities. In fact: nobody's even asking you to fix vulnerabilities. We just need a reliable way to communicate with you about them."
They've got a communication channel now: http://37signals.com/security-response.
So, is there any less sensitivity (security-wise) regarding the key, instead of the password?
It's also possible for the encrypted passwords to be stored in a separate server that only provides a simple web service with two operations: update_password(email, password), mail_password(email) and store passwords hashed in the main database for authentication.
That said, it is far more dangerous to store passwords in a reversible manner than in an irreversible one. I was just noting it was possible to have modestly secure two-way storage.
Personally, I don't even want to deal with storing user passwords so I prefer using OpenID.
(b) Independent of all the other flaws that will get you arbitrary file read, if you don't know what the cases are where SQLI gets you arbitrary file read, you're probably not qualified to design your own password storage. I really mean that with all due respect.
I don't ever intend to get into the area of writing my own password storage until I learn a lot more in the area of security. I am only aware of how little I don't know about what I don't know.
CREATE TABLE foo ( x TEXT );
LOAD DATA INFILE "/etc/whatever" INTO TABLE foo ;
SELECT x FROM foo;