12 ms·
Plain Text Offenders - Did you just email me back my own password?
"We’re tired of websites abusing our trust and storing our passwords in plain text, exposing us to danger. Here we put these websites to shame."
- nyellin 16y agoThere 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. For Freeversation, we store plaintext passwords for two reasons: 1. Our passwords are group 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 is the worst case scenario, not stolen passwords. 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 else 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. 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 more 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.
- kunley 16y agoThe catch is in the word hopefully. Wishful thinking is not a successful way of doing things in engineering.
- nyellin 16y agoIf someone creates and conversation and re-uses a password, that password is emailed to everyone they invited. There is no way to avoid that and still use a group password. Edit: Furthermore, the password is not associated with a specific email address or user name. Even if someone has access to a conversation's password, they don't know who the password belongs to.
- bmelton 16y agoI don't know your use cases, so pardon me if this is naive, but couldn't you create a token that is unique for each user, and is consumed after use?
- nyellin 16y agoI'm not sure what you have in mind. Our use case is explained on freeversation.com/about. Let me know if you have any questions.
- bmelton 16y agoOkay, having read that, I agree -- you absolutely don't have to worry about password theft. At least, not after the fact of a conversation having already happened. However, what I was suggesting, is that instead of using a group password: - create a random password for each user that is invited - as part of the 'login' process (or room join process, depending on how your code is structured), check to make sure that token exists in the database - as soon as somebody uses that random password, delete it (or mark it inactive) This means that for each token, there can be exactly one login. That login should belong to who you sent the email to, and nobody else. It's just as anonymous as your method, and slightly (wee bit) more secure. This also solves the problem of people sending the password to their friends, though obviously cannot plug the analog hole of allowing their friends to look at their screen.
- mercuti0 16y agoNo, it's only the worst-case scenario for you. The worst-case scenario for the users (your customers) is their password exposed. They don't care about your server.
- nyellin 16y agoAgain, it's not a private password if they chose to share it with a group.
- JangoSteve 16y agoWhat if the group is that person and their dad, and they don't care if their dad knows the password to their gmail?
- nyellin 16y agoBy definition, there is no point in having an anonymous conversation with your dad, because it wouldn't be anonymous. Right now, we're seeing freeversation used with much larger groups of people, where guessing which email matches the password is impractical, even if someone does reuse a password.
- estel 16y agoThe 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. After I emailed to complain about this, they said: "Security and usability is often a trade-off. We make two main ones: * 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. The accessibility and increased convenience for users in both cases has been deemed to be worth it." Edit: I just checked, and it seems that they've changed this element of their policy. The situation above was March 2009.
- Kudos 16y agoAt least it's some consolation that they don't store the password in plain text, unlike plentyoffish.com. Do they also email you your new password if you change it?
- estel 16y agoSorry, I didn't clarify: they showed in plaintext the password that I supplied and emailed my password back to me.
- mootothemax 16y agoEmailing a password after registration does not, in itself, indicate that passwords are being stored in plain text.
- BrainScraps 16y agoThe other day I thought there should be a "Wall of Shame" site for photos of the d-bags who abuse handicapped spots.
- hmemcpy 16y agoJust make a tumblr page for it :) Seriously, not including setting up a domain it takes about 15 minutes...
- nickbarnwell 16y ago>not including setting up a domain it takes about 15 minutes... Which, coincidentally, is about the same amount of time as you can expect your tumblr page to be up every month ;)
- alanfalcon 16y agohttp://youparklikeanasshole.com/ http://youparklikeanasshole.com/
- JCB_K 16y agoReminds me of this: http://news.ycombinator.com/item?id=2329366 http://news.ycombinator.com/item?id=2329366. Unbelievable.
- pbhjpbhj 16y agoMailman ... My LUG uses it and mails me my password in plaintext every month; IIRC it is|was the default setting ... /me-rolls-eyes
- ig1 16y agoTo be fair the Mailman registration page explicitly tells you not to use a secure password as it'll be mailed back to you in plain text.
- sigzero 16y agoAnd to be fair, you can't really do anything with that password except change your subscription status. That said, version 3 is in the works and I read that "feature" is going away.
- pbhjpbhj 16y agoI don't know, do the admins not get sent the email too as they are subscribed? It's a loooong time since I used mailman.
- nuclear_eclipse 16y agoIf you log in to Mailman, you can at least tell it to stop sending those emails every month...
- mattmanser 16y agoNitpick, they're not necessarily storing it in plaintext, they may just not be salting it. There is a difference.
- dansingerman 16y agoWhether it is stored plaintext, or in an encrypted format: 1) They are sending it in plaintext 2) Encrypted passwords are a factor less secure than hashed (and salted) passwords I am not sure how salting the password comes into it in the context you describe - can you explain?
- mattmanser 16y agoFrom the site: A website storing a password in plain text means that your password is there, waiting for someone to come and take it. It doesn’t even matter if you’ve created the strongest possible password. It’s just there. ...We’re tired of websites abusing our trust and storing our passwords in plain text, exposing us to danger. Here we put these websites to shame. That is possibly a libellous allegation. It is not necessarily true. The password is not necessarily stored in plaintext, it may still be encrypted. The website owner does not understand encryption. Understand my point now?
- dansingerman 16y agoNot really; this post doesn't mention salting, which is where my confusion about your point came from.
- JoachimSchipper 16y agoThere's also a difference between (non-reversible) hashing, with or without salt, and (reversible) encryption. Additionally, encrypted passwords are only better than plaintext passwords if an adversary that breaks into your database does/can not also get the encryption key. That's unlikely to be the case.
- mattmanser 16y ago
- linker3000 16y agoNothing 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. 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. 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.
- va_coder 16y agoYou say you telephone the users. What if they are traveling? How do you verify the other person on the phone is who they say they are?
- JoachimSchipper 16y agoWorse, GSM encryption is pretty broken, people could be listening in, etc. Phoning people is still sensible in that attackers have to be close to the target, though (or get a wiretap).
- asharp 16y agoSurprisingly not, mostly due to some very strange bits of the GSM protocol. Basically, as long as you have enough signal such that the victims handset can hear your commands, you can tell it that you are stronger then any other signal, and the handset will instantly switch to your cell. What's worse is that there exist secure GSM encryption/etc. standards, however as the cell tower chooses what encryption to use, it is mostly pointless. (I remember watching a video about this. Apparently your phone is meant to show a massive warning if they are using unencrypted GSM. None do). http://www.youtube.com/watch?v=rXVHPNhsOzo http://www.youtube.com/watch?v=rXVHPNhsOzo is a good video about this.
- colinhowe 16y agoI've been wanting to make this for ages. Very pleased to see it made! 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"
- hmemcpy 16y agoIt's already planned :) Stay tuned!
- blauwbilgorgel 16y agoBetter add rel="nofollow" too. Or do you want to vouch for all these pages? If your PR rises, expect people to create plain-text systems just to get a dofollow link. Also, do you check each and every service you put up? Or do you trust the random internet visitor to always do the right thing? Are you ready for and ok with any collateral damage?
- aslakhellesoy 16y agohttp://passwordfail.com/ http://passwordfail.com/ 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.
- deleted 16y ago[deleted]
- deleted 16y ago[deleted]
- robinwarren 16y agoI'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.
- jeza 16y agoSeems 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. 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. 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. 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. 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.
- temptemptemp13 16y agoIf I understood you correctly - there doesn't need to be a tradeoff between wire and storage security. You could use a oneway hash at the client side as well. If you don't want to divulge what's the hash in your database, you can add another oneway hash for whatever reaches the server. The challenge-response can also be based on hashes.
- netaustin 16y agoDrupal 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.
- compay 16y agoCodeweavers, 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. https://www.codeweavers.com/login/ https://www.codeweavers.com/login/
- Estragon 16y agoA straight list without the irrelevant screenshots would be much more scalable.
- treblig 16y agoPretty scary feeling: search your gmail inbox for your default password.
- tnorthcutt 16y agoI tried to submit a screenshot, but got the error message Sorry, your page had expired. Please try again. 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.
- tnorthcutt 16y agoThis comment got downmodded, but I'm not sure why. Does anyone have some insight into what I may have done/said wrong, so I can avoid doing it in the future?
- omervk 16y agoThis is a tumblr issue. I think it has something to do with Chrome. Did you use that?
- tnorthcutt 16y agoYes.
- jcsalterego 16y agoRackspace does this with their Cloud Servers :'(
- asharp 16y agoSurely your joking, Mr. Alterego?
- emp_ 16y agoWell, they do sent root passwords over email.
- goosemo 16y agoif it was the welcome message, that's not a problem. It's up to you to change it. If they're emailing you your password to root after you've changed it, you might have an issue.
- MartinCron 16y agoExactly, I'm using SoftLayer cloud servers and they do the same thing... displaying a cleartext version of the initial root password for the machine. I don't see a way around it. I do have to get that information somehow.
- JonnieCache 16y agoEC2 servers dont have any passwords at all by default. Not blank ones, but there are actually none set at all. They come primed with a keypair which you get when you create your account. Considering we live in space year 3000 now, its a wonder that we still have passwords at all. Why can't we have 2 factor keypair authentication for everything? OpenID is thinking too small.
- asharp 16y agoInject the users public key in as root and have pubkey only logins for root. Now you are both secure and convenient.
- r_kaup 16y agoCan someone explain to me why it is so important to hash passwords before storing them?
- temptemptemp13 16y agoThe passwords can be stolen and then you royally screwed your users who trusted you. http://blog.moertel.com/articles/2006/12/15/never-store-passwords-in-a-database http://blog.moertel.com/articles/2006/12/15/never-store-pass... http://stackoverflow.com/questions/287517/encrypting-hashing-plain-text-passwords-in-database http://stackoverflow.com/questions/287517/encrypting-hashing... http://www.usenix.org/publications/login/2001-11/pdfs/singer.pdf http://www.usenix.org/publications/login/2001-11/pdfs/singer...
- yuvadam 16y agoProps! Took me a moment to figure out why all the initial sites are in Hebrew ;)
- thisisblurry 16y agoI'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.
- acidblue 16y agoI 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!
- enewcomer 16y agoHere's my experience trying to bring this to one of the offenders' attention. He actually attempted to justify it. http://eric.newcomer.org/jamplay-defends-storing-passwords-in-plain-te http://eric.newcomer.org/jamplay-defends-storing-passwords-i...
- eekfuh 16y agoToms.com sends you your password after you signup, which is retarded since YOU JUST entered it into their system.
- gabbo 16y agoBy far the worst example I can think of here is Yodlee, the bank aggregator. Their product, Moneycenter, has this convenient "feature" which lets you display your bank password in plaintext! It's unthinkable that someone you trust with your bank credentials would let their website be a two-way street for plaintext bank passwords. 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. 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: 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.
- ars 16y agoHow are they supposed to log in your sub-accounts without the password? They have no choice except to store the plain text password. And they don't just show you the password - they make you enter your login password first. What exactly do you want them to do? You aren't thinking this issue through. Do you just want them to hide the password from you? What would be the point? They still have it. They also have a one-click login to your subaccounts, so even if they don't show you your own password it wouldn't be enough. I suppose you want this feature disabled too? The point of not storing plain text password is not to avoid displaying them, it's to make sure no one else can steal them. But yodlee has no choice, they must store it plain text. And once they do, displaying it - only upon your explicit request (so it's not accidentally displayed), and after you enter your password, seems reasonable to me.
- gabbo 16y agoI'm sorry but you're really not (a) paranoid enough and (b) thinking defensively (c) accepting the reality that users will make poor security decisions (d) recognizing that a service should do everything in their power to mitigate threats to their customers. Yodlee does a good job in many areas (security questions, special phrases and images, secondary password prompt for "riskier" operations) but still falls short here. I realize that my credentials need to be efficiently convertible to plaintext at runtime within their service. They still shouldn't be stored in plaintext (it shouldn't be easy for engineering and operations staff to see my bank password by just looking at a database dump) though. In any case, I took the leap of faith that I trust Yodlee to keep my bank credentials secret when I signed up for their service in the first place. This is not what I was talking about. I realize they force you to enter your password first. This is good but doesn't mitigate the threat I had in mind in the first place. It's Yodlee's responsibility to minimize the risk their service poses to their customers. Unless they can be 100% sure that the person signing in with my Yodlee credentials actually is me they need to consider the implications if it's not. Off the top of my head here are two obvious situations where Yodlee's "display plaintext password" feature puts users at higher risk: 1. User accesses Yodlee from a computer (maybe theirs, maybe their friend's, maybe a public terminal) which has a keylogger installed on it. 2. User is not security-conscious and doesn't realize the implications of this feature. Thinking Yodlee is read-only (like most other competing services) they use a weaker password than they should or even use the same password for Yodlee as on other sites. They shouldn't but it's a fact of life that they do. In both cases the attacker can get the user's Yodlee password and then all of their bank passwords. They steal all of the user's money. Banks are generally willing to play ball and cover users for their losses if their account at that bank is hacked. Will they step up in the same way if they're hacked via Yodlee? I'm inclined to believe the answer is no. I don't even know if the bank should be expected to. When choosing whether or not to build a feature, you need to consider whether its benefits outweigh its risks. Trusting Yodlee with my bank credentials to aggregate financial data is a risk but doing so is the entire basis for their service and provides me with a huge amount of value. It enables scenarios which are otherwise completely impossible. This "show plaintext password" feature is a small convenience which doesn't enable any new scenarios and has some pretty significant risks. EDIT: I'm aware of the auto-login feature but didn't bring it up because it's almost the same as displaying plaintext passwords. Practically speaking it's a tiny bit less bad because an attacker can't directly view the password and use it on other services (assuming again that users make poor decisions and use the same password everywhere). Either way I think both should be gone.
- itistoday 16y agoAdd Dreamhost to this list.
- code_duck 16y agoSo, the only companies that do this are in Israel?
- sayemm 16y agoMarkus Frind did this way back when and suffered for it when Plenty of Fish got hacked a few months ago, big risk.
- deleted 16y ago[deleted]