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 consumers). 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 http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=1121867212622215212&block= --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
