15
Jun 12

Naming and Shaming the Plaintext Offenders

facebooktwittergoogle_plusredditpinterestlinkedinmail

It was a fitting end to a week dominated by news of password breaches at major Internet companies. I’d sent a password reset request to a hosting provider I’ve used for years to host a file server online, and received an alarming response: The company sent me my password in plain text, all but advertising that they have zero regard for the security of their customers’ private information.

The site was used to store inconsequential files and images, but I cancelled my subscription nonetheless because the company’s response to my password reset request proved that they were storing my password without even making the weakest attempts at encrypting the information or storing it in a protected format.

Sadly, this practice appears to be quite common, particularly among low-cost hosting providers. I confronted the company, Hosting Metro, about its practices, but received no material response to my complaints aside from an automated “sorry to see you go” email.

I also submitted a redacted screen shot of the password reset email to plaintextoffenders.com, a site that regularly posts user-submitted images of password reset emails from companies that exhibit a complete lack of regard for customer password security. I would encourage all readers to do the same for any site that sends passwords in the clear.

Like many previous visitors to plaintextoffenders.com, I was surprised to see that the site’s search function does not work. The administrators of the forum seem to be aware of this, and have noted that visitors can search by company name via Google, by using the search convention “site:plaintextoffenders.com” followed by a Web site or company name. I would welcome the development of a browser plugin that uses a database of offending sites to warn users when they visit a site that practices unforgivably sloppy password security. Naming and shaming may be the only way to change this all-too-common practice.

Tags: , ,

46 comments

  1. DD-WRT’s forum! Really? Would be useful if they just had a list.

  2. Have you guys seen http://passwordfail.com/ ? Also naming and shaming.

  3. Citrix!!!! You are kidding me.

  4. a dropped bar of russian soap in a crowded prison shower full of porkies

    Could US cyberspies have moles inside Microsoft?

    “US government officials could be working under cover at Microsoft to help the country’s cyber-espionage programme, according to one leading security expert.

    The warning comes in the wake of the Flame virus that targeted key computers in the Middle East, and in part used confidential Microsoft certificates in order to access machines.

    According to Mikko Hypponen, chief research officer at security firm F-Secure, the claim is a logical conclusion to a series of recent discoveries and disclosures linking the US government to 2010′s Stuxnet attack on Iran and ties between Stuxnet and the recent Flame attack.

    “The announcement that links Flame to Stuxnet and the conclusive proof that Stuxnet was a US tool means that Flame is also linked to the US government,” Hypponen said.”

    ““This makes you think that this breach of Microsoft’s update system was done by the Americans and most likely a US agency, someone like the NSA,” Hypponen said. “That must make Microsoft mad as hell that its most critical system, used by 900 million of its customers, was breached by fellow Americans.””

    Continued:
    http://www.pcpro.co.uk/news/security/375169/could-us-cyberspies-have-moles-inside-microsoft

    ################

    US Security Services May ‘Have Moles Within Microsoft,’ Says Researcher
    http://it.slashdot.org/story/12/06/15/1614219/us-security-services-may-have-moles-within-microsoft-says-researcher

  5. I think storing passwords in plaintext is very bad. In most cases.

    But there are cases in which I think it is justified. Mailman (list server) is one – with your password, people can change your email preferences, nothing more. A blog were users register to leave comments is another one were plaintext passwords are justified. It keeps most trolls out and may deter spammers.

    The important thing is to make it absolutely clear upon registration that your password is going to be stored in plaintext. (Mailman does that fairly well.) And thus that you shouldn’t use a password that you also use for something remotely important somewhere else.

    You can argue that it doesn’t cost much to store passwords as salted hashes. That’s true. But then people may be tempted to use ‘their standard password’. And thus your database with salted hashes could be worth _more_ than your database with plaintext passwords.

    • “You can argue that it doesn’t cost much to store passwords as salted hashes. That’s true. But then people may be tempted to use ‘their standard password’.”

      You’re implying that people with a “standard password” can be discouraged from using it. Unfortunately, the people who are most likely to use the same password everywhere are probably also the ones who are least likely to understand the difference between plaintext and encrypted storage.

      • That’s true. So you should talk about salted hashes in your ‘warning’ but make a more clear statement.

        And it’s probably a good idea to _demand_ insecure passwords (only alphabetical characters, up to six letters or something) so that people can’t use the same passwords they use for webmail, PayPal etc.

        But then, perhaps I am talking about an ideal situation and is “all use salted hashes and secure encryption” a more practical solution. :-)

        • “demand insecure passwords”

          …for cases where passwords are used for nothing but a little convenience

          that should have said.

        • Most people who have a “standard password” aren’t going to take the time to read a page long description of why they shouldn’t use their password – they’re un-educated about good security and most want to stay that way – “it’s too complex” – or “it takes too much time”.

        • The large problem with storing passwords in plaintext is the amount of people who suffer from password reuse. We don’t need to make it easier to source passwords.

      • agreed! Average Joe doesn’t know anything about stored password security meassures.. Its our responsibility as Admins and Devs to do our best to protect them.. Even if they use lame repeative passwords.

    • To be clear, sending a password in plain text through email is not the same as storing a password in plain text. They’re two separate issues. Personally I don’t have a big problem with password information being sent through plain text because I’m going to just be changing it as soon as I get it, and the odds of someone intercepting it AND being able to use it before I can are pretty much 0. I also think the password should be temporary so that users are forced to change it on first login.

      So it’s not a big deal to me…not nearly as big a deal as storing passwords unsalted or in plain text…but I still think the better option is to have you click on a link and view the password through an encrypted Web page.

      • Better yet – don’t view the password at all – if you’re going to have a “forgot password” capability – either force them to change it immediately – or force them to change it once they get a temporary one in email, text etc.

      • Any password sent in plain text is an invitation to hackers to access whatever content is “restricted” by the password. When hackers are able to request credentials under the guise of “forgot my password” and see the responding credentials, 24 hours is more than enough time for the tools to work on even the slowest computer. It becomes a way for them to test their tools in the wild, and such attacks against “low value” targets frequently elicit the “it’s just a comment password” or “it’s just a blog” reply from security team members. Every security compromise should be assessed, perhaps one day security tools will be better than the hacker tools; until then every piece of evidence counts.

  6. It looks like you’re concerned with the fact that they’ve sent your existing password in the email indicating that it hasn’t been stored on their system as a one-way hash. A valid concern.

    Or is it that they’ve sent a replacement password as plain text and someone could have intercepted that email and used the new password before you have a chance to lock the account back down?

    Anyway, what sort of “lost my password” mechanism is considered to be secure?

    • I believe that there should be a confirmation email that a new password can be set. An encrypted link should be posted in the email leading to a private secure page to change their password. Enter old password, then enter the new password twice and submit.

      At least this would be the way I’d engineer a site to operate!

      • How can the user enter their old password if they’ve forgotten it?

        • Missed that small detail. :P

          I mean the reset link (secured) can allow them to enter in a new password and confirm it, along with a security code possible.

  7. What about all the webhosts that still support and recommend plain FTP?

    We should be shaming them into using sftp too.

    • A password is implicitly secure. Transferring data across the internet is not. I don’t feel that providing insecure FTP access is negligent or misrepresentative.

    • 1) I presume you mean FTPS, as SFTP has nothing to do with FTP.
      2) The issue here is clearly the customer. Even years and years after introduction of FTPS (and similar protocols), most customers are simply unable to use anything other than cleartext FTP. Tool support for FTPS in mainstream web editing tools (I am talking about stuff like Frontpage Express!) is sub-par, too.

      So, I don’t really think the hosters should be named and shamed because this is much more a customer education issue than negligence on the hoster’s behalf.

  8. I’ve found a supposedly PCI-compliant website that sent me a password in plain text. Bounced email and they claim a scheme (they won’t share) that encrypts the passwords on disk. Any PCI experts want to comment on this?

  9. Slightly confused here – sending the plaintext password in reply to a password request does not necessarily mean that the data is stored in the raw. Were there any indications that this wasn’t stored using strong crypto in the database where it lived?

    Don’t get the wrong impression; I’m not a fan of sending plaintext passwords over email. It just sounds like they are being blamed for storing in ASCII when in fact they may be using 10k rounds of modern encryption against per-user salted data. Of course, their mail server logs may not be getting the appropriate scrutiny!

    • Typically passwords are stored as a one-way hash that cannot be undone. When you enter your password on subsequent log-in attempts, the system applies the same hash then compares the results with what’s stored. Not even the system administrator should be able to recover the plain-text version of your original password.

    • What in the history of technology makes you think that a business would go through the effort of implementing crypto properly? Especially if they didn’t have enough knowledge of security best practices to know that passwords should be stored in some form of salted, one-way cryptographic algorithm (preferably bcrypt) as opposed to something reversible.

  10. FYI, when I clicked on YOUR link (https://krebsonsecurity.com/2012/06/naming-and-shaming-the-plaintext-offenders/) by Chrome Browser gave me the message “This page has insecure content. Learn More.”

  11. Brian: You seem to be implying that passwords should never be sent in an email when one clicks on a “forgot my password” link?

    That doesn’t make much sense to me as an average user/shopper. If I am trying to access my account at Clothes Are We, and I can’t remember my password, I need to retrieve it simply and immediately, in an email that I can understand. Many of the sites where I shop will respond with an emailed temporary password and instructions to change it to a permanent one. Then I can make my purchase (and they certainly don’t want to lose Mme. Customer’s sale because she is forgetful).

    I don’t see the problem here. I’d be much more concerned about how they store the rest of my information like credit card numbers and such.

    • They should email you a link that you can click on, which will take you to a page on their site from which you can type in your new password. The reset request should also be timed, in that if you don’t respond within 30 minutes, 45 minutes, etc. the request link stops being valid.

      They never should email a password, temporary or not, in plain text. But the fact that they emailed Brian the actual password to his account means they’re storing his password in plain text on the server.

      With strong password encryption it can take months to break a single password after a security breach. It takes no time at all if the password is stored in plain text.

      • I used to work at technican support at a major ISP – 30 – 45 minutes is too short. While it is true that most emails go through in seconds on occasions sending and receiving email servers can’t connect to one another or for other reasons build up a queue. If a queue builds up on the servers it can take hours for the mail server to get caught up.

        In reality 24 hours is probably more realistic.

    • The problem with plaintext passwords is that the traffic is being monitored by hacker tools written to harvest passwords, especially when retail purchases are involved – if the hacker’s program can beat you to the password reset and relevant credit card information is available, then the risk increases that fraudulent purchases will be charged to your accounts. This is an arms race, and the hacker weapons can easily take advantage of plaintext passwords. My stance aligns with Brian on this matter.

  12. Sending you a NEW/RANDOM/RESET password in plain text is fine. It’s just as “dangerous” as sending a link where you can change it. I can see a lot of submissions on that site are complaining about that. That’s dumb.

    Sending your EXISTING password in plain text back to you on a password reset request = BAD. This means they are not 1-way encrypting your password, and I’m sure a lot of other bad practices!

  13. Carl 'SAI' Mitchell

    Riot games strongly implied that they store their passwords with unsalted hashes. Not as bad as plaintext, but nearly so.

  14. krebsonblackmailing anyone?

  15. That was fast:
    http://plaintextoffenders.com/ -> Not Found

  16. just my 5 cents:
    some people here said, that they dont have a problem with plaintext passwords send via email, as long as they dont save it plaintext in their database.
    I dont have a problem with that, too.
    BUT their are way better methods to let user create an account or change their password, without the need to send any plaintext passwords.
    So why companys still do it, is beyond me.

    BUT the whole “send an encrypted link to reset” System aint any saver.
    If someone can read your emails, it doenst matter if theres the password in plaintext or a link to reset it.
    A twofold approach is necessary here:

    - Visit a ssl secured password reset page, hit the reset button
    - you get a code/keyword displayed and an email is dispatched with an encrypted link
    - you have to insert the code you got via the ssl secured webpage into the new password reset page you got via email.

    this is pretty secure against any network sniffing/man-in-the-middle attack.
    It wont help against trojans or governments with access to ssl infrastructure, but nothing is perfect ;)

    greetings

    Christian

    • That is more complicated, but not a single bit more secure.

      Assume an attacker can read the victim’s e-mail and has access to the password reset page (i.e., it is not on an intranet or stuff).

      Then the attacker visits the password reset page (which, by definition, must not require prior authentication), enters the victim’s e-mail address and notes the code displayed. It does not matter if the page is encrypted or not because the attacker does not have to sniff the traffic. He just goes to the password reset page and issues a reset request.

      The attacker waits for the e-mail with the reset link to appear and clicks the link. They then provide the previously noted code and reset the password. If the attacker can not only read, but modify e-mails in the victim’s account, this can happen entirely without the victim’s notice.

      Basically, this tells us two things:
      1) A more contrived protocol is not necessarily more secure. ;)
      2) Password reset via single-factor authentication (access to an e-mail account is the “something you have” factor) is conceptually insecure.

      A bit more security is gained from using password reminder questions. If they are implemented right (i.e. not “What are the last 3 digits of your SSN”), they can provide the needed second factor for the authentication scheme.

  17. The next question is whether the coded URLs of the password reset links are predictable, i.e., could someone crack the code used on a website and predict what URL will be sent to them when they click a password reset link.

    Forum spammers can often predict the registration confirmation links that will be emailed when their bots register on a forum. They can then confirm the link without actually receiving the email. (That’s how that Random Digilante dude can change their passwords and add snarky vacation messages when he hacks their email accounts, yet they continue to be able to use those email addresses to register on forums.)

    If someone could do a password reset and go directly to the password reset link, they could lock you out of your account before you ever opened the email.

  18. Brian, I am in alignment with your position on the matter of plain text passwords sent in emails. What is your position on Google’s attempt at 2-factor authentication via cell phone text messages? My apologies if you have already posted a blog on this topic…

  19. BK,
    Nice article. Unfortunately I think we need more Lambasting of these Companies. Especially Banks in my opinion. Mine has some really Moronic approaches on some things. For example they don’t digitally sign the half of the login process. (They break up the username & password into seperate blocks like Bank of America). Its ridiculous; I’ve wrote two emails to Domain Admins & two to there Phishing Dept… With no success.

  20. omg, did someone from the FBI really recommend people use a password like “123ABCCHECKING” for their checking accounts, or did this columnist entirely misinterpret the lecture:
    http://www.philly.com/philly/business/20120619_Advice_for_investors_from_the_FBI_on_how_to_avoid_getting_scammed.html


Read previous post:
Apple, Oracle Ship Java Security Updates

There must have been some rare planetary alignment yesterday, because the oddest thing happened: Apple and Oracle both shipped software...

Close