Friday, May 01, 2009

Can you trust 37signals with your password?

Recently, 37signals blogged touting their security in dramatic marketing terms. It's a pity that the reality doesn't match the claims.

Two of the major claims on the security page are Your data won’t be compromised and Our systems are hacker safe. And the related details talk about the firewalling and physical security of their data center. All that's great.

But there's a dirty little secret. 37signals stores passwords in plain text in their database (or, as commentators have pointed out, they could be storing the password encrypted using a key available to their application server; either way the password can be recovered by a hacker who gains access to their server). I found this out today when cancelling my Highrise account. I'd forgotten the password and so I went through password recovery. It instantly emailed me my password.

I'd expected to receive a temporary password and be asked to change it. But 37signals stored my password in their database and was happy to email it out. For me this isn't a disaster because I generate unique passwords for each registration, but for lots of people this is a big problem. Plenty of people use the same password on many different sites.

That means if one site is compromised hackers can get access to all those user's other accounts. And a compromise can come in various forms. It could be actually hacking into 37signals, or it could be getting access to an old backup of their database.

But there's a solution to this, it's easy to implement, it completely eliminates the problem even if their site is hacked, and it's a security best practice. There are plenty of good descriptions of how to implement it. The Unix operating system has been doing this since the 1970s, so why is 37signals not doing it? Hard to tell.

In a posting in 2007, Jason Fried said that they planned to change this, but now it's 2009.

There's no excuse for this sort of lax security, if 37signals got hacked they'd have to bow their heads in shame in front of every single one of their customers and admit that their password had been stolen. Why take the risk?

Labels: ,


Blogger Jim said...

I mean two major factors would have to come into play here. I highly doubt, but prove me wrong, that 37signals store the users passwords in their database completely unaltered. (And by no means am I a 37signals fanboy.)

They could be using a combination of SALT + AES and if a hacker had access to just the database there would still be no issue.

However, if hackers compromised both the database and 37signal's backend or knew the SALT and encryption keys there would be some issues.

However, overall I do agree with you. I am a fan of one-way encryption methods when developing.

2:57 PM  
OpenID Gavin M. Roy said...

How can you be sure it's stored unencrypted in the database and that it's not two way encrypted instead? I'm not arguing the merits of two way encrypted password storage as much as pointing out that your statement that they store a plain text password may be incorrect.

2:58 PM  
Blogger Kent Fenwick said...

Hi John,

I agree that when you make bold statements like they did you are likely to have holes in the system, but I don't think it nessessarily means that they store your password in plain text.

They could have an encryption and decryption algorithm that runs when sending out password reminders. I know we did this for a while, but we made the mistake of not using SSL when sending emails so it was a huge security hole. However, it doesn't mean that they were storing the passwords in plain text.

Overall though I agree, that this isn't the best practice and is A HUGE risk especially if people find out, since it's such an easy attack to start.

I think the best lesson from your post, is be careful when you say something is bullet proof. I heard of a guy who died wearing a Kevlar vest.


3:22 PM  
Blogger Saverio Miroddi said...

> in plain text in their database

I don't think this is the actual configuration.
Most probably passwords are stored with a reversible hash function, with the key hardcoded in the codebase, so that to hack the passwords they should hack the application server.

3:37 PM  
Blogger Walt Jones said...

37signals knows very well how to use md5, sha1, etc. to store passwords. Your claim sounds nearly unbelievable (though I'm not dismissing it.) Hopefully they will comment on this.

4:10 PM  
Blogger Sijin said...

You're assuming that they are not using encryption. Hashing is one way, encryption is two-way so they might have internal tools to decrypt your password.

5:01 PM  
OpenID senikk said...

How could you be so certain that the passwords is stored in the DB as plain text? Yes its mailed to you as plain text but that doesn't tell anything about the form its stored in DB.

I haven't seen their DB so I doesn't know the answer.

5:20 PM  
Blogger Chris said...

Sorry, but remind me again why sending a password in plain text is a direct correlation to storing it as plain text? What about a bi-directional encryption algorithm?

6:25 PM  
Blogger Nick said...

You are assuming that they don't encrypt passwords internally or have some other security mechanism.

6:52 PM  
Blogger Jeswin said...

I remember 'bugging' them about an XSS vulnerability about 2 years back. After 2 emails, DHH replied saying that BaseCamp assumes that administrators will only add trusted users to a project and so XSS is not an issue.

I was surprised, considering that all large projects could have many user accounts and some might belong to your customers or vendors. Why should you automatically trust everyone?

I feel better that they are giving more importance to security now; but this plain-text password is scary!

6:52 PM  
Blogger ken said...

maybe they store it in the encrypted format, and then decode it when they send it back to you.

you cannot say for sure that they are stored in plain text.

7:04 PM  
Blogger Brian said...

I'm sorry.. but what you described wasn't proof of plaintext.

There are ways to store passwords using Encryption. Most sites store them by hashing the password, so once it goes in it can't come back.

But Encryption, such as AES, is 2 way. Using a key, which they could store, they could encrypt your password into the database, and then when you need it, pull the password out.

Some web applications take this a step further and use a custom encryption algorithm, making the key even harder to break.

But, go ahead and believe that just because they send you a password unencrypted, that it must be plaintext.. without any proof of either way.

7:16 PM  
Blogger Jimic79 said...

Well, is it entirely true they store passwords in plaintext? I mean, there are ways to encrypt/decrypt things. I'm not saying that storing passwords is acceptable in the least, but I would hope there would be some kind of security... (*obvious naivety)

I found out the Philadelphia Chamber of Commerce is doing the same thing. They sent me a letter in the mail saying my membership renewal was due and it said "log into our website, here are your credentials" and it had my username and password in plaintext. They got a nice little email from me about it.

7:18 PM  
Blogger MeltingIce said...

How do you know they aren't using encryption? With MySQL, you use the ENCRYPT() function and give it a secret key, then you DECRYPT() later to get whatever its contents are.

7:23 PM  
OpenID Hohenberg said...

Actually, you might be mistaken. Maybe 37signals saves passwords strongly encrypted.

As long as the keys and the database are not compromised, which means two instead of one point of failure, everything is ok. Save enough, I might think

7:25 PM  
Blogger John said...

Doesn't mean they store it in plaintext. It can be encrypted with a key that only exists as an environment variable, or something like that.

7:31 PM  
Blogger Alex said...

Storing encrypted passwords is no safer than storing plaintext passwords. An attacker who has access to the database also likely has access to the encryption keys.

The only secure solution is to use a one-way hash function along with a per-password random salt.

8:01 PM  
Blogger kinabalu said...

For everyone here that mentions the password not being stored in plaintext but "encrypted". So what?

If a hacker got as far as the database, the "key" isn't anywhere near secure. Might as well store it in plaintext if you're not going to bother hashing it.

One way hashing ftw!

8:02 PM  
Blogger Geekwad said...

Unless an operator has to log in and key in a secret every time the system reboots, it's effectively plaintext no matter what the actual on-disk encoding is. Even still, for anyone who compromises a live server, it is effectively plaintext.

But, no one would go through all the trouble to strongly encrypt the password table using a key not persistently stored on the server and leave themselves open to attack despite all that effort when a one-way hash is safer and easier. It's very doubtful they even make a pretense of securing the passwords.

8:26 PM  
Blogger terhorst said...

Everyone is missing the point. If the password is stored encrypted and then decrypted for auth, then the key exists somewhere in the same system. On disk, in memory, environment variable, whatever--the point is that if someone is able to gain access to the DB then they likely can get at that key as well, at which point those passwords are as good as plain text. Then UNIX solution alluded to is to use a one-way hashing algorithm on the password plus a "salt". Even if the salt is learned it is still non-trivial to generate the correct password needed to match the stored hash.

8:27 PM  
OpenID Sidney San Martín said...

Almost every comment here argues that users' passwords might be encrypted and that that makes everything OK.

They might be. Does it matter? Plaintext isn't stored as letters etched on hard drive platters, it's encoded. If 37signals can decrypt your password we should assume that an attacker can as well.

8:34 PM  
Blogger synack said...

I"m a security researcher, not a developer, but from my perspective, reversible encryption for password storage is almost never a good idea.

A lot of the comments above make the argument that reversible encryption results in two failure points that an attacker must hit in order to recover the password, but this isn't true. If a hash is used, then an attacker must (1) recover the hash, then (2) brute-force/dictionary attack the original value. In the case of two-way encryption, the application must have a method of decrypting the password in order to send it out on request. Now, an attacker need only (1) find a way to make the application perform the decryption and return the plain-text password. There is a far greater likelihood of success if the password is stored in a two-way encryption scheme.

A way to secure it a bit more is to use a public/private key pair for the encryption. The user-facing application can perform encryption using the public key and authenticate by matching the results against the stored value. A non-user interactive application can be responsible for decrypting the password to send it in reminder messages. Since the required elements for recovering the password would still be available by a server level exploit, this is not a perfect solution, but it does remove the attacker's ability to use the application's native functionality to perform the decryption.

8:49 PM  
OpenID 4zumanga said...

Just have to reply mainly to replies, I agree with the article.

Even if the passwords are stored encrypted in the database, once a hacker is in to where they can get the database, they can probably get the code which mails out the passwords, which will include the info necessary to unecrypt the passwords.

Anyone with any security knowledge would not have any means of recovering the passwords. If any of my 1st year students designed a website like this, they would get failed.

8:51 PM  
Blogger Tom Bortels said...

I think a lot of the comments are missing the point...

37 signals sent his password back to his email, plaintext. It doesn't matter if they're saving that password with triple-super-unbreakable encryption - if they can recreate the password to send it to him plaintext, so could a hacker (apparently by means as simple as spoofing/intercepting email). There seems to be a recurring meme here that if you encrypt it in a reversable manner, it's appreciably more secure than just saving the plaintext - that's not the case.

The *right* way to implement this is for 37signals to save a one-way hash of his password - and then thru various mechanisms, use that hash to confirm the password on login. They're clearly not doing so, because they sent him the plaintext password - something they could not do by design if it was done "right".

9:08 PM  
Blogger varaon said...

@Tom Bortels

Thank you. It would likely be easier to sniff the plaintext email than to crack the database - people really are missing the point here.

9:36 PM  
Blogger Tim and Lauri Inman said...

Pride cometh before a security breach.

11:39 PM  
Blogger boblah said...

You make this bold claim with very little evidence to back this up. Like others have said, perhaps they are using two way encryption. Before you go slandering 37signals, do some more research, idiot.

11:42 PM  
Blogger Clayton Shepard said...

MSDNAA Microsoft Devenlopers Network Academic Alliance does the same thing. It is a service that provides software for college students (the college/department needs a subscription). I was pissed of to see my password in an email. It wasn't one I use for everything, but a couple old accounts still use it.

Even worse is that email is not necessarily encrypted -- server to server or user to server. Any eavesdropping can pick up plaintext passwords.

12:48 AM  
Blogger trafnar said...

I agree that the original post is somewhat off in assuming that because the password came to him as plaintext, it is stored as plaintext.

However, I find it problematic when companies send me my password in plaintext (regardless of how it was stored). Now I have to rely on my email being secure (which it isn't). Also I once gave the wrong email address by accident to a company so when I created my account, someone else was sent my created password.

I'm implementing this method of password recovery on a site I'm building. Seems like a slick way to do it:

1:35 AM  
Blogger psilo said...

Three words. Most of you commenting above probably don't know what they mean, so look it up. Known-plaintext attack.

With access to the DB, encrypted or not, an attacker gets to run not one, but gajillions of known-plaintext attacks.

This is absolutely an issue.

2:05 AM  
Blogger George said...

I'd encourage everyone to read the 37s forum thread Jeff linked before you make assumptions about 37signals basic knowledge of password security:

Make sure you scroll up and read what Jason Fried's comment is in response to. Its a complaint from a customer that other users' passwords are being printed plaintext in the HTML source of admin pages. Jason Fried's dismissive response to this glaring problem is telling.

With this attitude towards basic security, "they can't be that stupid" doesn't work as a rebuttal to the idea that they would store passwords in plaintext. They've already shown such wanton disregard with user credentials before.

The amount of sensitive business data in Basecamp confers a special responsibility to ensure its confidentiality. 37signals' performance to date is unacceptable.

4:09 AM  
Blogger Nitin R.K. said...


Just because 37signals was about to retrieve your password doesn't mean that the password was actually in plain text.

But I do agree with you on security - if the password is stored in encrypted format and can be decrypted, a rogue sysadmin could retrieve your password... but then again, they probably have some kind of an audit trail to counter that kind of thing.


6:56 AM  
Blogger Chris said...

Seriously guys, anyone thinking they're not storing passwords plaintext is deluded. Chances are, they're not even storing them base64.

Their application never supported encrypted passwords, and the feature is probably issue 43 (out of 27645) in their bug database. The problem is that it's a very easy one to put on the back burner until an 'oh shit' breach.

Very few web apps get this feature backported. I can only assume respondants saying, "hey, they might have encrypted it now" don't realise it's actually harder to do it that way for significantly less benefit.

Sad but true, and probably typical of hundreds of web apps.

Bad PR might effect the change, but this is but one example of why you should use a password manager no matter how inconvenient it might be.

10:47 PM  
OpenID JasonBunting said...

It's scary how many people that have left comments on this post know nothing about storing passwords.

"They probably store it using 2-way encryption," "just because they sent it in plain text doesn't mean they are storing it in plain text", etc.

You are the very people that screw website security up and need to be educated.

First off, the obvious, unless your email is sent safely, a packet sniffer would be all that was needed to get that password, which was sent in a regular plaintext email.

Second, if the cracker obtained access to the encryption scheme and the data, it doesn't matter that the passwords were stored encrypted, now does it?

People think that by using the word "encrypted" they know what they are talking about...

4:42 PM  
Blogger Sijin said...


"just because they sent it in plain text doesn't mean they are storing it in plain text"

I think extrapolating from the above to conclude that encryption is thought to be secure by the commenter is an error on your side.

12:50 PM  
Blogger Tanel said...

JasonBunting: You DO realize that the password can be sniffed at any point while submitting it to the web application or changing it or whatnot? And that when a hacker gains access to the server and/or to the database, then the passwords itself dont matter anymore? You have access to the data and even if you are solely interested in the password, then dictionary attacks yield good results on commonly used hashes.

Im not saying that hashing is not a bad practice or anything, but security trough obscurity is just a sad excuse for doing something because "everyone else does it, so it must be good". There are loads of more important issues about the security of an application and its infrastructure than plaintext passwords.

11:27 PM  

Post a Comment

Links to this post:

Create a Link

<< Home