Nick Owen wrote: > I think that the cost of two-factor authentication will plummet in the > face of the volumes offered by e-banking. Also, the more uses for the > token, the more shared the costs will be. The question to me is will > the FIs go with a anything beyond secure cookies, IP address validation > and unique images. Will they be forced to by the powers that be or by > disclosure requirements after the basic systems are thwarted?
two-factor authentication per se, isn't necessarily the panecea. pin-debit ... has a magstripe card as "something you have" and a pin "as something you know". as recently mentioned, compromised ATM &/or POS machines have been able to skim the magstripe and the pin .... enabling creation of counterfeit cards and fraudulent transaction. in x9.59, http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subpubkey.html#privacy a hardware token can digitally sign the actual financial transaction. this would be single factor, "something you have" authentication. skimming and/or harvesting the transaction and/or transaction log files http://www.garlic.com/~lynn/subpubkey.html#harvest doesn't enable either counterfeit cards and/or fraudulent transactions. the issue of a PIN, in conjunction with the magstripe card for two-factor authentication, was a countermeasure against lost/stolen card. However, skimming as a threat, is able to capture both the PIN and the card magstripe information, enabling fraudulent transactions. a single-factor authentication hardware token ("something you have") that digitally signs the transaction is sufficient countermeasure against skimming and harvesting. Enforced PIN-debit ... i.e. where the magstripe can't be used w/o the PIN ... turns out to be a countermeasure against some of the transaction log harvesting (the type of data breach stories recently in the press) ... since the PIN information isn't normally carried in the transaction log. The issue with the transaction log is that there are several other merchant business processes that require access to transaction information. The issue with magstripe and PINs ... is the threat and vulnerability model effectively is a replay attack ... static data that can be relatively easily recorded and repeated in fraudulent transactions (and/or used to create counterfeit magstripe). A "single factor" authentication hardware token that digitally signs that transactions, is countermeasure against attacks recording static data for replay-type attacks. Adding a PIN or biometric authentication to a hardware token for "two factor authentication" .... doesn't improve the countermeasure to skimming and harvesting attacks. The PIN or biometric authentication in conjunction with a hardware token is primarily countermeasure for lost/stolen token ... not countermeasure for skimming/harvesting replayable information. There is has been a separate issue with the use of pin/passwords shared-secrets http://www.garlic.com/~lynn/subpubkey.html#secrets for "something you know" authentication, is people having large number of different accounts .... each, supposedly requiring unique "something you know" shared secrets. The estimate is that possibly 30percent of the debit cards have PINs written on them. The issue is basic human factors and blindly adding "something you know" shared secret as a second authentication factor doesn't necessarily significantly improve the situation. so you are possibly faced with having to fundamentally rework some of the authentication landscape to compensate for well documented human short comings. So two possible pieces for reworking this portion of the authentication landscape (for human factor shortcomings with proliferation of large number of shared-secrets) 1) certified tokens that accept PINs for operation. the PINs are shared-secrets since they don't travel past the token. The token is in the person's possession and the PIN is just for activating certified token operation. this can contribute to the person being able to initialize all tokens to the same PIN 2) transition from institution-centric tokens to person-centric tokens ... aka rather than every institution in the world issuing a token ... and each token possibly requiring a single PIN, people can acquire some small number of personal tokens and register their personal tokens for valid "something you have" authentication at different institutions. A big issue in the recent data breach stories with respect to security PAIN acronym P ... privacy A ... authentication I ... integirty N ... non-repudiation is that many of the infrastructures tend to have relatively strong integrity requirements for their business records. this protects the infrastructure business operations. however, they tend to have much lower privacy requirements ... in part because the large number of business processes that require access to those records. furthermore, the privacy threats and vulnerabilities isn't directly against the infrastructures .... the privacy threats and vulnerabilities are against their customers. This, then becomes, you offering to pay for all automobile repairs and maintenance for the rest of the people in your town ... because it improves the overall safety of the roads. There is a large privacy threat and vulnerability for the customers of these institutions .... because of the pervasive use of static data for authentication and the readily available technology to record and replay/counterfeit that static data for fraudulent transactions. So the privacy play is hard * pervasive use of static data for authentication * pervasive use of the same static data for multitude of standard business processes * readily available technology to record and replay/counterfeit static data for fraudulent transactions * the privacy threat and vulnerability risk isn't directly for the majority of the institutions that need to provide the countermeasures * entities directly at risk aren't in position to provide most of the countermeasures * the value of the static data to the institutions is typically relatively low * the value of the fraudulent use the static data to the entities at risk can be extremely high ... aka, this is related to the security proportional to risk posting http://www.garlic.com/~lynn/2001h.html#61 where business operations have a frequent requirement to access the static data as part of normal business operations ... and the value of that data is proportional to the profit off an individual transactions. the business operations aren't directly at risk to the privacy threat and vulnerability. the entities having the privacy threat and vulnerability can be at risk equal to their credit limit (or their bank account). --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]