Nothing new there! When we setup a new in-house account, we either telephone the user or go to see them with their password. If it's a senior Manager with a corporate phone they get their password texted to them - Ok, not ultimately as secure as possible but a darn sight more secure than a plaintext email.<p>In my previous job I was asked to FTP our full client list (with financial information) to a third party acting on behalf of the company that had just acquired us. The IT Director of our new owners kicked up a hell of a stink and accused me of being 'unhelpful' because I insisted on the third party signing an NDA and installing AxCrypt so that I could encrypt the data for transmission. In the end I just said that if they insisted I send everying without encryption, I wanted it in writing with a disclaimer that I was acting on their instructions and they would assume responsibility for any possible liabilities arising with respect to UK Data Protection Laws.<p>By the time the IT Director had deliberated the point, the third party (who fully appreciated my position) had sent me a stock NDA, installed AXCrypt and we'd completed the transfer.
The worst offender I can recall was Wordpress.com. Not only do they email you your password back, but show it to both you and whoever might be sitting within a few metres in LARGE LETTERS in the webpage immediately after activating your account.<p>After I emailed to complain about this, they said:<p>"Security and usability is often a trade-off. We make two main ones:<p>* When you register at WordPress.com, we show you your password and email it to you.
* When you log in we tell you whether the username or password was incorrect.<p>The accessibility and increased convenience for users in both cases has been deemed to be worth it."<p>Edit: I just checked, and it seems that they've changed this element of their policy. The situation above was March 2009.
<a href="http://passwordfail.com/" rel="nofollow">http://passwordfail.com/</a> lets people register the offenders.
If you have the passwordfail chrome extension installed, you will get a warning whenever you visit an offender. Highly recommended.
Codeweavers, the creators of Crossover for Linux and OS X, do this. I emailed them about it around a year ago and they never bothered to reply back, even though I've bought several licenses from them over the years.<p><a href="https://www.codeweavers.com/login/" rel="nofollow">https://www.codeweavers.com/login/</a>
By far the worst example I can think of here is Yodlee, the bank aggregator.<p>Their product, Moneycenter, has this convenient "feature" which lets you display your bank password in plaintext! It's unthinkable that <i>someone you trust with your bank credentials</i> would let their website be a two-way street for plaintext bank passwords.<p>Things like this remove any confidence I may have had in their product. The fact that a feature like this exists at all is strong evidence that they're neither thinking in a security mindset nor paranoid on behalf of their users. If someone proposed this "feature" where I work they would be laughed out of the room.<p>If that wasn't bad enough their support folks politely ignored me when I raised the issue and pleaded with them to turn it off. They either don't get it, don't care, or don't know how to escalate issues to people who do:<p><pre><code> Please be assured that Yodlee considers account/data
security as highly critical and hence will not be revealed
to any other source.
We suggest you not to reveal your account login credentials
i.e answers to security questions & password, to anybody.
This will ensure your account will not be compromised.
Thank you for your feedback on the product. We appreciate it.
We are marking this Service Request as Resolved. Please let us
know if you have any questions in this regard.</code></pre>
There are some cases when storing plaintext passwords is justified, despite all of the risks. There are cases where you can't - or shouldn't - hash passwords.<p>For Freeversation, we store plaintext passwords for two reasons:<p>1. Our passwords are <i>group</i> passwords, which (hopefully) aren't re-used anywhere else. If someone hacks our server, the conversations stored on it are incredibly more valuable than the passwords themselves, which aren't associated with a specific email address or account. Our approach to security is that unauthorized access to our server is checkmate. That <i>is</i> the worst case scenario, not stolen passwords.<p>2. When you create a new conversation, you can invite new users to the discussion. Those users didn't sign up for Freeversation - and in all likelihood never heard of Freeversation before - but they're expected to remember a password that someone <i>else</i> chose. We help them remember that password by including it in every notification email we send. (E.g. emails inviting them to the conversation, emails notifying them of new comments, etc.) We wouldn't be able to do that if we hashed passwords.<p>In our case, the alternative to plaintext passwords is actually getting rid of passwords altogether and replacing them with secret URLs. We chose plaintext passwords because they provide psychological reassurance that conversations on Freeversation are invite-only, and not public. The irony is that secret URLs are actually <i>more</i> secure than the passwords that most of our users choose. In the future, we may use a combination of the two, so that users both feel protected and are protected in the best way possible.
I've been wanting to make this for ages. Very pleased to see it made!<p>Would be awesome to have a notable offenders section. A chrome plugin that hooks into this would also be cool: "This site has rubbish password security. Don't use your usual passwords"
Seems that in many cases you get a choice between security over the wire or security in storage, but not both. By this I mean if you use a challenge response authentication algorithm then you often don't have any choice but to store the password in cleartext. Then authentication can be done even over an unencrypted channel without revealing the password.<p>The compromise seems to be to store the password with a oneway hash then use an encrypted channel such as TLS to send the full password for each authentication. There is still the possibility of intercepting the password at the end of this encrypted channel before the password is compared to the stored hash.<p>So both models have weaknesses, it just means you have to focus your security efforts into a different area. For the first, it might be somewhere deep in the backend, for the second you'd be paying attention to the front end where you accept the TLS (e.g. https) connection.<p>This has certainly been the case with for example PPP where you had a choice between PAP (secure storage, but sent in plain text) or CHAP (insecure storage but not sent over the wire in full). Jabber/XMPP servers also traditionally store in plain text but passwords aren't sent for each login. Though it seems that HTTP Digest auth does allow storage of passwords in a hash without transmitting the full password.<p>Then even with challenge response algorithms if someone is able to monitor a number of authentications then they may be able to gather enough information to pose as that user without actually knowing the password.
I tried to submit a screenshot, but got the error message <i>Sorry, your page had expired. Please try again.</i> on the submission screen. Either they're having trouble (and displaying an unhelpful error message), or they have an awfully short page expiration time - from page load to the time I hit submit was under 30 seconds.
Here's my experience trying to bring this to one of the offenders' attention. He actually attempted to justify it.<p><a href="http://eric.newcomer.org/jamplay-defends-storing-passwords-in-plain-te" rel="nofollow">http://eric.newcomer.org/jamplay-defends-storing-passwords-i...</a>
I forgot the password to my credit union account. I clicked on the 'get password' link and they e-mailed my original password back to me, in plain text. Lame! I still need to move my funds though, doh!
Drupal also sends plaintext passwords out of the box (at least in Drupal 6), although it does hash the password in the database. One of the first things I do is change the wording of the welcome email.
I'd considered doing something like this the other day, good work for getting the bad news out there! Hopefully this can help lift the expected minimum of security on the web a little.
I'm shocked that Mozilla not only (seemingly) stores their mailing list passwords unhashed, but that they also email them out to each member every month in a reminder email.
Reminds me of this: <a href="http://news.ycombinator.com/item?id=2329366" rel="nofollow">http://news.ycombinator.com/item?id=2329366</a>.<p>Unbelievable.