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.
I am a security auditor, and this happens all the time. For non-IT company, If they changed default credentials they are already ahead of the curve.
It used to be scarily common, but I believe that it's slowly phasing out in favor of hitting a website where you can (re)set the password yourself after a couple of security questions.
I believe it's just a sign of old code (or an old coder) on the site. There may be cases where the guy writing the sitecode is inexperienced or incompetent, but I like to think that such cases are rare.
I think I only see a cleartext password sent via email like once every 10 requests now.
Quo usque tandem abutere, Nimbus, patientia nostra?
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.
I just assume that every system is insecure and try to isolate fallout when one of my passwords is compromised. Specifically, use a different password for every auth system. That way, you minimize damage when one is inevitably compromised.
That being said, I think we should really have stricted laws in place that require companies to not store their users' passwords in clear text, so we have a legal recourse against this kind of insane practice.
What about a college resetting your password to something to the last four of your SSN and sending it in plain text via email?
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
You ever type your password into the username field by accident and hit enter and so it does get transmitted and enters the server log as a failed attempt with username = YourPassword
Ouch. Have to change then.
applying for a job online sucks in many other ways I hope you hear back from the real IT person and are able to send them an resume that is not lost in a bot system or is loaded with keywords to get past them.
That is the reason their kind does this. They rule the vast majority of corporations so they force poor security practices from the top down. It is the way of their kind.
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.
Do you know if it was sent by TLS? Frequently encryption is disabled if opportunistic TLS is available since encrypted e-mail can be quite a hassle.
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
No one gives a fuck about your brother's transcript. It is not Important. On your job app, can you change it? I bet you can which nullifies your whining. If it was your bank account, yeah complain, but don't waste other peoples time on pedantic shit that doesn't matter.
The inspector general of the navy should be informed, with a copy to the chairman of the armed services committee. Then run away. Fast...
True, but what the OP doesn't understand is that PBKDF2 could very well be used to store the password in the database and they are just sending the email, securely over SSL, with a non-hashed version of the password before storing it hashed. It's pretty common during registration processes. Whether it's a good idea or not depends entirely on the application/business.
It's your only defense. Once a password is sent in the clear it's ruined for other uses. So you must assume this will happen and never reuse one.
http://lkml.org/lkml/2005/8/20/95
I'm assuming you checked the message headers and noted that TLS was not implemented and that the message and password were not encrypted during transit.
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?
I subscribed to the electronic version of a magazine. Each month I got an e-mail to alert me to the new issue and the e-mail included my plain text password. I contacted them and explained to them why this was a problem. They agreed and got in touch with the company providing the e-magazine service. It took two months, but they stopped the practice. So I think you should just politely inform people.
soylentnews.org
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.
You don't know that for sure. It's entirely possible that the password was generated, sent to you in the clear, stored hashed and the clear version discarded. They can only do that once. If they can do it more than once, it's not being hashed before storage.
The problem with passwords is that at some point, it has to flow in a form it can be read by a human. We're not to the point where everyone on the planet can do everything with key pairs that prevent it.
"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.
I get a dozen a week like this. User name and document url in one email, password in another email. Link (once accessed) is good for 48 hours, usually. Or a variation on that where the PDF itself is secured. Then you have to download the PDF wrapper and use supplied name and password. Then the fun of getting the PDF into the document management system begins. Can't import secured PDFs, so it gets printed and scanned in or it has to be converted to TIFF or printed to XPS then reprinted to PDF to import. Can't do it in one step with PDF, unfortunately.
Of course, those are more secure than the helpful school counselors that just send us documents in email with no security. Or students who send us financial documents in email. Or admissions counselors insisting upon using such tools as free MediaFire accounts to transmit sensitive documents (because it wouldn't fit in email!). We have policies in place, but nobody listens.
12 rounds of each, enjoy your uncrackable passwords!
Posting this anonymously because... well... our system is a cobbled together mess that started in the mid-90s. Passwords are stored in the clear in the database, so aren't case sensitive (logging in is a stored proc), and the password field is a VARCHAR(8). Yes. Eight. Passwords aren't a minimum of 8 in our system, they're a maximum. Due to complaints, we allow passwords longer than 8 on the front end, though... we just truncate them down to eight on the backend. So "scret123" is the same as "SCret12345".
Well, sorta. Maybe from your ISP to you if your email client supports it.
But the ISPs have to be MicroSoft compatible, which only uses clear-text email.
Comment removed based on user account deletion
Probably not. Nothing that hiring managers like less that people telling them that they are idiots!
I use "[password redacted]" for my password for this very reason!
Which has more power: the hammer, or the anvil?
Every month, on the 1st, I get an email reminder that I'm on the CentOS mailing list with the subject "centos.org mailing list memberships reminder." And in that email is my password, plain text. And every month I shake my head as I'm reminded of how bad of a practice this is -- not only do they not use hashes but they also choose to email the password out regularly. Really CentOS!? I realize this is probably some old mailing list software and it's not protecting any sensitive data, but still, it reflects poorly on the organization that chooses to use it.
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
"You have sent me the password of my account in clear text. This is a security issue as passwords sent out in plain text can easily be intercepted and abused by a third party.
As your company has demonstrated a total lack of security awareness, I cannot trust you to safely handle my credit card information. As such, I will take my business elsewhere and will not be purchasing my PC at your company."
My policy on security questions is to use algorithmically generated answers based on the text of the question itself (which can be relied on to be invariant); thus there's no risk of an imposter guessing them, nor do I need to store the answers anywhere. There are enough different ways to hash the questions, and the practice is sufficiently uncommon, that it's a very low-risk strategy.
Got back home from doctor's appointment this afternoon, and when I checked my email, I noticed I got a message from a healthcare portal associated with my doctor's medical group. In the message the portal not only assigned my username, but it also listed a temporary password that's good for 30 days! All of this transmitted cleartext. Since I have no interest in using this portal, I contacted via email the company managing it and told them to delete my account because I didn't trust them to secure my medical information. I've yet to hear back from them.
If you assume that the only communication channel the company has with you is email (which is generally a pretty good assumption as multiple channels or channels that include humans are expensive), there isn't really any other choice but to send the credentials (password) in plain text.
This is not a new problem. For the entire history of secure information transmission (cryptography), one of the hardest issues to solve is the issue of initial secret (key) exchange. This problem has been around a lot longer than computers have.
To actually be secure over email you would need the end user to provide a public key when they request the password and then have the company encrypt that password with the public key. The user would then decrypt the password with their private key. This can all be done with S/MIME, but would be a pretty tall order to expect that a random user would be able to figure out how to obtain and use a personal email certificate.
You could split the password into multiple parts and send each part in a separate email or separate the account and password into different emails. These are decent options but don't really provide true security against a targeted attack (someone sniffing the network or directly accessing the email server). These do provide a reminder to the end user that security is important. I would suspect that targeted attacks are not that common.
You could try and obscure the password by making it really long garbage string or embedding it in a URL, but it still ends up being a password in plain text. These don't add any security and may instill a false sense of security.
If a second channel is not cost or support prohibitive, then a one time use text message (SMS) or automated phone message is a pretty good option.
If the password can be retrieved in an automated fashion then even if its encrypted, everything necessary (i.e. the key) is present, so if the host is compromised the passwords effectively are plaintext as the attacker can simply run the same process to decrypt the password.
And even if you use SSL to check your mail, that doesn't change how the email has been transmitted from one mail server to another, which is often done without using SSL, and most mail servers will fall back to plain text even if they do support SSL because so many out there don't support SSL at all.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
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
But how would you encrypt "a random hash" on its way to the e-mail recipient?
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?
Because this one-time random password serves precisely the same purpose as "a random hash" that you mention.
If you want a bit more security than this you could do something like text the user the token instead of baking it into the URL.
But how do you send a text to the number "I don't have a cell phone" or to a land line? I tried to send the code to a land line on a couple sites and got "Unsupported carrier".
... would be "kinda OK" in my book. (if the description is correct)
After all, it was NOT a password "linked to an account", but only a password to "access a document".
If you have documents that you have to give to a few thousand people, then a possible approach would be to just put them on a web server, protected by HTTP authentication. Then when a user wants the document, create a username/passwort, mail that to the user, and then perhaps a month later delete the username/password pair.
Probably works fine for documents that are not "really that secret" but you still don't feel comfortable putting on the open web for any search engine to find.
I'm an attorney. Every year, the state bar sends out (via postal mail) a license renewal reminder to all of their registered attorneys. The reminder gives the URL to visit for online renewal, and then lists the attorney's username and password.
So, every year the state bar mails out the credentials for all of their users.
...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.
And your method won't work if somebody "fixes" the question because of a typo/change of phrasing/to make it clearer/whatever reason.
Get free satoshi (Bitcoin) and Dogecoins
Exchange has supported TLS for SMTP connections since at least Exchange 2003. There's no reason to not use it anymore.
I'm a sysadmin. I send lots of passwords to users (on account creation, that is). Got tired of sending them in clear text (since they don't do GPG/PGP), or spelling them on the phone. So I created a simple php application that, under SSL, will encrypt your message on disk and offer it ONLY to the first visit (the message is destroyed on first read). I've been using it since, best bunch of hours spend on code. There: https://onetimepaste.org/
EOF
The questions we ask are not something that would normally be found in a users inbox
A lot of time, the answers to security theater questions are things that would be in a user's Facebook timeline, such as the name of the middle school that the user attended.
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.
Really? Of course they will send you a reset password in email. The other option is that or a link.
Ideally it is only good for a single use and you then enter a new password.
How else would you do password recovery?
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
In the message the portal not only assigned my username, but it also listed a temporary password that's good for 30 days! All of this transmitted cleartext.
This use of a one-time, soon-expiring autogenerated password is common in flows that include the step "To reset your password, confirm your e-mail address" or "To opt in to e-mail notifications, confirm your e-mail address". Is there an alternative, other than to either A. mail all customers a second factor of authentication used to reset a password, or B. require all customers to subscribe to mobile phone service with unlimited texting to receive resets through SMS?
I wasn't talking about password retrieval, neither was OP. If a forgot password or retrieval process is sending original passwords, then yes security is lacking and most likely stored in plain text without encryption or weak key encryption. He is complaining about a plain text password emailed during a registration process, which is extremely common and does not mean the password is actually stored in plain text. This is OP's misconception and lack of understanding. They could just be sending it before hashing and storing. If he's not even choosing a password and it's auto-generated, what does he expect to receive? Apparently OP wants his passwords from form data to be magically hashed before even being transmitted and magically work with whatever system they are stored in. It has to exist in plain text initially and that is what OP fails to realize.
I recently got a payslip emailed to me. This was full of information I didn’t want to see published and, as far as I could see (IANAL) was in breach of our Data Protection Act (in UK). I emailed the company to say that I thought this was not a good idea: it was potentially a risk to staff and gave the company legal exposure. My contact responded by saying he could stop them sending mine by email in future. I thanked him and asked him to notify information governance: if there isn’t one, then HR: no response. It worries me that the simplest data protection policies are so hard for some people to understand.
Or you can use pdftk to remove the arbitrary pdf restrictions and get a plain normal pdf file out of it...
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Here's my user name and password emailed to me in the clear by Slashdot, though it was 1999:
From slashdot@slashdot.org Fri MMM DD HH:MM:SS 1999
To: --------@-----------
Subject: Slashdot user password for ---------
The user account '---------' on http://slashdot.org has this email
associated with it. A web user from 123.45.678.9 has
just requested that password be sent. It is '----------------'.
You can change it after you login at http://slashdot.org/users.pl
If you didn't ask for this, don't get your panties all in a knot.
You are seeing this message, not "them". So if you can't be
trusted with your own password, we might have an issue, otherwise,
you can just disregard this message.
--Rob "CmdrTaco" Malda
malda@slashdot.org
Don't ever store passwords (reversibly) encrypted. Don't even (just) hash them; hash functions are way too fast (and yes, fast is bad here). There should be no way for anybody to get the password out of the info stored in the database, even if they know all your keys.
Use a slow key derivation function instead. PBKDF2 is popular, because it's easy to understand and widely supported; it's basically just taking a value (the password), salting it (you are using a strong, cryptographically random, per-user salt... right?) hashing it, salting the resulting digest again, hashing the salted digest, and repeating the last two steps over and over (tens of thousands of iterations are common). At the end of that, you compare the resulting digest to the value stored in the database; if they match, the user is authenticated. Obviously, don't try implementing this yourself; even simple crypto should always be written by an expert, and you should use the resulting library. There are lots of places to find it, though.
Alternatively, you can use the purpose-built algorithms like scrypt or bcrypt. These are more complex (and less widely implemented) than PBKDF2, but they also offer more advantages against brute forcing, such as requiring a lot of RAM during the computation so you can't build a massively parallel hash-cracking machine (a commodity GPU can do billions of hashes per second in parallel; these algorithms make those parallel attacks harder).
There's no place I could be, since I've found Serenity...
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)
My concern is how to keep someone between your server and the subscriber's MUA from compromising "possession", or how to establish "possession" the first time.
Assuming the coders didn't decide to come up with their own GUID generation algorithm that is easily reverse engineered and seeded
I just use a PRNG. If I need it as a GUID, I request 120 random bits and format them as a type 4 UUID. Is that good enough?
I used to keep my /. password in my IMAP folder. For years I would just search for the old mail instead of memorizing it or writing it somewhere safe.
"Not too long ago I had a similar experience when applying for a job online (ironically for an entry-level IT position)"
That would likely be Tek Systems Inc he's referring to. You know, one of the largest IT staffing company in the US. They did precisely that to me as well. I changed my password immediately to one I don't use elsewhere.
There are legions of sites out there that will shoot you an auto-generated password over plain e-mail: hell, even Google (as in, Google Apps) will do it.
The question is user responsibility and importance. If you're signing up for something, you should pretty much be there to complete the process, log in, and change your credentials.
99% of places where it happens, literally nobody gives a shit. Sorry, but access to some random putz's social media account is not a serious security problem, and it's probably not worth the massive support headache that an actual secure method of credential issuage/distribution would cause.
College transcripts? Admittedly, I haven't been in college in forever. Unless there's something like an SSN floating about on the document, well, seriously? Nobody cares. Same with job applications.
Yes, in a perfect world, all of our data, no matter how trivial, would be locked away behind quantum multi-phasic encryptowoo. It isn't a perfect world, and it's rather understandable why nobody's willing to wait three weeks for an RSA-type token device just so they can tell the Internet what they had for dinner.
fairly normal practice is to generate a random password, email it to the user and hash it and store the hash. The user can then log in and change their password to something of their own choosing, but the start point is just sent through a different channel. The big problem is if the service can tell you what your password is, or repeat the email, or resend you your password - that means it is stored in the clear. If they can reset your password and send you a new random password then that is OK (ish, not perfect, but we don't live in a perfect world)
There's better options than PBKDF2, like scrypt. Also, both require you to chose some parameters; PBKDF2 with a salt of String.Empty, hash algorithm of MD5, and iteration count of 1 is... just an MD5-hashed password. Obviously, those are terrible and stupid parameters, but if people were *good* at choosing secure options then this whole thread wouldn't exist. At least scrypt *only* has the work factor, and it's pretty straightforward.
There's no place I could be, since I've found Serenity...
I Like this. It beats the heck out out of email and it is far more convenient than a phone call.
Good job!
Is an email with a plaintext password that much more dangerous than an email with a reset password link?
Granted users are stupid and will use the same passwords everywhere... but for me I really don't care - I use randomly generated passwords for nearly everything and two factor authentication for passwords I need to personally type in.
"What I found was that the transcript company had sent an e-mail with a URL (not a link)"
I thought a URL was a link, what other kind of link are you referring to?
You're right that it's normally easy enough to find the answers to questions like "what high school did you go to?" I make that much more secure by secretly replacing "you" with "Barak Obama".* I don't enter MY high school, I enter Obama's. I enter Obama's mother's maiden name. So anyone who goes on my Facebook** to get answers will get wrong answers.
* I actually use another famous person, not Obama.
** You won't find much on my Facebook page, because I don't use Facebook. But if I did, it wouldn't show the answers I use.
The KDE mailing lists do this.
It's still bad, regardless of how it is transmitted. If they have access to your plaintext password (which they would, if they mail it to you), that means if their database is compromised, so is your password. And since many people use the same password on all of their online accounts, the attacker can go searching for other places they can use your password, such as gmail or your bank.
Why does every site think it is worthy of its own username/password?
Just use oauth2, give them a nascar login, and let them auth against whatever provider they want.
You store an id that is completely useless for anything else even if it were compromised.
Here's an example: while applying for a job, I was required to use docusign.net. This site carefully offered the option to use paper for all communications, while explaining that doing so would increase processing time considerably. I elected to fill out the application, which contained plenty of highly confidential personal information, electronically. However, when I signed it, docusign.net then EMAILED ME COPIES OF THE DOCUMENTS IN PLAIN TEXT.
Nowhere on the site was there a warning that this would occur, an option for using encryption for email communications, or an option to download completed documents rather than having them emailed.
From this I inferred that the customers of docusign.net are their client entities, and the people who fill out the documents are [fill in your favorite term].
My response? I questioned the integrity of the organization to which I was applying, and vowed never to do anything through docusign.net again.
Stop stalking APK, join the discussion or go away please.
..Mullah or Pope, Preacher or Poet, who was it wrote: "Give any one species too much rope and they'll fuck it up"?
Signed up for UVerse, got it installed a couple weeks ago. 2 surprises. First, I got a "welcome to ATT UVerse" email that contained my account password in cleartext. Not cool UVerse.
Then I logged into my router at 192.168.1.254. There on the welcome page was my wifi password for all the world to see.
It's turning out the UVerse DVR is a steaming pile, at this point I can't really recommend it.
Veda - the Australian credit reference company - sends people their full credit history file as a PDF whose password is their date of birth.
You'd think that because they have the official government approved monopoly on credit scoring in Australia they'd have their act together a bit more than that, but nope...
I signed up to get my medical records from my doctor only to find out that they sent a URL that pointed to an image of my password! Anyone could, and I did start creating/incrementing the URL number contained in the address and get other passwords. I donber
called ParentVue /StudentVue emailed me my password in cleartext after I clicked the "forgot password" link once. I sent the sysadmin (no actual help or other contact available) an email, and he explained that they store the passwords using a reversible hash. Puh-LEEEZE.
XM is the worst.
You can call them, simply give a phone number and they will tell you the password over the phone.
Virtually all pay porn sites send you your login credentials in clear text when you signup.
I run a company, a tech company, and I actually insist that most passwords be easily sent to clients in plain text.
I'm not talking about credit card information, obviously, nor control of any nuclear facilities. We're usually talking about invoices, business-administrative panels, business reports, and even financial reports. And, believe it or not, even e-mail passwords.
It's certainly not more secure. Especially those last two.
But I drive very fast on highways with other cars driving very fast, and the only thing separating us from 50-car pile-ups and massive death is a yellow line of paint.
In all of these cases, no one dies, and no one directly loses large sums of money.
But it's more than just convenience alone. It's business. Business often comes down to service. And when a client forgets their password, nothing beats just telling them. Yes, telephone's a little bit better, but not always the better business solution.
In the end, you know something, it's up to the person paying the bills. If my client doesn't care about the security risk, then I'm not the one to force them onto the long road.
The front door to my house has a lock that is easily picked -- which doesn't matter because right next to the door. . . is a window. I don't want bars on my windows either.
First two that come to mind are XDA-Developers and the Cyanogenmod Forum. Both websites do not support HTTPS logins or even HTTPS at all as far as I understand.
I had one "are you stupid?" experience, where a financial company sent my monthly statements as PDFs.
That is fine, but they added a password to the PDF. MY password to their website.
So now the attacker just needs ANY of the monthly PDFs, my account number (which was also in the email and in the PDF), and pdfcrack.
Once the PDF password was cracked, the attacker would have everything they needed to log onto my financial account.
I complained, and many months later I think they changed it. But it took a while for them to comprehend.
I was not aware of scrypt. Thank you for pointing it out. It appears to be pretty new. PBKDF2 has been a published standard since the year 2000.
I've found that you can go a long way with in-jokes and circumlocutions that only an employee at the given location could know.
An example might be the name of a local watering hole. Especially if there is an in-joke name at the company. That way you send one of your guys an email that says, "Your new password is the official name of the West Conference Room -- change it sooner than immediately" or "Your new password is the name of the hot waitress at Poltergeist Chinese -- change it sooner than immediately". This works all the better if "Poltergeist Chinese" isn't the official name of the restaurant in question (god I hope it isn't).
Usually you end up having a lot of gadgets in the office that are beyond the ken of IT, either out of laziness, willful blindness, or just not telling them. In most shops those gadgets all usually end up having the same password for sanity purposes, and if they are behind a decent firewall and not directly connected to the Big Wires that really isn't a problem. Usually there will be a common and well-known password (hopefully not something like "password" or "secret" or "please", although I have seen all three). If you have this kind of situation, you can send an email of the form, "your new password is the usual and accustomed password, change it right away."
The HR manager at a place I used to work at would send both in the same email.
However I still couldn't read the stuff he sent out since the key and document had to be used with a specific version of MS Office that was new at the time.
I'll tell you what *I* do about it - I promptly complain to someone who proceeds to ignore me entirely, that's what I do about it.
Perfectly Normal Industries
If you choose "hunter2" as password, it is automagically crypted and shown as "*******" so you can consider yourself pretty safe. [citation needed]
The amount of effort it takes to do proper password handling versus the amount of effort it takes to just store one long enough to authenticate a user is so little different that treating them differently just shows a lack of knowledge about security in general.
Sending a clear text password for 'recovery' tells me that you didn't even bother to hash it ... that is NEVER AN ACCEPTABLE PRACTICE. If you think it is, or if someone treats it like it is, it shows you that they aren't capable of treating the different bits of data at different security levels since the extra 3 lines of code to hash the password for safer storage was apparently too much for them.
If you(they, whoever) care so little about the password that its not hashed, then its not worth having a password for in the first place. On modern processors, even doing hashing in ASSEMBLY is not a ridiculous task, every other higher level language has a library that does it in one function call in most cases.
There is no excuse that justifies storing a password in clear text. Ever.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Slashdot account creation sends pw in plain text. Although it does tell you to change it immediately. On a related transgression, lastminute.com sends your name and date of birth in plain text when you book a flight. I didn't like this one.
... to read my latest password in clear text: j6apZVsxrXwFZ?P8,BdVb9uz1Q=:Ephq
now we need to go OSS in diesel cars
"it showed that the company was storing my account information in cleartext"
No, it does not show any such thing, it shows that they emailed it to you in unencrypted form, but says NOTHING about how the company stored your data.
I agree it is bad form to email such things and have said as much for years - worse to send both in one email! But still, it does not speak to how the company stores your data at all.
The solution is obviously to use a machine generated one time password, possibly with a limited lifetime, to protect some data - for instance a password. It can be used only one time and the protected data delivered using SSL and is securely deleted afterwards. The real password would be stored inside this data and will only be in cleartext for the lifetime of the data or until it is fetched.
"For every complex problem, there is a solution that is simple, neat, and wrong." -- H.L. Mencken (1880-1956) --
See subject: It's also not polite to talk w/ a full mouth http://it.slashdot.org/comment... seeing as you're STILL "eating you words" in that link I see!
* LMAO...
(You really ought to CHANGE YOUR DIET: "eating your words" != GOOD nutrition Sardaukar86...)
APK
P.S.=> Tell us: How does "eating your words" in a 244++:1 ratio against you taste? Can't be TOO good, spiced w/ the 'bitter taste of SELF-DEFEAT', & rammed down your throat since your FOOT'S IN YOUR MOUTH too, lmao... apk
If you email provider and the senders email service both support opportunistic TLS, the email is automatically encrypted during transmission. Most email providers support it: https://www.google.com/transparencyreport/saferemail/
"I just reply to you when I see you spamming Slashdot with your nonsense"- by dave420 (699308) on Friday June 19, 2015 @10:31AM (#49945047)
Why'd you agree w/ my points on hosts then? Quoting you:
"I'm not denying all those things" - by dave420 (699308) on Wednesday September 17, 2014 @11:39AM (#47927435) FROM -> http://yro.slashdot.org/commen...
Of course not: It's impossible to dispute HOSTS FILES superiority to other methods!
Since my points in favor of hosts SINGLE FILE native kernelmode faster part show hosts doing more w/ less vs. so-called 'competitors' many part messagepassing + cpu/ram use overheads laden slower usermode FAR MORE COMPLEX 'solutions' doing less than hosts do for more security, speed, reliability, + anonymity!
I make creating a superior more efficient solution EASIER!
(That's more than a mere trolling stalking harassing "ne'er-do-well" like yourself could *EVER* manage).
---
"I'm simply pointing out that it takes an AdBlocker to block your spamming"- by dave420 (699308) on Friday June 19, 2015 @10:31AM (#49945047)
I bother you? Then WHY DON'T YOU DO IT & use 'em? Answer that!
(You stalk/harass me instead!)
OBVIOUSLY you don't & you're a "ne'er-do-well" troll & you have "other motivations" (next):
---
* QUESTION:
DO YOU WORK FOR AN ADVERTISING FIRM, or ARE YOU A WEBMASTER/WEBCODER http://slashdot.org/comments.p... , or a MALWARE MAKER, or ARE YOU AFFILIATED WITH 1 OF MY COMPETITORS?
Answer it!
As per your usual you'll avoid every question, or lie & You've been EXPOSED in your "motives" in the last link just above, lol!
APK
P.S.=> See Dave420 the "pot puffing clown" SQUIRM - evasions galore will ensue (as well as effete downmods via sockpuppets to *try* vainly "hide it" -> http://slashdot.org/comments.p... )... apk
"Your hosts file comments are not trustworthy" - by omnichad (1198475) on Friday August 09, 2013 @11:22AM (#44520759)
See subject: MalwareBytes' hpHosts Admin (MalwareBytes employee who has seen & verified its sourcecode too no less as safe) hosts & recommends it -> http://hosts-file.net/?s=Downl...
&
MalwareBytes = BEST antivirus (per this VERY recent testing of them all) -> http://www.av-test.org/en/news...
&
It's GUARANTEED safe & clean (per it being checked by 57 antivirus programs recently) in BOTH its 64-bit model -> https://www.virustotal.com/en/...
+
In its 32-bit model also https://www.virustotal.com/en/...
---
Tells us, omniweasel:
* HOW'S IT TASTE "EATING YOUR WORDS" flavored with your FOOT IN YOUR MOUTH ramming them down spiced with the BITTER TASTE of SELF-DEFEAT"?
LMAO...
Additionally - have some manners!
It's NOT POLITE to talk with your mouth full as you "eat your words" quoted above after all that proof to the contrary from reputable sources.
APK
P.S.=> Lastly: You also conceded MANY points on hosts to me & made huge mistakes vs. me here http://tech.slashdot.org/comme...
&
Here too http://tech.slashdot.org/comme...
LMAO @ U, "omniloser"... apk
"Your hosts file comments are not trustworthy" - by omnichad (1198475) on Friday August 09, 2013 @11:22AM (#44520759)
See subject: MalwareBytes' hpHosts Admin (MalwareBytes employee who has seen & verified its sourcecode too no less as safe) hosts & recommends it -> http://hosts-file.net/?s=Downl...
&
MalwareBytes = BEST antivirus (per this VERY recent testing of them all) -> http://www.av-test.org/en/news...
&
It's GUARANTEED safe & clean (per it being checked by 57 antivirus programs recently) in BOTH its 64-bit model -> https://www.virustotal.com/en/...
+
In its 32-bit model also https://www.virustotal.com/en/...
---
Tells us, omniweasel:
* HOW'S IT TASTE "EATING YOUR WORDS" flavored with your FOOT IN YOUR MOUTH ramming them down spiced with the BITTER TASTE of SELF-DEFEAT"?
LMAO...
Additionally - have some manners!
It's NOT POLITE to talk with your mouth full as you "eat your words" quoted above after all that proof to the contrary from reputable sources.
APK
P.S.=> Lastly: You also conceded MANY points on hosts to me & made huge mistakes vs. me here http://tech.slashdot.org/comme...
&
Here too http://tech.slashdot.org/comme...
LMAO @ U, "omniloser"... apk
See subject & LMAO @ U, boy -> http://slashdot.org/comments.p...
FACT: "AlmostALLAdsBlocked+" is INFERIOR vs. hosts - hugely so!
AB+ doesn't even DO what it's supposed to fully anymore being BRIBED http://finance.yahoo.com/news/... not to!
AB+ doesn't do a FRACTION of what hosts do for more speed, security, reliability, + anonymity online!
AB+ EATS 128mb of RAM (vs. hosts @ 11 *maybe* tops via my program with CURRENT data, the important kind vs. current threats + ads) http://cdn.ghacks.net/wp-conte...
AB+ adds messagepassing overheads!
AB+ operates in SLOWER usermode (vs. hosts in PnP kernelmode)
AB+ creates huge CPU consumption!
AB+ is also detectable by clarityray (via native browser methods) nullifying it (not hosts).
---
I use what you already have that works & does more with LESS, no less - you by way of comparison? Pile on "MoAr" that doesn't do as nearly as much & what it's supposed to do, massively inefficiently no less (see above)?
Ab+ NO LONGER DOES!
* AFTER ALL THAT?
AB+ = "better", Coren22?? LMAO - NO f'ing way!
If you say it is, you are *TRULY* stupid & I'd reply saying "argue with the numbers" & facts above, from reputable sources & analysis proving my points for me!
APK
P.S.=> Gonna go "cry in your cereal" now, boy?
(You ought to for being STUPID enough to use OR SUGGEST a blatantly INFERIOR solution! See above - it's fact & truth via reputable sources)... apk
See subject, "Run, Forrest: RUN!!!" - Can ab+ do 16 things hosts do for speed, security, & reliability:
1.) Protect vs. malicious sites/servers (past ads)
2.) Protect vs. fastflux botnets + stops C&C communique
3.) Protect vs. dynamic dns botnets + stops C&C communique
4.) Protect vs. DGA botnets + stops C&C communique
5.) Protect vs. downed DNS (adds reliability)
6.) Protect vs. DNS redirect poisoned dns
7.) Protect vs. trackers
8.) Protect vs. spam
9.) Protect vs. phish
10.) Protect vs. caps
11.) Get you past a dnsbl
12.) Keep you off dns request logs
13.) Speed up surfing by adblocks & hardcoded fav. sites
14.) Work on anything webbound (ie email programs) multiplatform.
15.) Give you easily controlled data
16.) Do all that & block ads more efficiently in cpu + memory usage vs. addons
* ANSWER ="NO" to each on ab+ doing it or as well + hosts = already on every device natively.
APK
P.S.=> Ab+ does less than hosts & less efficiently - hosts do MORE w/ less + Hosts start w/ the IP stack before REDUNDANT inefficient addons BEGIN to operate (as 1st resolver queried):
Ab+'s 128mb memory inefficiency -> http://cdn.ghacks.net/wp-conte... (hosts consume 3-11mb using my program initially).
+
ClarityRay defeats it dumping addons in use in a browser via native browser methods to do so!
+
Ab+'s paid to not do its job http://finance.yahoo.com/news/...
Ab+ adds complexity + slower mode of operations (usermode = more messagepassing overheads vs. hosts in kernelmode).
What's best?
APK Hosts File Engine 9.0++ SR-2 32/64-bit -> http://start64.com/index.php?o...
MalwareBytes' hpHosts Admin (MalwareBytes employee) hosts & recommends it -> http://hosts-file.net/?s=Downl... & MalwareBytes = BEST antivirus http://www.av-test.org/en/news...
&
It's GUARANTEED safe & clean per it being checked by 57 antivirus programs recently in BOTH its 64-bit model https://www.virustotal.com/en/...
+
In its 32-bit model also https://www.virustotal.com/en/...
... apk
"Your hosts file comments are not trustworthy" - by omnichad (1198475) on Friday August 09, 2013 @11:22AM (#44520759)
See subject: MalwareBytes' hpHosts Admin (MalwareBytes employee who has seen & verified its sourcecode too no less as safe) hosts & recommends it -> http://hosts-file.net/?s=Downl...
&
MalwareBytes = BEST antivirus (per this VERY recent testing of them all) -> http://www.av-test.org/en/news...
&
It's GUARANTEED safe & clean (per it being checked by 57 antivirus programs recently) in BOTH its 64-bit model -> https://www.virustotal.com/en/...
+
In its 32-bit model also https://www.virustotal.com/en/...
---
Tells us, omniweasel:
* HOW'S IT TASTE "EATING YOUR WORDS" flavored with your FOOT IN YOUR MOUTH ramming them down spiced with the BITTER TASTE of SELF-DEFEAT"?
LMAO...
Additionally - have some manners!
It's NOT POLITE to talk with your mouth full as you "eat your words" quoted above after all that proof to the contrary from reputable sources.
APK
P.S.=> Lastly: You also conceded MANY points on hosts to me & made huge mistakes vs. me here http://tech.slashdot.org/comme...
&
Here too http://tech.slashdot.org/comme...
LMAO @ U, "omniloser"... apk
I signed up for Tigerimports.net back in February, and was surprised to find out they had sent me my password in the account creation confirmation email in plaintext. I notified them immediately and a support member replied stating this wasn't intentional and that Sunshop, their shopping cart company, are not supposed to be emailing passwords, and added that they used to not do this. The support member said they'd create a support ticket to have it changed. Again, this was back in February.
I created a new account there just now and they are still sending passwords in plaintext. Seems like they don't really care. Either that or not much gets done in their company internally. Should I even bother sending another email?
1> If it was a company wanting my business: I'd email their IT department explaining why I will never ever use them. 2> If it was a company who wanted to hire me: Likewise I would email the head of IT explaining why I'd never ever work there. 3> If it was just a company on the internet: I'd email their head of IT explaining what happened and do they need for me to recommend someone who can take care of this situation?
I bet most people (not slashdot readers) but most people don't know any saved password in firefox and chrome can be easily be seen. Let me borrow your laptop for a sec, I need to check something...Ok, got this guys banking and paypal passwords....
Stop stalking APK or go away.
..Mullah or Pope, Preacher or Poet, who was it wrote: "Give any one species too much rope and they'll fuck it up"?
It's obvious 95% of the posters here have never worked on a real service desk. I spent 3.5 years working as a Security Account Admin and sent every password in cleartext and here's why. End users & their managers are remarkably computer illiterate. If I salted or hashed the passwords as so many have suggested, I would get a reply within 5 minutes saying "my password didn't work." As it was I still had about a 50% success rate with end users actually getting their passwords to work. Another issue I faced was a language barrier. Our work spanned 6 continents and roughly 18 time zones. as a result we provided 24 hour service and to a warehouse worker in Shanghai, my e-mails probably looked like they were written by an alien; which is why their managers were always copied on the e-mails. As a rule to ensure some security, all e-mails were sent encrypted and never sent to a third party address which angered the UPS & FedEx shippers in Asia. I also often copied the regional service desk person, as it was likely they spoke the language of the end user or someone on the service desk spoke it.
"If stupid things work...then they are not stupid."
See subject: As you "eat your words" http://it.slashdot.org/comment... 244++:1 against you!
* LMAO...
(You really ought to CHANGE YOUR DIET: "eating your words" != GOOD nutrition Sardaukar86...)
APK
P.S.=> Tell us: How does "eating your words" in a 244++:1 ratio against you taste? Can't be TOO good, spiced w/ the 'bitter taste of SELF-DEFEAT', & rammed down your throat since your FOOT'S IN YOUR MOUTH too, lmao... apk
In the summary there was no proof of a password being stored in clear text. It described the password being emailed in clear text.
Sending a clear text password for 'recovery' tells me that you didn't even bother to hash it
No, it doesn't. If the password was generated/reset and emailed at the same time it could easily be sent in clear text and hashed properly in whatever system it is used on.
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.