* Don't play into security-scene drama

* Do welcome and endorse security researchers

* Don't scare your customers or box yourself in with technologists by being overly specific

* Do make it clear that web security is your main concern

* Don't hit people over the head with a 15 page security and privacy policy

* Do take 5 minutes to set expectations about handling security incidents and advisories, including a sketch of a response plan.

Hyperbole may sell, but we don’t want to sell it.

Well, you sold it for a long time.

The clear text passwords thing is incomprehensible. These guys have move knowledge about rails in their toe jam than 99% of the "rails experts" out there and they can't implement hashed/salted passwords? Come on. How is this not a show stopper?

Not hashing passwords is suboptimal, to be sure, but both you and patio11 are on the crazy-talk ends of the debate here. In a security assessment, weak password storage is a "Severity: Low" vulnerability, right alongside the "Weak Ciphers Enabled in SSL" finding.

Brian's stored XSS finding is considerably more severe, but it got fixed relatively quickly.

Hashed/salted passwords provide marginal security if someone has already succeeded in thoroughly compromising your production servers. If that happens, 37Signals and all their customers are 37Screwed. Any password touching the Rails stack (i.e. all of them) would have to be considered compromised anyway, because whatever compromise allowed the bad guys unfettered access to the app server also lets them inject arbitrary code into the Ruby processes.

Hashed/salted passwords are security theater for geeks.

Safe by default if you use the easiest way to write code:

User.find params[:id]

User.find_by_favorite_fruit(fruit)

Safe by default in the natural Rails idiom:

User.find(:all, :conditions => ["favorite_fruit = ?", fruit])

To get compromised you have to ask for it:

User.find(:all, :conditions => "favorite_fruit = '#{homerolled_buggy_sql_stripping_regexp_i_copied_from_some_dot_net_guys_blog(fruit)}'")

http://www.rorsecurity.info/2008/09/08/sql-injection-issue-i...

No need to make a bad situation worse in my opinion, especially if the cost is just about '0'.

I see password hashing as just another layer of defense, sure if you have the hashes and infinite time you can do more damage but it would certainly help as a deterrent.

Hashed passwords are a secondary strategy, assuming that you have already been compromised how do you contain the damage.

If the reddit guys had hashed their passwords instead of storing them in plaintext the fall-out would have been a lot less severe than it was.

This isn't "security theater". When you lose your users table, you don't want all your users to lose their GMail passwords. So you hash them. Why are we even debating this?

Ok. Point taken.

So, how to do significantly better than hashed/salted passwords ?

Most frameworks that I'm aware of implement the hashing/salting (and sometimes just the hashing) method as their default method of securing stored passwords.

Is there a much better approach that does not inconvenience the user and that has been widely implemented ?

Once your production server is hacked I would think that pretty much all bets are off.

Especially if someone would manage to get access to either the network stack (where they can monitor the initial attempts at authentication in plaintext).

Just having the hashes for a large number of accounts would allow an attacker to do a whole bunch of mischief 'in their own time' rather than to have to contend with the first line defenses (velocity checks etc) of the website under attack.

edit: on re-reading I think you possibly mean to say with your use of 'security-theater' that you might as well store the passwords in plaintext because after your software has been compromised the passwords are all to be considered 'lost' anyway. But that only deals with the 'front door', not with the back door, in case someone walks out with a copy of the database (such as what happened to Reddit).

1) That database dump of the users table that someone put on a usb drive and lost.

2) A brute-force attack via a misconfiguration which allows remote logins to mysql. No "rails stack" access, but the passwords are now compromised.

3) The non-application backup server with DB dumps.

4) S3 access is compromised and unencrypted dumps to S3 are downloaded.

I guess I could keep going, with the attacks getting more outrageous, but I can assure you that stranger things have happened.

Back in real life: All four of your scenarios give me full access to the users table, right? That should be sufficient for me to run my favorite common passwords dictionary and compromise, hmm, 70% or so of them at my leisure. If I wanted a particular one, for example for the admin account or an email address which looked interesting, I could rainbow table it. If I wanted to be extra clever real name and email address gives me two extra datapoints to run for brute forcing and the opportunity for targeted spearphising, but hey, with successful compromise of most of several million accounts I'll already have my hands full stuffing my pockets with your users' money.

Like most proposed solutions added to stop movie plot threats, this one doesn't even work, but it does take mental bandwidth you could be using to implement security that actually matters. (Look how every always latches on to "you don't salt passwords!" and most ignore "Rails does not escape HTML by default, which puts every Rails site at the mercy of the worst coder remembering to h() all their tainted data.")

Bull.

Back in real life:...

Well, in my real life, I've never "rainbowed" a table, or even know what that is after 12 years in IT, but I sure can open a sql file in a text editor and figure out which field is the password.

It's a layer of defense and widely accepted as the minimum and so easy to implement it's ridiculous to argue against it, especially as a "movie plot threat".

Quick, somebody make a movie out of this:

http://www.webhostingtalk.com/showthread.php?t=729362

I think maybe you're over-thinking things. There have to be compromises that don't involve getting access to the whole system - plus even if an attacker does have full access, how likely is it that they're going to try to capture pre-hashed logins versus just dumping the auth db?

As far as I can see, hashing provides clear value over not hashing, so there's no excuse not to do it.

Bravo. This is a great response, and as tptacek noted a great case study in security relations.

Of course, what ultimately matters is 37signals's behavior going forward. But this is certainly a step in the right direction.

At least now that procedural hole seems to be fixed and this will never happen again.