Ask Slashdot: Dealing With Passwords Transmitted As Cleartext?

An anonymous reader writes: My brother recently requested a transcript from his university and was given the option to receive the transcript electronically. When he had problems accessing the document, he called me in to help. What I found was that the transcript company had sent an e-mail with a URL (not a link) to where the document was located. What surprised me was that a second e-mail was also sent containing the password (in cleartext) to access the document.

Not too long ago I had a similar experience when applying for a job online (ironically for an entry-level IT position). I was required to setup an account with a password and an associated e-mail address. While filling out the application, I paused the process to get some information I didn't have on hand and received an e-mail from the company that said I could continue the process by logging on with my account name and password, both shown in cleartext in the message.

In my brother's case, it was an auto-generated password but still problematic. In my case, it showed that the company was storing my account information in cleartext to be able to e-mail it back to me. Needless to say, I e-mailed the head of their IT department explaining why this was unacceptable.

My questions are: How frequently have people run into companies sending sensitive information (like passwords) in cleartext via e-mail? and What would you do if this type of situation happened to you?

Comments

Responses

[neminem]

"How frequently have people run into companies sending sensitive information (like passwords) in cleartext via e-mail?"

Not *that* often, but more often than you would think. (See plaintextoffenders.com - they've got hundreds of examples.)

"What would you do if this type of situation happened to you?"
What I do when this happens:
1. Take a screencap of the email, black out the username and password, and send it to plaintextoffenders.com
2. Contact the site admin, let them know that you just did that, and why it's such a bad idea. Link them to http://plaintextoffenders.com/...
3. Immediately change your password on the site to something stupid that would definitely not even *remotely* help an attacker guess what sort of passwords you might use on other sites, since if their password security is that awful, chances are their security is awful in other ways too.

Re:Responses

[Zontar_Thing_From_Ve]

"How frequently have people run into companies sending sensitive information (like passwords) in cleartext via e-mail?"

I see this and people sending both public and private PGP keys to outsiders more than I should from other companies. I assume it's because in general American businesses have devalued IT for so long that they're getting exactly what little they pay for now with barely trained and barely competent people who don't know anything about security.

Re:Responses

[chihowa]

My site, on account creation, generates a password and sends it to you in email in cleartext before putting it in the DB. In that email is a link to reset the password; you can't log into the rest of the site until you've done so. The updated password (and the original) are stored encrypted in the DB.

If anyone has a better suggestion, I'm all ears.

Seriously? Let the user enter their own password at account creation and send them an email with a link (containing a random hash that's indexed to that user in the DB) to verify the email address (if that's even a necessary step... it isn't always).

Why would you need to generate a password for them, especially if you're going to email it plaintext and make them change it anyway? What possible benefit does that serve?

Re:Responses

[sexconker]

My site, on account creation, generates a password and sends it to you in email in cleartext before putting it in the DB. In that email is a link to reset the password; you can't log into the rest of the site until you've done so. The updated password (and the original) are stored encrypted in the DB.

If anyone has a better suggestion, I'm all ears.

Don't send the fucking password in plaintext.
Don't store the fucking password. If your database/application can read it, then it's decrypted at some fucking point. Don't fucking do it.

User creates account.
User provides password, username, email, etc.
You generate salt.
You generate a UUID (emailverificationUUID).
You create DB entry with username, email, HASH(password + salt), salt, emailverificationUUID, emailverified (0).
You email the user "Your account has been created, please click this link to verify your email address.".
Link contains the UUID. When clicked, the site performs normal login processes (prompt login if not logged in already) and then verifies that the UUID matches the UUID stored for the logged-in user, and sets emailverified to 1 for that user if so.

Re:Responses

[omnichad]

If you don't salt your hashes, you're less likely to rust the undercarriage.

Re:Responses

[RingDev]

[quote]So how do you encrypt this UUID?[/quote]

You don't. It's just a GUID or some other low collision rate hash.

[quote]And what do you send for a password reset?[/quote]

You send them a new UUID in a link. When the link is hit, the UUID resolves back to their account and they are directed to enter a new password, just like a first time user.

The combination of time (the UUID can be time boxed), activity (a successful login nullifies the UUID), and possession (control of the account's registered email address), and if you want to get really wild, knowledge of a security question, creates a scenario where there are no good purely technical solutions for the attacker.

An attacker could, in theory, create a colliding GUID for an account they know the name of (but not password), manually enter the UUID link, and set the new password (assuming there is no security question).

But if an attacker manages to consistently generate colliding GUIDs*, they have accomplished something so monumental that they should be heralded as the second coming of Steve Jobs or something.

(*Assuming the coders didn't decide to come up with their own GUID generation algorithm that is easily reverse engineered and seeded)

-Rick

Re:Responses

[alexhs]

Ok, here are some possible benefits over chihowa's proposal, for specific use cases.

- If the use case implies a system/"real" account rather than a virtual one (which I admit is a bad idea most of the time), the implementation practically comes for free: simply create an initially disabled account with a generated password. Particularly useful if the bunch of account creation doesn't actually use an e-mail account at all (say, university students accounts, with account names and initial passwords printed)

- You don't have to develop a different UI to differentiate account validation and regular password change.

- Some (web)mail applications are breaking URLs. Often times systems using generated URLs contain a link, plus a textual representation of the URL in case the link doesn't work (which usually means a text client), and sometimes some kind of pretty printer likes to add spaces after punctuation signs. With a short static URL and a password, you're minimizing copy/paste issues.

Simple

[juanfgs]

What would you do if this type of situation happened to you?

I'd continue using different passwords for different accounts and not being a whiny bitch about it.

Re:Simple

[Anonymous Coward]

Don't mod down the angry bro just because he uses bad words.

The only safe assumption is to assume that no one handles passwords correctly. So you use a different password for every service. Use a password manager and let it generate random passwords for you.

The question one then to answer for themselves is if I assume they are not properly handling passwords, how much personal information is one willing to provide. You're on your own for that as everyone values information differently.

Security

[corychristison]

Your first example is acceptable in my opinion, as that password was probably random and (essentially) single use. After logging in, you should immediately change the password to something you can remember.

The second example, however, is a big no-no in my books. I develop web based applications for a living. The only time we send a password over e-mail (or SMS) is when a user has locked themselves out of their account, and are using the account recovery tool to regain access. This is how we handle it:
1. Click on "Forgot Password"
2. Enter your e-mail address (and username if different from e-mail address), click "Begin Recovery"
3. Send an e-mail with a verification URL for them to continue the process, this is to confirm they actually are the owner of the email address, and also to weed out people trying to use the recovery process maliciously.
4. Upon following the URL you will be prompted to answer two security questions you set up on registration from a set of predefined questions. You must answer both correctly to proceed. Internally, when this URL is hit, the account in question is flagged in the DB that it is now in Recovery Mode.
5. Upon answering the questions correctly, you will be e-mailed a single-use password you can log in with.
6. Upon logging in, you are required to change your password to something you can remember (or store in a password DB, like you should be doing).

I know it's long and cumbersome, but it works.

I used to see that all the time

[HangingChad]

Before NMCI came along, I was tasked with taking over a mapping application for the Navy and discovered the app was sending admin credentials in clear text in the URL string. Instead being of grateful I found the obvious sloppy coding they accused me of trying to pad my billing with make work and blaming the previous programmer. When I explained their application was crap and a giant security hole they would say, "Well, it works for us."

So I totally understand how apps like that make it online.

Re:Concern not warranted

[JaredOfEuropa]

If passwords are sent in the clear, they are kept in the clear (unless they are one-time randomly generated passwords). And if you check with black hats, you will note that they steal password files all the time. In most cases they'll end up with password hashes, which means they can spend some time and computing power to throw a dictionary at the file and see if any semi-obvious passwords come out. But if passwords are stored in the clear, they end up with everything, no matter how strong your password. And if you use that same password on multiple sites, you'll be in even more trouble.

FAO of inspector general - copy to Congress

[Bruce66423]

The inspector general of the navy should be informed, with a copy to the chairman of the armed services committee. Then run away. Fast...

Re:FAO of inspector general - copy to Congress

[xombo]

If you point out government waste or find out that the security practices required by the government contract were not met you can actually receive a % payment for the value of the difference won back in court. Try and work that route instead of just whistle-blowing. If you find the government was over-billed for services that weren't rendered (i.e. security) then you have a real case and there are official channels through which you can work.

policy

[Orgasmatron]

You don't control the security policy of most things that you need to interact with.

You should be assuming that every single site that is not under your direct and personal control is doing the same thing. Even if they swear that they are not.

Every password that you give to a remote system should be a unique random password given only to that system and saved in your personal password safe.

The one exception is having a common password for things that you don't care about. The trick to taking advantage of the exception is making sure that you really, really don't care about any of the systems in that category, and never will.

Pearson is guilty of this

[bangular]

I forgot my password on a Pearson website, so I did the whole "forgot password" thing. Low and behold I receive an email with the original password I chose.

Re:Pearson is guilty of this

[TheCarp]

One of the last companies I worked for was undergoing a single signon project. In their presentation they made it quite clear that they were actually encrypting passwords with a two way function. After the main presentation I pulled the presenter aside and asked why when hash functions are the industry standard.

His response was kind of hillarious (and kind of sad).... too many IT managers were afraid of the repercussions of not being able to actually recover an executives password if he actually lost it and had used it for something important that couldn't just be reset.

Re:Happened to me once with a magazine subscriptio

[i.r.id10t]

They didn't salt and then hash their copy of the passwords - they are still stored plain text. They just stopped including it in your email.

Nobody cares about the password your transcript...

[toadlife]

...or your job application.

Because of the low value of the data that the password grants access to, lax handling of the password is acceptable.

Now if the password granted you access to everyone's college transcript or job application, then how it was handled would certainly be important.

Different types of data have differing security requirements.