

"On communicating better" --- 37signals revises security pages. - tptacek
http://37signals.com/svn/posts/1907-on-communicating-better

======
tptacek
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.

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

------
yomamma
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?

~~~
patio11
_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.

~~~
tptacek
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_.

~~~
patio11
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)}'")

~~~
jacquesm
Rails has had SQL injection vulnerabilities before:

[http://www.rorsecurity.info/2008/09/08/sql-injection-
issue-i...](http://www.rorsecurity.info/2008/09/08/sql-injection-issue-in-
limit-and-offset-parameter/)

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.

------
qeorge
_"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
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>

~~~
jacquesm
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.

