| HN Mirror

It happened (storing in plaintext, not losing the actual passwords): http://www.jgc.org/blog/2009/05/can-you-trust-37signals-with...

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.

There is a difference between storing plaintext passwords and actually losing them, and as much as I hate to give someone a pass on insecure password storage (it is, apparently, all I ever talk about here), you have to be intellectually honest.

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.

Either they haven't gotten to you in the rollout yet, or they aren't doing Backpack (which would surprise me).

The "honesty" comment wasn't directed to you, but it's obvious why you would think it was. Sorry.

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.

They're doing it as we speak. They had a 5 hour down time that stretched out to 10 hours on Saturday night getting systems migrated; they're announcing batches of accounts converted in Twitter over the week.

(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).

epochwolf 6025 days ago

Both of those links are not proof of any lax security at 37signals. The first link makes the assumption that the ability to email a user's password means the passwords are in plain text. There is such as thing as secure two-way encryption. (Granted, if the hacker gets the encryption key, you're hosed.) You can read more about that in the comments on that blog.

[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)

The first link makes the assumption that the ability to email a user's password means the passwords are in plain text. There is such as thing as secure two-way encryption.

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.

Nwallins 6025 days ago

There is such as thing as secure two-way encryption. (Granted, if the hacker gets the encryption key, you're hosed.)

So, is there any less sensitivity (security-wise) regarding the key, instead of the password?

epochwolf 6025 days ago

It's more common to get access to the database through sql-injection rather than hacking the server. So having the encryption key on disk is more secure than plain text in a database but not much more.

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.

(a) You don't have to "hack the server" to read a config file that the web app can also read.

(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.

epochwolf 6025 days ago

Yikes, I didn't realize databases included the ability to edit the filesystem.

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.

sabat 6025 days ago

37 Signals is on record as having stored passwords in plain text. They thought it was just fine at the time. I'm glad to hear they finally caught up with the new millenium.

cloudkj 6025 days ago

I'm guessing tree5 is talking about "Agile Web Development With Rails," in which the authors do give examples of creating hashed passwords with a unique salt and running a SHA1 digest. The book also talks about preventing plain text passwords from showing up in log files from form submissions.

From what I understand however, AWDWR is only tangentially related to 37signals.

tree5 6025 days ago

"Agile Web Development With Rails", Chapter 11, Administration

Here's the sample code they give in that chapter:

    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

They are using SHA1 with a salt, the exact method that security experts recommend against when storing passwords: http://news.ycombinator.com/item?id=995645. And obviously they didn't even use this insecure method internally.

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.

You're right. Just give them credit for taking their lumps, apologizing, and getting religion.