[epochwolf]

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)

[tsally]

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]

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]

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.

[tptacek]

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

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.

[tptacek]

Yep.

    CREATE TABLE foo ( x TEXT );
    LOAD DATA INFILE "/etc/whatever" INTO TABLE foo ; 
    SELECT x FROM foo;

Did you know about INTO DUMPFILE in SELECT statements? =)

[sabat]

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.