Jerrold Leichter wrote:
> If this is all you need, then using a 1-way hash of the card number for
> identification and the card number itself for security would give you much
> of what you need.  There are databases out there which identify customers
> by their CC numbers, not because they are willing to use the stored CC
> number for charging, but just becauses it's a good unique ID.  If what were
> stored were the 1-way hash, there would be nothing worth stealing in the
> database.
> This kind of thing is actually implemented, though people rarely think of it
> in these terms.  You can see it on many printed charge slip these days:  Your
> CC number no longer appears, being replaced by a one-way hash that produces 12
> X's and the last 4 digits of your number.  Hardly cryptographically strong in
> the usual sense, and not generally applicable, but for ID purposes - letting
> you identify which of your cards you used when making the charge - this
> particular one-way hash is perfectly good.  (It's also common on Web forms
> that tell you which of your cards a charge will be applied to.)

there was a vulnerability where attackers took the published algorithm
for valid account numbers and attacked using account numbers that
satisfied the published algorithm. somewhat as a result, guite some time
agao, the CVV field was added to the magstripe ... which could be
considered a kind of one-way hash of the contents of the magstripe ...
with some other stuff that is not predictable from the algorithm (as a
countermeasure to attacks from automatically generated account numbers).

one of the "business processes" is that somebody calls their issuing
bank and disputes a charge by a specific merchant on such & such a date.
the issuing bank eventually provides notice to the merchant (giving the
account number, date, and purchase details). the merchant then looks for
a transaction (in their transaction log) for that account number on that
date. In some cases, the merchant bank processor may provide an online
service for merchants ... where the merchant processor keeps the online
merchant transaction log on behalf of merchants for things like dispute
resolution (this may include things like online library of digital
images of the original reciepts).

There was a least one processing specification (possibly even mandatory)
during the 90s ... where each transaction was giving a unique
transaction identifier ... and transaction logs were only to be
referenced by the transaction identifier. However, consumers only
identified their account number by their account number ... and so
processes, like dispute resolution, continued to use the account number
as the identifier (and you need something else to be used for
authentication ... since the use of the account number as the identifier
is so ingrained into so many processes ... including the minds of the

however, with regard to the magstripe, there are lots of widely
published reports about magstripe being skimmed at point-of-sale
devices, at ATM machines (and/or the value of the magstripe being
skimmed in transit) ... and counterfeit magstripe/cards being produced
for fraudulent transactions.

here is a news article from yesterday about magstripe from credit/debit
cards being skimmed (including the CVV field) and used to rewrite the
magstripe on (magstripe) gift cards:

Gift Cards Carrying Cloned Data Used To Steal Gas

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to