Slashdot Mirror
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?
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?
"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.
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.
This was one of the reasons I started using a password manager. No need to remember passwords to sites I rarely use and much easier to avoid using the same or similar passwords in general.
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.
In ham radio command and control over remote digital ground stations all have clear text passwords because it's against the law to encrypt on ham radio bands. So every password is a single use.
Today, if I connect to the digipeater that is near me I will use the password S4tA12fDg
and it will work once and only for a certain window for that single login to happen.
Any company worth anything would do the same. Here is your link, here is your one time use password, you had better get the file in the next 20 minutes or that password will not work.
Perfectly secure for simple crap that really has zero value like a school transcript.
Do not look at laser with remaining good eye.
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.
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
If you check with black hats, you will noticed that there are two tactics that they use approximately never:
- network packet sniffing, and
- break-ins to email
What they're saying by this is that passwords sent in the clear are not an interesting target.
Just trying to bring this conversation back down to earth.
What part of "A well regulated militia" do you not understand?
In 2015, passwords should be stored in a one-way hash. Preferably in the PBKDF2 format.
If the company is in any sort of regulated sector, this should be reported to their regulator
If the company is big enough to have an auditor - and that's pretty small - they should be informed
If it's a European company, then the Information commissioner https://en.wikipedia.org/wiki/... or the equivalent should be notified. This is clearly unsatisfactory behaviour
The inspector general of the navy should be informed, with a copy to the chairman of the armed services committee. Then run away. Fast...
1) Treat them like worthless things - only having them to satisfy those weirdos that want something called 'privacy', whatever that is. What the hell, use the same default 123 for all passwords.
2) Here is your top secret password. It must be 23 digits long, have symbols, letters, cyrillic characters and at least one unicode symbol whose name you don't know. Nothing can EVER be repeated, and it must change every 60 minutes. Also do NOT write it down - even though these conditions mean you absolutely have to write it down in order to remember it.
Honestly, you are talking about your transcript for a University. I can not honestly think of a situation where someone that you don't want to see it would care enough to see it - unless you yourself are planning on committing fraud.
If I was in charge (and I am not), the university should not use a password. They should let ANYONE see your transcript - but also notify you that someone has requested to see it.
excitingthingstodo.blogspot.com
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.
See that "Preview" button?
"Don't you know my name yet? That's the only answer. Tell me, who are you, alone, yourself and nameless?" — Tom Bombadil in Tolkien's Lord of the Rings
"There are only two hard things in Computer Science: cache invalidation and naming things." — Phil Karlton
This is one of the true hard problems in modern end-user computing, and it comes up all the time. What do you do when you get a phone call like, "hi, this is Don with $MORTGAGE_COMPANY. For security validation, please tell me your address."
How do you provide a way for two people (entities) to get introduced to each other in a reliable way, without a trusted third party to make the introduction? And, beyond that, if you have to create an "account" with me to maintain that relationship, how do we make that happen safely (another questions is why those accounts are so uni-directional; why doesn't the bank need to create an account with you as well?)
Most of the solutions to this problem favor us giving our personal information away for free to big companies, in exchange for some benefit which may never come. There's been talk for ages of having some sort of identity layer for the Internet, but that raises its own privacy and anonymity concerns.
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.
Comment removed based on user account deletion
The best password: ********
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.
Don't blame me, I voted for Kodos
...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.
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
Send an e-mail with a verification URL
How do you encrypt this unique verification URL on its way to the subscriber to your service?
security questions
I'm sorry; I misread this as "security theater questions". See "The Curse of the Secret Question" by Bruce Schneier and "Wish-It-Was Two Factor" by Alex Papadimoulis.
That just shows up as asterisks here...
Yep. I can type in my password all I want and you can't see anything but asterisks. So I can hunter2 all I hunter2 want and you can't hunter2 it
There are actually valid reasons for using two-way encryption in some scenarios. It's not ideal but it can be quite secure if managed properly. For example, most privileged user management systems and password escrow systems need to use reversible encryption. There are also reasons to do so in certain credential synchronization/SSO scenarios. Yes, just dumping encrypted passwords in a database is a bad idea. However, done right you can have two-way encryption and maintain security.