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.
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...
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
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.
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".
Comment removed based on user account deletion
I use "[password redacted]" for my password for this very reason!
Which has more power: the hammer, or the anvil?
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
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.
...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 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...
Same AC you replied to. Allow me to make the same statement in a less confrontational way. I admit I was a bit over the top on the first go around.
Security should be commiserate with the damage that a breach may cause and the desire to commit the breach. Passwords distributed in plain text may be perfectly acceptable depending on the data they are protecting.
A leaked transcript is not particularly damaging to an individual (assuming they didn't lie about it) nor a very popular target (unless they are a politician). Therefore a plain text password is sufficient to prevent casual snooping.
A job application site is not particular interesting either but may be if it contains your SSN. That said, the individual applying generally has the ability to change their password before entering sensitive information. Therefore, changing your password on the first login should provide a sufficient protection from a moderately sophisticated attacker, i.e. the initial plaintext password is not a cause for concern.
Access to a bank site would be damaging to the individual attacked and valuable to the attacker. A network sniffer could gain access using the plain text password and do serious harm/make profit. This is true even if the attacked were to change their password and quickly and possible. Therefore a plain text password is unacceptable.
If you go to your boss and say the whole IS system is insecure you will not get funding to fix real issues. Instead, if you go to your boss and say I need a smaller amount of funding to fix a potential security problem in the credit card processing subsystem you have a high probability of getting the funding. There is a common problem of arrogance and crying wolf within the IT/IS community. We get distracted by being perfect and forget about being good enough.
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?
That is Mailman, and is fixed in Mailman 3.
"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'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...
"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.
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.
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.
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
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) --
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."
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.