"On communicating better" --- 37signals revises security pages.(37signals.com)
37signals.com
"On communicating better" --- 37signals revises security pages.
http://37signals.com/svn/posts/1907-on-communicating-better
5 comments
Acknowledge mistakes; fix broken process; communicate changes clearly: three straightforward steps that too many companies still haven't figured out yet. Fair play to 37signals for getting the message.
Kudos for being open and honest. These guys are the poster child for PR.
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?
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?
I don't know. Should FedEx shut down its web ordering system until they figure out how to hash passwords? Because they'll happily send you your password via email if you lose it. And they have your credit card on file.
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.
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.
How is this not a show stopper?
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.
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.
Uh, yeah, that's true exactly up to the point where they manage to code an injectable SQL statement --- you know, like every web application ever built.
SQL injections are a bright spot in Rails' security, actually: to cause them with ActiveRecord, you have to go out of your way to write insecure code.
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)}'")
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)}'")
Rails has had SQL injection vulnerabilities before:
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.
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.
Rails apps wind up with SQL injection like every other application, patio11. All it takes is someone (a) doing a join that AR doesn't support directly and (b) using it to drive a table with sortable columns, pagination, or selectable column names.
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?
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?
> Hashed/salted passwords are security theater for geeks.
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).
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).
and what about:
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.
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.
These are the geek versions of "movie plot threats": increasingly unlikely contrivances of a combination of poor choices and brilliant evil genius which can only be addressed by the fact that the hero studied ballet back in high school which we know because he was razzed about it in scene two.
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.")
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.")
These are the geek versions of "movie plot threats": increasingly unlikely contrivances of a combination of poor choices and brilliant evil genius which can only be addressed by the fact that the hero studied ballet back in high school which we know because he was razzed about it in scene two.
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
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'm not a security person - you're saying hashing is useless because an attacker could capture passwords before they were hashed?
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.
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.
"Hyperbole may sell, but we don’t want to sell 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.
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.
I really like the effect of crowd-sourcing influence. This appears to be a fall out of the large number of comments to the recent post on HN regarding the slack on part of 37signals:
http://news.ycombinator.com/item?id=803899
Very effective. What's scary though is that it apparently took being posted on HN before someone took it serious.
At least now that procedural hole seems to be fixed and this will never happen again.
At least now that procedural hole seems to be fixed and this will never happen again.
* 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.