Article on passwords in Wired News

[Anne & Lynn Wheeler]

At 02:19 AM 6/5/2004, Ernst Lippe wrote:
>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 majordomo at metzdowd.com