[email protected] (Charles Mills) writes: > I think much of the problem is with credit card numbers > themselves. There are only ~10**16 possible credit card numbers -- > many fewer if you allow for the fact that only certain combinations > are valid. A credit card number is easier to brute-force guess than > its encryption key, format-preserving or not.
trivia/background long ago and far away we got called as consultants to small client/server startup that wanted to do payment transactions on their server, they had also invented this technology called "SSL" they wanted to use; the result is now sometimes called "electronic commerce". Then somewhat having done "electronic commerce", in the mid-90s we were asked to participate in the (financial industry) x9a10 standards working group which had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments (not just internet, *ALL*, point-of-sale, attended, unattended, credit, debit, ACH, i.e. *ALL*). part of this is we did end-to-end threat analysis and attetmpted to use a number of metaphors to characterize the existing paradigm: dual-use ... since information from previous transactions can be used for fraudulent transactions, that information has to be kept totally confidential and never divulged. at the same time the same information is required in dozens of business processes at millions of locations around the world. we've periodically commented that even if the planet was buried under miles of information hiding encryption, it still wouldn't stop leakage security proportional to risk ... the value of the transaction information to the merchants is the profit on the transactions, which can be a couple dollars (and a couple cents for the transaction processor) ... the value of the information to the crooks is the account balance and/or credit limit ... as a result the crooks can afford to outspend the defenders by a factor of 100 times. ... the x9a10 financial standard working group came up with a transaction standard that eliminated the "dual-use" characteristic of the account number ... which met that it no longer needed to be kept hidden (and the earlier work we did on "electronic commerce" was the major use of "SSL" for hiding the account number ... which in the new transaction standard was no longer necessary). Later we were tangentially involved in the cal. state data breach notification law. A lot of the participants were heavily involved in privacy issues and had done detailed, in-depth public surveys. The #1 issue was identity theft, primarily of the form of fraudulent financial transactions as the result of breaches and there was little or nothing being done about the breaches. An issue is typically an entity/institution takes security measures in self protection, In the case of the breaches, the institution wasn't at risk ... it was their customers. It was hoped that the publicity from the breach notifications would prompt breach countermeasures. Note in the years since the cal. state breach notification act there have been numerous federal (state preemption) acts introduced ... about evenly divided between those similar to the cal. act and those that would effectively eliminate any requirement for notification (frequently ingeniously disguised as criteria on when notification was required). The PCI DSS specification came out after the appearance of the cal. state data breach notification and referenced by federal legislation attempting to eliminate notification requirements ... "because the industry was addressing the problem". Early jokes about the PCI DSS certification was that it was relatively straight-forward ... but everybody with PCI DSS certification that had a breach would have their certification revoked. -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
