Re: T.J. Maxx data theft worse than first reported
- From: Anne & Lynn Wheeler <lynn@xxxxxxxxxx>
- Date: Fri, 30 Mar 2007 15:48:07 -0600
Don Leahy wrote:
"What are we going to do tonight, Brain?"
"The same thing we do every night, Pinky. Try to take over the world! If *I* ruled the world retailers wouldn't be allowed to store credit and debit card numbers on their data bases!"
"Why not Brain, I thought they needed to?"
"Don't think, Pinky, you'll hurt yourself. No, my intellectually deficient friend, retailers only need store the authorization code they receive from the card issuer".
"I don't get it Brain, what good would that do?"
"'It's very simple Pinky, but perhaps beyond your limited capacity to understand. To trace a transaction all they'd have to do is send the authorization number back to the credit card issuer and the information chain can be completed. No one would be able to hack into a retailer's data base and get the card numbers because the card numbers wouldn't be there! The hackers would be thwarted, Pinky! Then I, Brain, will take over the card issuers and achieve total world domination! YES!! "
re:
http://www.garlic.com/~lynn/2007g.html#10 Record Credit card heist ...TJM
http://www.garlic.com/~lynn/2007g.html#15 T.J. Maxx data theft worse than first reported
lots of times the dispute process has the consumer calling their bank with
credit card number, merchant, amount and date. the bank then contacts the
merchant with credit card number, merchant, amount and date ... there was
transaction id introduced several years ago to replace it ... but the
uptake wasn't very succesful. the consumer may also contact the merchant
with just account number, amount and date.
the current infrastructure not only requires the account number in several
places in the infrastructure ... making it vulnerable "at rest" ... but
also has it vulnerable in transit as the process is flowing thru various
processes ... i.e. skimming and harvesting vulnerabilities
http://www.garlic.com/~lynn/subintegrity.html#harvest
for "replay attacks".
in the past decade ... a number of financial institutions have tried
"one time account numbers" as countermeasure to "replay attacks" ... frequently internet specific ... i.e. the consumer is given a whole list of account numbers ... each which may be used once, and only once.
this moved a significant burden (related to attempting to limit the
current infrastructure fraud vulnerabilities) to the consumer
(where it became the consumers responsibility of keeping track
of which account number went with which purchase). some past posts
mentioning some of the one-time account number deployments:
http://www.garlic.com/~lynn/aadsm17.htm#42 Article on passwords in Wired News
http://www.garlic.com/~lynn/aadsm26.htm#4 Citibank e-mail looks phishy
http://www.garlic.com/~lynn/2003n.html#0 public key vs passwd authentication?
http://www.garlic.com/~lynn/2007c.html#6 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#15 Securing financial transactions a high priority for 2007
note ... these financial institutions typically already had transaction
infrastructures that could map multiple different account numbers
to a common (primary) account.
now, as i've mentioned before, in the mid-90s, the x9a10 financial standard
working group had been given the requirement to preserve the integrity
of the financial institution for all retail payments. the result was
the x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959
part of the standard provided end-to-end strong authentication ... and precluded
being able to use an account number used in x9.59 transactions ... in non-authenticated
transactions (eliminating being able to use harvested/skimmed information from previous
transactions in replay attacks for fraudulent transactions)
other posts/discussions related to the x9.59 financial standard for all
retail transactions
http://www.garlic.com/~lynn/subpubkey.html#privacy
i.e. the issue is that account numbers in the current infrastructure have diametrically
opposing requirements ... on one hand they are used as a type of "shared secret"
authentication (analogous password) ... in which case they have to be kept confidential
and never divulged to anybody. On the other hand, the account numbers are a standard
part of numerous business process ... and as such have to be divulged and made available.
part of the x9.59 financial standard was eliminating the use of account numbers for two distinctly different business purposes with diametrically opposing business requirements
problem can somewhat be viewed as frequently occurring systemic problem when a single construct is for multiple different business purposes which impose radically different
(and possibly diametrically opposing) requirements. It would be somewhat like taking
existing mainframe security paradigm using userid & password ... where a lot of
permissions and privileges are associated with the userid ... and the password
is separately used for authentication ... and eliminating the userid ... requiring
that the password be used for both specifying permissions and privileges as well
as used for the purposes of authentication.
in the financial cryptography mailing list blog https://financialcryptography.com/mt/archives/000877.html
somebody also used the analogy of infrastructure that decided that the color of a person's eyes were going to be used for authentication ... and then blaming the individuals if they didn't go around perpetually with their eyes closed.
.
- Follow-Ups:
- Re: T.J. Maxx data theft worse than first reported
- From: Anne & Lynn Wheeler
- Re: T.J. Maxx data theft worse than first reported
- References:
- T.J. Maxx data theft worse than first reported
- From: darth . keller
- Re: T.J. Maxx data theft worse than first reported
- From: Don Leahy
- T.J. Maxx data theft worse than first reported
- Prev by Date: Re: How to: allocate a UNIX subdirectory to SYSEXEC?
- Next by Date: Re: 3490 off maintenance June 30 2007
- Previous by thread: Re: T.J. Maxx data theft worse than first reported
- Next by thread: Re: T.J. Maxx data theft worse than first reported
- Index(es):
Relevant Pages
|
|