"On communicating better" --- 37signals revises security pages.

http://37signals.com/svn/posts/1907-on-communicating-better

by tptacek • 17 years ago

50 17 17 years ago

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.

tptacek4• 17 years ago

I'm biased, but I think this sets the playbook for how your web startup should be handling security public relations:

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

qeorge• 17 years ago

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

scharan• 17 years ago

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

jacquesm3• 17 years ago

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.

yomamma3• 17 years ago

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?

patio113• 17 years ago

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.

jacquesm3• 17 years ago

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

yomamma3• 17 years ago

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.

cdr• 17 years ago

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.

tptacek4• 17 years ago

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.

tptacek4• 17 years ago

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.

"On communicating better" --- 37signals revises security pages.

Related Stories