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,

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

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

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
* 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

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

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to