What is that card? There are some schemes that use debit cards with an embedded smartcard. If you are referring to one of these schemes I don't think that they are more secure than TAN's. If it is a card that you carry along with you, the risk that it will be stolen is higher than the risk that some TAN's will be stolen, because in most cases you are able to store your TAN's in a safe place in your home. The only apparent advantage of using a card is the PIN, i.e. "something you know", but all internet banking application that I have seen require some form of password which has at least the same security as a PIN. If it really is a debit card, then the security is probably even worse. In several debit card schemes the PIN for cash transactions is the same as the PIN for web transactions ( if the users have the possibility to change either PIN, it is a safe bet that they will be both the same), and it it not at all difficult to determine the PIN in this case.
there is two factor authentication:
* something you have * something you know
in this scenario we could conclude there are are a least 3-4 types of "something you know" authentication.
* re-usable "shared-secret", things like run-of-the-mill account numbers .. where knowing the account number is sufficient to perform a fraudulent transaction. these are extremely attractive to criminals ... because merchants tend to aggregate them in transaction files ... so a single theft of the transaction file could represent an extremely huge return-on-investment (benefit/risk trade-off). some past discussion of this with regard to security proportional to risk: http://www.garlic.com/~lynn/2001h.html#61
* shared-secret, one-time account numbers. this is a fairly adequate counter-measure for the major fraud scenario ... harvesting merchant account files. there can still thefts/copying of individual account sheets, just like there can be thefts of individual cards. note however that the benefit/risk of individual thefts is orders of magnitude less than the merchant transaction file harvesting. as per the above url discussion of security vis-a-vis risk ... harvesting a merchant account file of re-usable account numbers may represent a $50m exposure ... and hundreds of thousands of dollars expense to a bank to block the affected accounts and re-issue new cards. one time numbers may represent little or no countermeasure to the individual vulnerability .... but it represents a countermeasure for the aggregate vulnerability that is several orders of magnitude larger and more expensive
* something you have cards ... that are supposedly hard to counterfeit ... but changing technology over the years have made them more and more vulnerable, PINs with most of these existing cards have been somewhat "something you know" shared secret ... i.e. some flavor of it is transmitted to the financial institution. skimming technology captures the magstripe value as well as the entered PIN; counterfeit cards are then manufactored ... along with notation regarding the correct pin. this skimming also relies on re-useable values ... and skimming operations can be setup and automated to capture tends of thousands
* newer generation of something you have cards with embedded chips and non-shared secret PINs ... i.e. the correct PIN has to be sent to the chip ... before the chip performs the correct operation. Some of these have acquired the "yes card" label in some parts of euro-press. transaction information is skimmed ... sufficient to create a counterfeit chip-card. these counterfeit chip-cards answer "yes" to everything ... i.e. whether the pin entered was correct, whether the transaction value is less than limit, etc. again the skimming process has been automated, allowing the capture of information for potentially thousands of counterfeit cards (the skimming can be identical to that used with magstripe cards).
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
