

Can you trust 37signals with your password?  - l0stman
http://www.jgc.org/blog/2009/05/can-you-trust-37signals-with-your.html

======
mpk
Oh boy, that's an embarrassing newbie mistake to make.

~~~
ryanwaggoner
What's worse is that they've known that it's an embarrassing security flaw for
years, but they apparently thought other things were more important. Not
really very comforting.

~~~
tptacek
"Embarassing security flaw"? Come on. We audit several major web applications
every week --- things that are far more sensitive than 37s, like banking,
trading, and pension --- and we see sites store plaintext passwords all the
time. I've never seen any vendor's security report write someone up for this.
If it did get written up, it'd be "Severity: Low", along with "enabling weak
SSL ciphers" and "exposed server version information".

I'm not trying to be an apologist here, but "someone is wrong on the Internet"
if they are saying that storing passwords badly is a major vulnerability.

~~~
sachinag
Really? We're going to downmod the most active security professional on HN? A
guy who's built a 25+ person company on the basis of analyzing web
applications for security? FFS, did we learn _nothing_ from yesterday's expert
kerfuffle?

If Thomas says it's not really a big deal in practice, then _it's not really a
big deal in practice_.

~~~
ryanwaggoner
On the contrary, it's a big deal to me because it's _my password_ and I judge
that it's being stored in an insecure manner. I really appreciate Thomas's
expertise, but since my data is at risk as a customer, my opinion is really
the one that counts.

~~~
axod
If you're not already using different passwords for each website, you can't
really complain _too_ much.

~~~
ErrantX
but it's still the password for THAT site.

~~~
axod
Sure, but if someones managed to hack into the server, they can steal your
account regardless of if the password is plain text or not.

~~~
mdg
no its cool, they use macs

------
datums
I would take it a step further. Why email plain text passwords? It usually
stays in your inbox. This increase the chance of someone being able to get
your password. It now exists on your laptop/desktop and on a email server,
depending on your settings. There should be a reset password, but not a
recover password. Send a link to a secure page which asks for something the
user knows/has username ?

~~~
ErrantX
So many sites email your initial registration details to you in plain text.
Even if they store them hashed up in future it's just a bad bad idea :(

I know my damn password - I just typed it in :)

~~~
rythie
I know, it's really annoying MySpace do this

------
bcl
This kind of beginner mistake makes you wonder how 'hacker safe' their system
really is. You can bet that they will be improving their security soon --
making bold claims about security is one way to guarantee lots of free pen
testing.

~~~
octane
> wonder how 'hacker safe' their system really is

It's not. Not more than anyone else, anyway. 37signals and Fog Creek are
masters of marketing and mind control. There are free tools, or at least
superior commercial tools, that do everything their stuff does.

~~~
weaksauce
Care to expand on that? I am looking for something for team collaberation like
basecamp and curious as to what is out there.

I recommended basecamp to my boss to check out but after seeing this I am a
little hesitant about it.

Edit: I am hesitant because I cannot guarantee that all the users of basecamp
will use a different password than the normal one for their email.

~~~
codemechanic
you can try Tonido workspace

------
crad
One thing worth pointing out is he's saying that they're storing plain text in
the database, which may not be the case. They may be storing the password in
the database with two way encryption. I'm not arguing the merits of that, only
pointing out he's claiming fact on something he has no specific details on.

~~~
jonknee
If the server can decode it so can anyone who has access to the server. Not
only that, but 37S reveals the password of other people's accounts to the
admin. Pathetic.

~~~
ramchip
"Pathetic." is a bit excessive...

~~~
jonknee
No, revealing people's passwords is pathetic. They are a multi-million dollar
company, it's about time they Get Real.

------
jackowayed
That doesn't necessarily mean that it's in plaintext. It could just be a 2-way
encryption algorithm. That's what I did for my Twitter app pre-OAuth. That
way, the passes are encrypted, but I could still decode them to send them to
Twitter.

Now, the way I did it, at least, the key for decrypting it was in my code, so
if someone hacked, there's a good chance that they would look through the code
and figure out what the algorithm was and what the code was.

Still, if they just took the db and got out, and I fixed the hole before they
realized it and came back, they would have a very hard time getting the
passes.

37signals might be doing something like that, which is better than nothing.
Now, they have no reason not to use a 1-way encryption algorithm, so it's
still less secure than it should be.

~~~
eli
Why go through the trouble of a "2-way" encryption scheme which, as you point
out, could easily be compromised by someone with access to the server, instead
of just storing a properly salted hash?

~~~
TJensen
Because he needs the plain-text password to send to twitter for auth.

------
ten7
You said "37signals stores passwords in plain text in their database"

You have no way of knowing how they store their data! And saying something
like this is ludicrous and insulting, IMHo. Sure, they emailed you your
password. That doesn't mean the password was stored in "plain text"... it just
means it was stored. Yes, a one way hash would be better, but they stored the
password. That doesn't mean the password was not encrypted when it was stored.
It also does not mean the encryption key and the storage database are not on
different servers -- which would be harder to crack, since it would mean two
servers would have to be compromised. There is the possibility that they used
two way encryption. That exists, you know...

Just sayin'...

~~~
thorax
Occam's razor says to me that if they didn't take the time to make one-way
hashes, they're not doing anything especially clever with the storage.
Certainly no dual-machine way of handling them because that's surely more
complicated than using SHA1 or MD5.

------
shalmanese
People are missing the point. The main reason for this is not to defend
against "hackers" so much as malicious employees within the company. If you
hash and salt the passwords, it's simply not possible for anyone within the
organization to access them. Even if you trust all your employees, it can help
in avoiding liability.

------
ErrantX
The main securityy issue is not so much that the data is in plain text if
extracted - it is the fact that it can be instanlty used.

If you can only pull hashed, salted passwords from a site there is a LONG
delay before you can make use of it, if at all. But with a plain text password
a cracker can pull paswords, access accounts instanlty, harvest the data and
potenetially ruin your site in minutes. There is no time delay in which
potentially you can catch the intrusion.

The defence by delay is one of the STRONGEST defence mechanisms you can have.
Every day that data is unusable to a cracker the less value it has for him/her
and the more chance the intrusion will be noticed.

------
madair
LOL, a favorite like 37signals does something so egregiously wrong, is
reported, and there's plenty of security 'experts' to say no big deal. This is
a HUGE deal, and thanks to the OP for pointing it out. And you call yourselves
experts. Note to self, be sure to avoid writings by Thomas Ptacek, if these
are his standards.

------
FraaJad
reddit made this mistake early on and they learnt their lesson. They no longer
store passwords in plain text.

The popularity of a service does not guarantee that it's developers are
covering all the bases.

I'm glad Django stores all the passwords as a sha1 hash.

~~~
cperciva
_I'm glad Django stores all the passwords as a sha1 hash._

This is better than storing plaintext passwords, but it still makes a brute-
force attack very cheap. Use a well designed key derivation function which is
expensive to attack. (And come to BSDCan'09 next week to hear me talk about
this!)

~~~
simonw
Django uses a salted hash - each password is stored with a random hash code
unique to that password, e.g.:

sha1$0ae33$b8a9502237851f302170e1bb207d4eb3f36d9a31

The 0ae33 is different for each stored password, and is used as part of the
SHA1 hash. This means you have to brute force each account separately - you
can't just use a pre-generated SHA1 lookup table.

It sounds like you know your stuff though - if there's anything we could do to
make this secure (while not depending on any libraries other than the Python
standard library) please share!

~~~
tptacek
That's still not secure, because SHA1 is very fast. To get "secure" from that,
you need to iterate the function several thousand times, or use bcrypt.

~~~
cperciva
Or use scrypt, which is far more secure than bcrypt. :-)

------
davidw
The comments are impressive... pretty much all of them are people rushing to
the defense of 37 Signals.

~~~
dabeeeenster
You must be new here... ;)

------
simonw
Anyone know if 37signals still allow people to XSS their own Basecamp
accounts? <http://forum.37signals.com/basecamp/forums/5/topics/3155>

~~~
100k
I haven't used Basecamp in a while, but I was distressed to discover this when
screwing around with HTML in todo lists a while back.

I could put arbitrary JavaScript in the todo element, and I verified that it
would execute when run by another user.

Combine that with plain text password reset and you just got pwnd bad.

------
dfranke
Anyone who asserts in blanket terms that his application is secure is
providing evidence to the contrary. Anyone who actually groks security won't
make any such claim without loading it with carefully-chosen qualifiers.

------
rythie
Whilst doing hashed passwords is a no-brainer and it solves process problems
like employees emailing passwords to people (who maybe impersonators) I don't
think it solves all the problems with password security.

Unless you have a strong password policy, john the ripper can often find
several passwords (out of 100+) in literally a few _seconds_ by doing
dictionary attack, variants and common terms. I would say that someone's
hashed password should be well protected as a unencrypted one would be even
inside an organization.

~~~
rythie
...and your both downvoting this because you believe every security problem is
solved by having hashed passwords?

Another point is, do sites even protect against brute force remote hacking of
passwords, Twitter for example got hacked that way.

To be clear I believe they should hash their passwords, but it's not the only
measure you should take.

------
duncanj
A long time ago I learned a technique where you use a random salt to add
several bytes to a password. The salt is not stored, but rather the
authenticating server does a brute-force search for it, using the user's
password as a stem.

For some reason, it just doesn't seem useful to me to store the salt with the
user's record, if you're worried about someone with a rainbow crack running
through your password file.

Edit: that last paragraph was stupid.

~~~
ryanwaggoner
You lost me...the way I've always seen salts used is just before hashing, but
the same salt is used for all the passwords. Then when authenticating
passwords, you salt & hash the incoming password and compare to the stored
record in the DB. Am I doing it wrong?

~~~
jonknee
Using the same salt for all records makes it significantly easier for someone
to crack your whole DB. A different salt for each row means they'd have to go
through the effort of creating a rainbow table for _each_ row instead of a
whole database.

------
Batsu
While it's important that the passwords aren't stored in plain text, it should
be noted that it is also the last line of defense, not the first. There are
plenty of other things to stop you on the way there (not having access to the
email, not being able to crack into their data center, the normal stuff).

Just because passwords are in plain text it doesn't mean that suddenly
everyone is in trouble.

~~~
jonknee
One of the most common ways for data to be stolen is from the inside. Having
500,000 user accounts with plain text passwords is a valuable commodity, all
it takes is a pissed off employee and a SELECT email, username, password FROM
users INTO OUTFILE '/tmp/users.txt'. Odds are you'd have access to tens of
thousands of email addresses and from then on it's easy enough to crack tons
of other accounts.

~~~
Batsu
Very true, and a point I didn't consider.

------
pg
I would have expected Rails libs to store hashes by default. Don't they?

~~~
gry
Rails was extracted from Basecamp. The authentication mechanism is something
of their own MVC design.

The most popular authentication libraries do store salted nonce hashes by
default.

------
psranga
Protect yourself against lax companies like this with the PwdHash Firefox
extension. <http://www.pwdhash.com/>

------
geuis
Military.com is another company that stores their passwords in plain text.

------
slavingia
obviouky. qhy da fuck not.

