As of now, we're accomplishing this by hashing, salting and storing the first three characters of the customers' passwords in one table and hashing, salting, and storing the full password in another table.

BCrypt is used for hashing and SQL Server for storing.

When a customer calls our customer service, the representative has the option to verify the caller's id by asking for (among other things) the first three characters of her password.

The system used for this is behind all kinds of security measures and in no way exposed via external GUI nor API.

With the desired outcome in mind, verify the caller's id fast and easy, is there a more secure way to gain the same benefits?

  • 1
    I think this question needs more context, like: How secure need the system be, i.e. what harm can be done by an attacker which tricked the verification? What kind of information you have from the true user which can be considered unknown by an attacker and how hard would it be for an attacker to get this information? What kind of tradeoff between security and usability you or your users will accept? Commented Sep 8, 2017 at 10:01
  • 2
    WHAT? Hopefully none of the caller give away (part of) their password.
    – Marcel
    Commented Sep 8, 2017 at 10:34
  • 2
    how long of passwords do you require? if only 8 chars, minus those 3 that are a phone-call away, you're down to only 5, which an Apple IIE can break over lunch...
    – dandavis
    Commented Sep 8, 2017 at 14:41

1 Answer 1


(For other searchers who are concerned about separate storage of the first three characters, the asker's other question about that technique here has some solid and detailed replies, explaining why extracting a subset of secret information like a login password may be suboptimal).

More generally, there are a couple of canonical ways to verify identity. Most involve asking the customer for information that both the customer and the company would usually only know:

  • Recent activity. For example, if it was a financial institution, you could ask them to describe the amount, merchant, and date of a recent transaction.

  • Credit history data. If your business has access to credit history information (loan types and amounts, previous addresses, etc.), you could leverage this information.

  • Account support password. Separate from the password used by the customer to access the services directly, you could simply have the customer supply (at signup) a password that will A) be stored on your servers in plain text, and B) only be used by customer service to verify the customer's identity.

You can also throw in, in addition to the above and selected at random, some other information that is naturally collected at signup and stored (address, birthdate, last four of SSN, etc.). For obvious reasons, these would only be used to supplement the questions above, and would need to be adjusted based on your business model.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .