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?
Re:Responses
By chihowa
•
2015-Jul-2 14:27
• Score: 4, Insightful
• Thread
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?
Pearson is guilty of this
By bangular
•
2015-Jul-2 14:31
• Score: 5, Informative
• Thread
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.
Nobody cares about the password your transcript...
By toadlife
•
2015-Jul-2 15:17
• Score: 4, Insightful
• Thread
...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.
Re:Pearson is guilty of this
By TheCarp
•
2015-Jul-2 15:24
• Score: 5, Interesting
• Thread
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:Responses
By RingDev
•
2015-Jul-2 15:31
• Score: 4
• Thread
[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