One Way to Reduce the Risk of Social Engineering Attacks

In my day to day job I work with a number of secure systems. A number of them are entirely internal, but the others are customer facing. There are also certain operational procedures which are instigated at a customer's behest (the customer phones up and asks - I've been taken to task for my sesquipedalian posts...).

The problem comes when the customer is asked to provide identification. The classical approach is via some form of shared secret - you know the kind of thing - a maiden name or some other personal piece of information.

I've never been comfortable with this kind of security scheme as it relies on security through obscurity in the first instance and on the honesty of the company staff in the second. Anyone can now trawl through public records to find out the kind of personal information used for this security scheme and increasing numbers of cases of personal information being stolen at call centers are coming to light.

Many of the systems I work with have dual channels for customer interaction:

• A secure online channel - for day to day customer use of the system.
• A phone number - for out of the ordinary requests.

To reduce the risk of Social Engineering attacks I advocate using a scheme that provides authentication for the phone calls through the secure online channel.

The steps of the scheme work like this:

1. The customer decides that he or she needs to make a call.
2. The customer accesses a function on the secure online channel to enter a password for that call.
3. The customer enters the password.
4. The system digests the password and stores it.
5. The customer makes a phone call.
6. The customer representative requests the password and enters it on his system.
7. The system digests this password and compares it with the stored one.
8. If they do not match then the customer has not been authenticated and the representative politely handles this.
9. If they do match then the customer is authenticated and the call proceeds.
10. The system clears the digest preparatory for a new support call.

This scheme does rely on a couple of things:

• The presence of the online channel
• The fact that the customer does not mind the added complexity versus the increased security (this can be handled by clear public relations explaining how this scheme reduces the risk of identity theft etc.)

We are building a chain of trust here. We base the authentication of the customer over the phone on the authentication of the customer over the online channel.

The security of this system can be fine tuned in a number of ways:

• A more complex password (length, character types etc.) can increase security but at the cost of increasing the complexity of the customer interaction with the system and the representative - try explaining !B00thbY over the phone. The fact that the password is intended to be only used once should allow for a simpler password.
• Store the digests of previous passwords and introduce a clear reuse policy. This introduces a marginal increase in customer complexity for a good increase in security.
• Allow (limited) reuse of passwords. This reduces the security but can be very useful in a scenario where support is needed when the online channel is down. The user can generate a password in advance for, say, 5 uses after which time one would hope that the online channel is back and a new password can be generated. Further modifications can come in the event of an extended outage where the password use could be extended.

This security scheme produces a limited shared secret in a relatively simple and secure way and neatly eliminates the use of most personal information from customer interactions. I hope that I have illustrated not only the scheme but the compromises involved.