Your Data and Your Credit Card

[Update: I had a couple of machine crashes while I was writing this, and only just realized that a pointer to Allan Dyer's excellent article at hadn't survived to the final version. Which is a pity, because it's very relevant, and well worth reading.]

Over the weekend, I posted a blog on the AVIEN site pointing to a blog by Roger Thompson ( about an instance of a credit card provider using "public" information he hadn't provided them with to authenticate him as a customer.

That generated some interesting discussion on Facebook, so I thought I'd clarify one or two of the reasons why there are problems with organizations that use publicly available information for extra validation of a customer's identity.

I don't think the scary aspect is the ease with which a finance house can introduce this sort of scope creep, when legitimate organizations start to use the same data aggregation techniques that are used by criminals working on Identity Theft and related forms of fraud. There are some disquieting ssues that do immediately leap to my mind, however.

The possibility of an organization using one customer to validate (or invalidate) another poses some semi-submerged ethical and practical issues. For instance, if, as Roger suspects, social networking sites are one of the sources of this "public" information, what happens when one of the parties uses misleading or false data on (for example) Facebook because (not irrationally) they mistrust Facebook's ability to keep it confidential? In a situation like the one Roger describes, false information may be seen as more "valid" than "true" information. Well, that seems scary enough to me.

Actually, any instance of an organization relying on the accuracy of data from a wider (more public) range of resources should worry you. The Wider the range, the more likelihood of inaccuracy, and even of deliberate poisoning of data. While a bad guy who has access to all the information that a bank (for instance) has may not need to change it in order to profit from it, there are several scenarios where he might want to.

  • In order to hamper remediation
  • In order to influence the presentation of data he can write to even when he can't read it. (A more common situation than you might think.)
  • In order to compromise reasonably public data as part of a social engineering attack.

In fact, in any scenario where some of or the whole objective is blocking legitimate access as well as or instead of impersonation.

But there are more immediate difficulties.

Data held by public organizations (to which a financial organization may or may not have access) is not automatically accurate. You'd think that the UK income tax officials would know more about me than most organizations in certain respects, but they quizzed me about my "deceased" father a decade before he actually died. Another friend was asked far more recently by his provider to describe his car, but the information they had on what he drove was actually months out of date. Some public information is either wrong, partial, or correct(-ish) but ascribed to the wrong individual.

Maybe it's legitimate for a provider to want to know more about a customer (though in Europe, data protection directives are supposed to restrict the use and storage of personal data to what is necessary). But how do you keep track of and validate everything that's "known" about you when they're pulling info from who knows where, long after they're supposed to have validated you as a customer? There is clearly a need for regulation of the way public information is used regulated organizations, corresponding to the way that the information they -hold- is regulated (for example by the UK's Data Protection Act and other European legislation that enacts the European Directive 95/46/EC – see

As Allan suggests, the authentication process should incorporate multiple checks. But if we can't trust financial organizations like PayPal to follow best practice in corresponding with their customers (;, can we trust them to validate external information correctly?

Chris Blask pointed out that the unexpected question cited in Roger's post is probably pretty effective, and "unless it is the only piece of identifying information you are using it would be hard to intentionally target effectively for purposes of poisoning".

That's a fair point, but I think it's easily possible to underestimate the capacity of a service desk (any service desk!) to make decisions on the basis of an incomplete protocol and information of uncertain provenance.

One thing that Chris, Allan and I seem quite agreed on is that regulation is nowhere near keeping up with the Internet age, and some of our legalist assumptions were outdated in the 19th century…

(Thanks, Chris and Allan, for the interesting discussion.)

Director of Malware Intelligence

ESET Threatblog (TinyURL with preview enabled):
ESET Threatblog notifications on Twitter: (or @ESETblog)
ESET White Papers Page:

Securing Our eCity community initiative:

Also blogging at:



Author David Harley, ESET

Follow us

Copyright © 2016 ESET, All Rights Reserved.