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?
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
The inspector general of the navy should be informed, with a copy to the chairman of the armed services committee. Then run away. Fast...
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?
"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.
I just thought I should clarify this a tad bit for non-hams. (but the rotating password you provide is a good way to go)
It is not permissible to encrypt the message in a way which obscures the meaning, but can in a non-obscure way to verify the user is authorized. This is still not common, but possible. One such method with digital modes is to have the user use a private key to sign the message, and the control operator maintaining the station can have the corresponding public key. In a fashion similar to Echolink, an Amateur VoIP system, an operator can be verified by the service before being granted access.
Others have argued that on modes such as HSMM you can use WPA2 encryption as long as you share the key with any licensee who requests it, but this is still dubious, FCC hasn't said much on it, and the point of no encryption is that you can see who is talking with who.
There is one exception to the encryption rule, and that is for telecommand of Space stations on the Amateur Radio service. However, that space station cannot encrypt data back Down to Earth.
73!,
ke5tuz
(anonymous coward only because I'm on a corporate proxy which, while not prohibitive of slashdot, will log passwords). Normally I'd post under DaJJHman
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.
"I opened my eyes, and everything went dark again"
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.
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.