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 ?
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.
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.
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.<p>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.<p>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.<p>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.
You said "37signals stores passwords in plain text in their database"<p>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...<p>Just sayin'...
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.
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.<p>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.<p>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.
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.
reddit made this mistake early on and they learnt their lesson. They no longer store passwords in plain text.<p>The popularity of a service does not guarantee that it's developers are covering all the bases.<p>I'm glad Django stores all the passwords as a sha1 hash.
Anyone know if 37signals still allow people to XSS their own Basecamp accounts? <a href="http://forum.37signals.com/basecamp/forums/5/topics/3155" rel="nofollow">http://forum.37signals.com/basecamp/forums/5/topics/3155</a>
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.
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.<p>Unless you have a strong password policy, john the ripper can often find several passwords (out of 100+) in literally a few <i>seconds</i> 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.
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.<p>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.<p>Edit: that last paragraph was stupid.
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).<p>Just because passwords are in plain text it doesn't mean that suddenly everyone is in trouble.
Protect yourself against lax companies like this with the PwdHash Firefox extension. <a href="http://www.pwdhash.com/" rel="nofollow">http://www.pwdhash.com/</a>