How to tell users that they shouldn't disclose their password over the phone to our help desk?

Question

I work for a help desk, and we recently launched an online service where our members can log in.

A problem we are having is that users who are calling us often ask us to confirm that the password handed in to them is correct. By doing so, they disclose their password over the phone. How can we prevent this?

It is mentioned in the sign up mail that they mustn't disclose their password, and we mention it whenever we feel they are going to disclose it to us.

About the users: Around 90% of our callers are first time callers. Since they're doing it the first time they call, it's difficult to educate them. They are pensioners, so they usually have less experience of authenticated services than the average computer user.

Answer 1

Ensure there is a method for users to reset their own passwords, and make a policy whereby the helpdesk will initiate a password reset if a password is revealed to them.

Users will tend to phone up when they can't log in, and therefore triggering the same password reset process as they can themselves results in them slowly learning that it doesn't help to phone up.

Answer 2

Unfortunately some users will always do this but you could add some audio to the introduction message and hold music, reiterating that users are not to provide passwords over the phone.

Answer 3

Simply put, there's no way of stomping this out completely. There are policies and procedures you can put in place to reduce it, though:

• Send out Security Awareness messages (standalone, or footers to other messages) reiterating that passwords are private and should never be given out to anyone.
• Train Helpdesk staff to cut customers off before they can give their password out.
• Implement a policy whereby if a customer gives a password out to the helpdesk, that password must immediately be reset.
• Ensure that self-service sections are prominent and well advertised (for password resets/recoveries).

Most of these come with an associated cost to service (inconvenience, usually, and additional paperwork), which should be considered before implementation, but that's the general direction.

Answer 4

I think in addition to the immediate password reset it might be appropriate to remind users of the terms of service (sample terms of service).

You are the sole authorized user of your account. You are responsible for maintaining the confidentiality of any password provided by You or Zimride for accessing the Service. You are solely and fully responsible for all activities that occur under Your password or account. Zimride has no control over the use of any User's account and expressly disclaims any liability derived therefrom. Should You suspect that any unauthorized party may be using Your password or account or You suspect any other breach of security, You will contact Us immediately.

Tell the user that they have violated the terms of service by disclosing the password and that you are resetting the password to put them back in compliance.

It also depends on what kind of service you are providing. For me personally, if I attach no monetary value to my account, then I won't likely care much about the terms of service. On the other hand, if I am asking about my retirement account and it is implied that frequent violations of the terms of service may be used as evidence to absolve the company from financial liability in case of a security breach, I will definitely pay attention.

For example, some hackers steal my money using an unrelated security breach but the company does not want to make good so they use my password disclosures as evidence of my carelessness.

Answer 5

I have a simple process that taught users pretty rapidly to not give us their passwords. If a user tells you their password do the same thing you would do if you knew the user told someone else the password, force them to set a new password. Finish the call / interaction and then inform the user that for security you need to now reset their password, to please remember to never tell anyone (Including their manager or IT staff) their password and if they ever do to inform IT immediately so you can reset it.

Answer 6

You could have asked this on UIX.StackExchange - here nobody seems to ask the question "Why are they telling you their password ?". I think trying to educate people with audio messages or warnings won't cut the deal. Most people know they shouldn't tell their password anyone without a good reason.

If so many people call your support to assert "P4ssW0rd is my password, right?" It seems your user interface leaves them clueless if that really is their password. This could have multiple reasons - if you have old clients it could simply be, that they forget their password, but people who know they cannot easily remember stuff would usually write it down.

Maybe they have problems logging in and get the usual "You have entered a wrong user name or password" message - It is natural to ask support if the username or the password you entered was wrong. Maybe they get the same message if their account is locked? Or maybe they get their first password via mail and it doesn't "look" like a password. Or the application doesn't make it simple enough to know what your password is.

You should ask users why they need to clarify their password and you will probably find a reason in communication with the user / in the user interface which leads to so many people feeling the need to clarify their password via phone.

Answer 7

Update with a new proposal for a solution:

What if you started each conversation by asking a customer for the answer to some pass-phrase that only he or she should know? A similar option has been used as an extra measure for a long time at a company I used to work for, where security is relatively high, and I have a hunch it just may help sidestep problems like yours.

The way this works is as follows: When a customer calls and gives his or her name, you look up their info, including a plain-text question and answer set. Now immediately ask them to verify their identity by answering the question, which you read to them.

What would this achieve?
Two things, I would hope: Firstly, it should improve your security, even if only marginally. The information may be stored in plain text, with everyone working at the help desk having access, and it would probably be the case that many of the answers would be easily guessed, especially if an attacker did a little research before calling you. Even so, this should still make it just a little more difficult to impersonate one of your customers over the phone without triggering any suspicion.

Secondly, and more importantly for your particular problem, this should make it clear to the caller that you have in fact identified them, and are looking at their customer data right now. The idea here is that you actually allow your customer to be helpful. That is, after all, probably why they are so eager to give you their passwords, right?

In essence, you will then be providing them with a simple way to identify themselves without disclosing the more sensitive piece of info that is their personal password.

---

My previous answer:

You can and should keep trying to educate your users about issues like this, but there will always be users who are ignorant of this, or who do not take it seriously. Whenever that happens, make sure to politely inform your users once again about it, and tell them you have a policy that requires them to reset their password now that it has been revealed.

If this is a recurring problem, you might also want to look into why this happens. Do people at your help desk actually require access to customers accounts, even if only for a short period to help them out? Perhaps you can find some solution where temporary access is given with a temporary password? If this includes an advertised solution making it simple for you to help your users, while also obvious for them that you can get access without them having to provide their passwords to you, then perhaps they won't feel the need to "help" you access their accounts?

Obviously this would require logging each time an employee accesses a users account, preferably with a short description of why, and what was done, etc., along with a strict policy concerning confidentiality and guidelines about what employees can and can not do, etc.

Answer 8

I just wanted to throw this in on top of the other options here (which are good.)

I'm not sure what kind of phone system you're using, but in addition to the ones suggested above, would it be possible that a short automated audio message gets played to the user calling in informing them not to share their password with any service reps and all that? This automated message could both educate users before they get to reps, as well as prevent against any malicious rep asking for passwords (not sure how much of an issue that is there.)

Answer 9

I am posting this comment as an answer as I think it is a very good answer to the question

Personally, if someone is already unaware that they should not tell the helpdesk their password, then reactively resetting their password would most likely make them angry - even if it's good practice to ensure that only they know their password. If it's extremely sensitive information, it's a must. Otherwise, I think having some kind of a recording before a call is picked up might help - "Your call may be recorded for quality assurance purposes. Remember to never reveal your password to anyone - including the Help Desk."

-@Jake

Answer 10

Another one coming from the left field, trying to stop the leak, rather than mopping the floor.

If your password contains letters and numbers, quite often we get a lot of problems with non monotype fonts. '1' 'i' 'l' all looks the same '0' 'O' also. So perhaps use a picture, or force the browser to use monotype, when displaying their pass?

Or get your pass algorithm to not use any of the above.

Answer 11

Usually it is a symptom of poor communication, procedures, organisiation, policies and strategies by the company toward the customer.

For some of my bank acounts, even I can't understand what the 'letter' or 'email' is on about between the Pin, security phrase, security number, password, customer ID, login name, login name, email address, email address and another email address, all of which are sometimes different and sometimes not. (note the duplicates!). Then there are the two factor ID cards and codes to follow that..

E.g. my ISP required me to enter an email address to create an account to get their service which provided an email address [see (1)], and then my telephone ADSL ID was also 'an email address'. So which do I log in with - both depending on the web page!

No wonder folks are confused and the security is compromised by all those supposedly security enhancing 'schemes'.

Then I try helping my elderly in-laws (87 & 90) with hearing aid difficulties etc.

It is about management of risk and consequences (actually it's Hazards, Probabilities, ...).

Make sure the communications department improves the format and layout of those emails, and that they can't be confused with any other similar sounding item (i.e. remove one, so there are NO similar sounding items!)

Answer 12

I think it's best to have an automated message thru IVR telling them explicitly that-

For security purposes please never provide your passwords to our Help desk Representatives ...

before they even talk to your support team.

I hope it helps! :)

Answer 13

I suggest you back up and ask yourself why the users are doing this in the first place. What occurs to me is that they can't log in, and are trying to determine if they forgot their password or something else is wrong - the account is blocked, they have the wrong user name, etc.

Your problem is that the innocent user trying to fix his access problem is mixed in with malicious attempts to get access to accounts by human engineering your support staff. Unfortunately, it probably won't work to just ask the caller he is a real user or a criminal.

I don't have any answer for you - any information your staff is willing to provide or confirm is potentially part of an attempt to gain access by someone who should not.

Answer 14

People are used to trusting the people that they ask for help, else they would not ask them... Doctors, therapists, auto repair, appliance service, etc. For example, yesterday I took my car in to the shop for a repair. It would be absurd if they said, "Do NOT under any circumstances give any of our staff (or any other person) the key to your car!" Inside my car were the usual documents which show my name and address (car registration paper, insurance documentation) and I also have a key to my apartment hidden inside the car as well (in case I ever lock myself out somehow, and there is a spare car key in my wallet). It is possible that bad people work at the car shop, but unlikely.

But in any case, no one can "hack in" to my apartment or steal my car without actually being here, so I don't have to worry about trusting 99.9999% of the world's people. If I misplace my car key in New Zealand, it won't be a problem. If someone in Romania gets a copy of my apartment key, still no problem. So, the point is that the electronic world is just different.

I think that the solution is to make it more like the real world: no one living outside my home town should be able to access my bank account remotely. If I bought gas at home using my credit card, and someone tries to use it 2000 miles away an hour later, it should just fail. (And, it did once. Bravo to my Credit Union for automatically doing what was best for me without me ever asking or having to pay for that!)

You can't explain to people or prevent assumptions based on a world of verifiable trust if the world you are "selling" has no such benefits. Change the world that you are selling to people. Make a password that has been stolen as useless as my car key is in New Zealand. Technology has to work for people, not the other way around. IF the things you create are not secure, work harder. We have improved the safety of airplanes, cars and electricity dramatically, we didn't just say, Oh, Well, more education needed.

Answer 15

I work for a help desk, and we recently launched an online service where our members can log in.

It is unfortunate that a design problem rears its head and you, at the frontlines, have to deal with it, when it should be the architects who should have to answer to the feedback provided in this QA.

I note two things (emphasis mine):

A problem we are having is that users who are calling us often ask us to confirm that the password handed in to them is correct. By doing so, they disclose their password over the phone. How can we prevent this?

and:

Around 90% of our callers are first time callers. Since they're doing it the first time they call, it's difficult to educate them. They are pensioners, so they usually have less experience of authenticated services than the average computer user.

The problem here isn't the design of the password system, the problem is the use of passwords in the first place, by an unsuitable audience.

If I were designing this system, I would avoid passwords, or otherwise, provide a suitable alternative means of authentication for a less-technical audience. My preferred options include:

• One-time-passwords from an RSA Key or similar (used in a single-factor authentication system),
• Client-side certificates from either a smartcard or virtual smartcard (secured with a PIN) or from a secure USB dongle
• "Picture Passwords" (a series of clicks/taps on a large image), from an infosec perspective this is the same as a password and it is plausible that it is less secure if the click-point-sequence is obvious, but it makes it harder to forget, and doesn't lend itself easily to being shared over the phone.
• Use PII (personally-identifiable information) as a password. In the US, one's social-security-number often serves in this place, as (generally) everyone knows it should be kept secret, yet people seem okay with their banks' websites asking for it to confirm their identity - perhaps a less critical analogue could be used, such as a birthdate and current street name, though these are hardly secret, if the system uses numerical or randomly-assigned user-IDs (as opposed to email addresses or freetext usernames) this would be just-as-secure as a password, provided users do not leak their user-IDs.

Answer 16

The risk here seems to lie more on the side of the help desk technicians who are getting told the password. If you can't trust them not to abuse the knowledge then, you have a problem to fix.

Getting users to stop giving their password is a matter of educating them. That should happen as needed when it occurs.

If a user gives a password to a help desk person, there should be a process in place to lock that password and force them to create a new one. Again, you have to trust the help desk person to initiate this, but that's why you'd vet them before being hired.