87

I recently received an email from a popular graduate job website (prospects.ac.uk) that I haven't used in a while suggesting I use a new feature. It contained both my username and password in plain text. I presume this means that they have stored my password in plain text.

Is there anything that I can do to either improve their security or completely remove my details from their system?

UPDATE: Thanks to everyone for the advice. I emailed them, spelling out what was wrong and why, saying that I will be writing to the DP commissioner and will be adding them to plaintextoffenders.com.

I got a response an hour later: an automated message containing a username and password for their support system. Oh dear...

Community
  • 1
jamesj
  • 1,093
  • 1
  • 8
  • 10
  • 18
    And for added bonus points, what to do when the owners of the system claim/state that it's Industry Standard to do so? – Jon Feb 03 '12 at 00:00
  • just do not use your favorite password **tyrFTgjh432#@@** on unknown (any) sites. They can do not send your password in plain text, but still store it in plain text (view, sell...). – garik Feb 13 '12 at 19:59
  • Related: http://security.stackexchange.com/questions/4997/is-it-a-bad-idea-for-an-information-holder-to-e-mail-a-user-their-password – Steve Melnikoff Aug 24 '12 at 16:12
  • A bit late, but this is relevant: http://www.troyhunt.com/2012/07/lessons-in-website-security-anti.html –  Jul 04 '13 at 12:02
  • This is also a bit late but might contribute something to the community. https://pogsdotnet.blogspot.sg/2017/06/risks-associated-with-plain-text.html – Allan Chua Jun 04 '17 at 13:12

11 Answers11

54

There isn't really much you can do, other than contact the website and try and explain them how bad of an idea and practice it is to store (and email) passwords in plain text.

One thing you can do is report any offending site to plaintextoffenders.com - a site (currently a tumblr blog, but we're working on a proper site soon) which lists different "plain text offenders" - sites that email you your own password, thus exposing the fact they either store it in plain text, or using a reversible encryption, which is just as bad.

With everything that's happened with Sony, again and again, people become more aware to the dangers of sites storing sensitive details unencrypted, yet many still aren't. There are over 300 sites reported, with more reports coming every day!

Hopefully, plaintextoffenders.com helps by exposing more and more sites. Once this gets enough attention on twitter or other social media, sometimes sites change their way, and fix the problem! For example, Smashing Magazine and Pingdom have recently changed the way they deal with passwords, and no longer store nor email the passwords in plain text!

The problem is awareness, and I hope that we help the cause with plaintextoffenders.

Igal Tabachnik
  • 656
  • 5
  • 5
  • 7
    As I am based in the UK would I be able to suggest that they are in breach of the data protection act? – jamesj Sep 13 '11 at 19:04
  • @jamesj: I really don't know, unfortunately! – Igal Tabachnik Sep 13 '11 at 19:07
  • 1
    Nice idea with this site! Once you move to a proper site (or even before, if possible) you could add a section of "converted offenders". I hope that such a section would not stay empty and be an additional incentive for sites to fix their problems. – Joachim Sauer Sep 14 '11 at 06:03
  • 1
    @jamesj IANAL, but it looks like it may breach [the seventh principle](http://www.legislation.gov.uk/ukpga/1998/29/schedule/1/part/II/crossheading/the-seventh-principle) (see "accidental loss" in 9a). – deizel. Sep 14 '11 at 12:08
  • @jamesj - it's certainly worth letting the DP commissioner know; try to write a short clear easy to understand letter (on real paper) for them. Don't expect too much though. :-( – DanBeale Sep 14 '11 at 18:47
  • @DanBeale Thanks I will do that. This website is recommended by almost every university in the country so I imagine most students and ex-students have signed up to it at some point. – jamesj Sep 14 '11 at 19:00
  • @IgalTabachnik, Where do you get your statistics for "there are over 300 sites reported, with more reports coming every day"? – Pacerier Jun 05 '14 at 08:06
14

Storing a password in plaintext is not really an issue -- at least, much less so than sending the said password in a plaintext email !

This email just proves that the web site administrators are not very careful with the information you entrust them with, and that's a good reason not to entrust them with any more data.

Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • 1
    Can you elaborate a bit on why it's not an issue? I (along with millions of others) have a strong pwd that I use for many things. If everyone is doing their job and hashing then should I have to worry about my PWD being in plaintext and a disgruntled employee seeing it and using it to get into any one of my many accounts (My bank/other important passwords are different because of this). But making passwords visible to anybody seems like an issue and I'm curious as to why you say it's not because you are in fact the resident expert :) – Dan Drews Apr 16 '14 at 16:54
  • 9
    As I said, it is _less_ an issue than the sending out as an email. But this highlights the need for site-specific passwords. I _never_ use the same password for two distinct services -- and you should do the same, because you cannot know how (in)competent the sysadmins of any site are. They may store the password in plaintext, or, even worse, send it by email to poorly validated addresses. – Thomas Pornin Apr 16 '14 at 17:13
  • 7
    Storing the password in plaintext is a *huge* issue. LinkedIn got their credentials database stolen and over 6,000,000 user accounts were compromised. Those passwords weren't even stored in plaintext, but were hashed with SHA-1 without "salt." **HOWEVER**; I profoundly agree with you that this practice means that site is not worthy of you entrusting any more data with them. – Craig Tullis Aug 16 '15 at 18:21
  • 1
    Storing plaintext passwords is absolutely an issue. Who knows how many employees have access to their databases who are one bad day away from abusing all those plaintext passwords. The company does not need to know and should not know any user passwords. Period. – Nathan Adams May 26 '19 at 16:51
9

Use a different password for each site. That way, when the password is compromised (whether by snooping on plaintext email transmissions, or even if a database with properly hashed/salted passwords is cracked), the attacker will only be able to access your account on that one site, rather than on all sites on which you have similar account credentials.

...and so you don't have to remember a zillion passwords: Stanford's PwdHash is a handy browser extension that automatically generates unique passwords by hashing a common password you enter with the site's domain.

smokris
  • 199
  • 1
  • 2
  • 5
  • See also the similar supergenpass options: [Is the Bookmarklet Password Generator from SuperGenPass.com safe to use? - Stack Overflow](http://stackoverflow.com/questions/554224/is-the-bookmarklet-password-generator-from-supergenpass-com-safe-to-use) – nealmcb Sep 14 '11 at 20:04
3

Send them one email asking to be removed from their database.

Don't give any more information about you to them

Be sure to not have that password used anywhere.

woliveirajr
  • 4,462
  • 2
  • 17
  • 26
  • 3
    I have the feeling that anyone so negligent about security would, at the most, mark your database entry as inactive. I don't see any way to have assurance that your plaintext password is no longer available to all and sundry--the easiest way would probably be hacking in and deleting it. – user502 Sep 13 '11 at 18:32
  • perhaps changing the password a thousand times, just in case it's stored somewhere to prevent that "don't repeat your last 3 passwords" – woliveirajr Sep 13 '11 at 18:52
  • 1
    @woliveirajr Doing it a _thousand_ times would probably trigger DoS protection. – forest May 24 '19 at 00:22
3

That's why it's recommended to use another password on each site.

Try to e-mail them to delete your account. Otherwise do not use that site and really, use/generate another password (and long one!) on each site you're registering to. You never know which ones store plain passwords into their database

genesis
  • 718
  • 6
  • 15
2

I would say since the password is out there for the world to see, just update it to a password that you are not using anywhere else. Thus no one can hack your information on any other site using the password on this site. Example could be if your email is your login and you are using the password on this site as a password for your email.

Other than that,if you would like to offer to help the website with storing passwords effectively and send them the link of this stackoverflow thread.

pal4life
  • 177
  • 1
  • 8
1

If it's transmitting passwords in plain-text, it's a "vulnerability".

The first step is to find proof, such as by running Wireshark to capture the passwords as they are sent on the wire.

The second step is to contact the company, such as by sending e-mail to "secure@example.com". The email addresses "secure@" and "security@" are the email boxes companies set up if they are concerned by such discoveries.

Save the responses you get from the company.

When it becomes obvious that the company isn't going to fix it, then post a message to the "full-disclosure" mailing list. Succinctly describe the problem, show the proof, and show the response.

Read email postings to the full-disclosure list in order to see how other people have done this.

Robert David Graham
  • 3,893
  • 1
  • 15
  • 14
  • 2
    "The first step is to find proof, such as by running Wireshark to capture the passwords as they are sent on the wire." — that won't prove *anything*. To sign up and log in, you obviously have to send your plaintext password to their servers. How else could the server process the password and authenticate you? The real problem is passwords being *stored* as plaintext in a database. – slhck Apr 13 '15 at 12:08
  • also, it's likely the site runs on https, so you'd need to MITM the connection to sniff and capture the login credentials – sox with Monica May 24 '19 at 09:45
1
  1. Don't use a system you can prove is insecure if you need it to be secure.
  2. Contact the company/owner responsible for developing the system and share your proof of its insecurity.
  3. If you get an unfavourable response from the company/owner that amounts to them being unwilling to correct the system to be secure to your satisfaction, move to another system.
Bernard
  • 201
  • 2
  • 5
1

What are best practices in dealing with that system :

Don't use that system with sensitive information. Consider what would the problems for you if there is some data leakage, or if someone begins to use the system with your login. If it's a no-go situation, stop using the system.

[best practices in dealing] and the owners of that system :

Register your insatisfaction using email and any other means of contact: customer support, phone call, contact emails, foruns, blogs, wikis...

while minimizing risk to yourself via the use of the system :

if you consider that you will use that system anyway, then don't use the same password for that system and any other system. If you can not use your email as a login, even better.

or reporting of the related issues?

the same other answers have told you: register all your complain, stop using it.

woliveirajr
  • 4,462
  • 2
  • 17
  • 26
0

Changing the password has been suggested already. Changing it to "do not store passwords in plain text, you lamers!" and then e-mailing them asking to remove your account and delete all personal data might help your message being heard.

Apart from that, passwords in plain text are not that much of an issue since even hashed password databases can be bruteforce-attacked in a reasonable amount of time nowdays, especially if the hashed data does not contain any salt.

syneticon-dj
  • 184
  • 6
-7

There is nothing wrong with storing plaintext passwords. In fact, in some ways it is the best solution.

[not] storing passwords in plaintext limits the security of communications.

it is more secure to send passwords encrypted over the network, and store them in plaintext on the database, than sending the passwords in plaintext over the network and store them encrypted on the database.

In other words, the server needs to know the user password to support the most secure authentication mechanisms.

source: ejabberd Book, chapter Store passwords in plaintext in the database for security (link)

Community
  • 1
user7610
  • 217
  • 1
  • 9
  • Message to downvoters: don't just downvote, say why you do not like my answer. Storing passwords in plaintext is a good and common practice in the Jabber world. – user7610 Dec 08 '14 at 16:03
  • 5
    If this is specific to a product, the answer should say so. Otherwise, this is a dangerous and misleading answer to put here. Storing it as a plaintext is **never** more secure than storing it hashed. Working around a limitation of a product is not being more secure in general. – Chris Murray Dec 08 '14 at 17:22
  • 3
    Further, the person who wrote that "book" (rather, an FAQ on a website) doesn't seem to understand security, or the importance of hashing passwords. No competent programmer (with an understanding of security) would advocate either plaintext *or* encrypted storage of passwords. – Chris Murray Dec 08 '14 at 17:26
  • @ChrisMurray Plaintext gives you the possibility to upgrade your authentication scheme if something better becomes available. Sometimes you are not able to perform the upgrade if you have stored is the hash. Then you have to keep using the old, less secure authentication scheme. – user7610 Dec 08 '14 at 20:01
  • @ChrisMurray In addition to that, plaintext gives you the flexibility to use multiple auth methods for different things. Let's say that I want to authenticate visitors on my webpage with HTTP Digest. I need to have plaintext passwords for that. – user7610 Dec 09 '14 at 09:03
  • that makes no sense. Why would you want the same user with the same password signing in with a lower level of security than normal? The lower level becomes your weakest link and is precisely where an attacker will strike. If something needs to be secure, it needs to be actually secure. There's no point in using a password at all if it's going to be exposed as plain text, as this will remove all security and leave a **false** sense of security, which is arguably worse than having **no** security. – Chris Murray Dec 09 '14 at 10:55
  • Exactly. Encrypting or hashing the passwords leaves you with a **false** sense of security. With encryption, the attacker will probably get to your passwords *and key* at the same time. And any hashing scheme will be broken eventually, given enough compute power. With plaintext, you always know where you stand. There is no pretense of endpoint security. Endpoints will be insecure whatever you do. Look for example at the recent well publicized SSL bugs. Instead, focus on securing the communication, which is the only area where you stand a chance to make a meaningful increases in security. – user7610 Dec 09 '14 at 11:11
  • hashing is not the same thing as encryption. Hashing is not reversible, and there is **no** key to be gotten. – Chris Murray Dec 09 '14 at 12:05
  • 1
    To properly understand hashing, go read Thomas Pornin's excellent answer [here](https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords) – Chris Murray Dec 09 '14 at 12:22
  • I never said anything about keys when I spoke about hasking. All I said is *And any hashing scheme will be broken eventually, given enough compute power.* and I stand by it. – user7610 Dec 09 '14 at 13:47
  • 1
    And any lock can be picked, given enough skill and time. Should we not bother locking our doors? – Chris Murray Dec 09 '14 at 13:57
  • I wouldn't compare hashing passwords to locking house doors. It is more like installing bars on windows, something "extra". And yes, you should not bother installing barred windows if you have just a cheap lock on your door and the door can be easily kicked open anyway. Web apps usually have ton of problems with web security: XSS, SQL injections and so on. One should focus on that and not waste too much time on what is essentially obfuscation. Chrome browser developers know that https://news.ycombinator.com/item?id=6166731 – user7610 Dec 09 '14 at 14:07
  • 4
    You do not understand hashing if you think it's "essentially obfuscation". You **cannot** reverse a hashing function. Yes, it is worth focusing your time on the most critical vulnerability in your app, but that doesn't mean that you can ignore all other failings. Storing a password in plain text is **never** better than storing it hashed, and you haven't given any examples to the contrary. – Chris Murray Dec 09 '14 at 14:33
  • Sure I can. I can bruteforce it. Since the input was not not uniformly distributed ('password1' is more likely than 'asd865$*sdf.aa'), I stand a good chance of getting reasonable results reasonably quickly. – user7610 Dec 09 '14 at 14:42
  • *Storing a password in plain text is never better than storing it hashed, and you haven't given any examples to the contrary.* You are right. It gives everybody more time to react should a leak happen. People tend to reuse passwords, so this is certainly valuable. I'll delete my "answer" lest I get even more downvotes. – user7610 Dec 09 '14 at 14:44
  • 1
    The main use of keeping unhashed passwords is that you can do some challenge-response type authentication (like HTTP digest which someone mentioned, which is useful over unencrypted connections), however, TLS with free certificates makes that less necessary... – Gert van den Berg Jun 20 '16 at 20:31
  • -1. `it is more secure to send passwords encrypted over the network, and store them in plaintext on the database, than sending the passwords in plaintext over the network and store them encrypted on the database.` This is a false dichotomy, since nothing says the password must be transmitted in plaintext if stored encrypted. The password must be sent (in plaintext) **over an encrypted channel (TLS)**. There are also a lot other wrong statements in this answer and relative comments, but this should be enough to qualify this answer as utterly wrong. – sox with Monica May 24 '19 at 10:03
  • _You cannot reverse a hashing function._ That is simply not true. Every hash function must have colliding inputs. Given enough compute power, you can find a collision with the password. Which is just as good a result. – user7610 May 24 '19 at 10:32
  • 1
    Finding a collision != reverse the hash. That is very true if you use the right words for the things. And please explain to me how a **theoretical** cracking of the hash (good luck bruteforcing `scrypt` or `argon2`!) means that storing the password in plaintext is "nothing wrong". It's like saying that since your house door can be picked given enough effort, there's no use in locking it when going outside. That is simply not true. – sox with Monica May 24 '19 at 10:51