Account Security:
Using Passwords to Protect Customers' Privacy

Attention Large Companies: Does your customer service department deal with customer passwords?
Here's a sample set of suggested guidelines for your staff.

by J. E. Brown

Last updated Friday, January 5, 2001.

Topics: Assigning Passwords | Definitions | Customer Service | Management | Programming


Guidelines for Assigning Passwords to Customers.

Do It In Person. If at all possible, have the customer visit you in person to create the account; assign the password then and there. Require a photo ID before creating the account.

If you can't create the account in person (for example, because you and the customer are in separate cities), then the following guidelines become necessary:


Now Some Definitions.

A caller and a customer are not the same thing:


Guidelines for the Customer Service Staff:

The Purpose of the Password is to make sure that the caller is the customer he/she claims to be. The Password is proof of identity, in the sense that no one but the caller knows it. In fact, unless the customer has been irresponsible about guarding it, the password is the one piece of information known only to the customer.

Look at it from your own point of view: We all have accounts which we wouldn't want our kids and in-laws and employers getting into. The beauty of your password is that it lets you restrict access to yourself alone.

Passwords at Work. Suppose a caller wants to access an account. Until the caller tells you the password, you are to assume that the caller could be anyone. Do not let Just Anyone have information about the customer's account. Never let Just Anyone change the customer's account or move or remove money within or from it. If the caller wants information about an account but can't provide a password, you are to politely but firmly inform the caller that company policy doesn't allow you to give personal information out. If the caller then becomes belligerent, or begins talking fast, or begins trying to use logic on you (instead of a password :^) ) -- in short, if at any time, you aren't sure what to tell the caller -- hand the call over to a supervisor. If you feel flushed or feel your heart rate increase, you are probably being scammed.

Checking the Password: Never tell the caller what password is on the account. Password information should only flow one way, namely, from the caller to you. If you need to identify the caller, the caller may tell you the password, but never the other way round. The same rule applies to the caller's other identifying information (DOB, SSN, ...).

Persons who call in, claiming to be account holders, but claiming not to know the account's password (as in "I forgot my password" or "I didn't know I needed a password") should not be allowed to change information on the account, nor should you answer their questions about the account -- technically, they are callers, not customers (see Definitions, above).

Never ask a caller "Is your date of birth __/__/__?"
If you need to check, then instead ask "What is your date of birth?"
Of course, you may ask either question of a customer.

Questions You Should Not Answer:


Guidelines for Customer Service Management:

When hiring customer service representatives, beware of applicants who say:

These statements of overconfidence and naive disbelief are made by employees who are less than fully watchful. Such statements reveal security vulnerabilities on your staff.

Test Your New Hires. Phone them, pretending to be a customer. Ask for information on an account. Claim you forgot your password, but say "please" a lot. If you get any information, take appropriate action.

Other security loopholes:

Password problems (lost or forgotten passwords) should be handled by a supervisor or by a small team of full-time trained specialists (as small as possible) who know how to treat callers with tact and firmness as needed, and who demonstrate a good understanding of the password principles shown on these pages.

Chronic problems: When Identity Theft occurs, an account may suffer repeated hacking attempts by unauthorized callers who insist they are the real account holder. When you find it necessary to establish who is the true account holder, do all the following:


Guidelines for the Computer Programming Staff:

When you write software for in-house use, follow these security guidelines:

Passwords Are Not Optional. Customer accounts should remain locked until the customer's password is typed in. This discourages casual browsing by in-house users.

Reduce Hack Attacks. Customer account information screens should not even be visible/accessible to customer-service people (i.e. to anyone who receives customer phone calls) until the caller has given the rep a password and the rep has typed it in. You've seen the scandals in the press concerning security gaffes at large companies -- con artists are very sly and very adept at tricking customer-service reps into revealing information on targeted customers. They will ask questions like, "What password is on the account?" and say "I'd like to withdraw money from my account, okay?" Con artists may become emotional or abusive, knowing that a rattled representative is likely to bend rules or forget procedures. Help the customer-service staff by making unauthorized access difficult. Remove the "Oops" factor.

Encryption: Customer passwords should not be stored in unencrypted form, since unencrypted passwords can be stolen and used by hackers who break into your computers.

If You Can't Encrypt: Make sure your customers know this, and advise them to change their passwords periodically.

Supervisor Passwords: In case an account holder forgets his or her password, you should provide a "supervisor password," to allow the Password Problem Team (or customer service supervisor) to access the account. Change this password once a month, and also whenever a member of that team leaves the team. Whenever the Team uses the password, software should record this event in a protected log which only the System Administrator or Security Officer can see.


About the Author

J. E. Brown is a software engineer and writer who learned a few things about security while at Los Alamos National Laboratory.



Copyright © 2000-2001  J. E. Brown   all rights reserved.
write me here
Los Alamos, NM USA