John Denker wrote:
The phrase "there are no sensitive secrets today" sounds very strange
by itself, and doesn't sound much better in context.
I assume the intended meaning was more along the lines of:
== The set of things you want to keep secret has zero overlap with
== the set of things you might want to use as an identifier.
this is sort of the track of the x9a10 working group activity on x9.59
... which had been given the requirement to preserve the integrity of
the financial infrastructure for ALL retail payments.
the analysis was that the account number had become grossly overloaded.
one hand it was mainstay of normal business process required to be
widely available and divulged for large number of different business
processes. on the other hand, it was also effectively being used for
authentication; aka knowing the account number was frequently sufficient
for authenticating the transaction.
the severely conflicting requirement for account number use ... on one
hand being widely available and divulged for large number of different
business processes ... and on the other hand needing to be kept private
and confidential for authentications purposes ... created opportunity
for numerous compromises. this also somewhat has led to my periodic
observation that the planet could be buried under miles of cryptography
(for hiding account numbers) and it still wouldn't be sufficient to
prevent account numbers from leaking.
this is further aggravated by the long term findings that the majority
of fraud have involved insiders who have legitimate access to the
information. it is even further aggravated by account number being
static data and therefor vulnerable (as an authentication mechanism) to
skimming and replay attacks.
x9.59 called for dynamic data on the actual transaction for
authentication (as countermeasure to both replay attacks and mitm
attacks). x9.59 also called for account numbers used in x9.59
transactions would not be honored when used in "non-authenticated"
transactions (countermeasure to skimming, security breaches, and data
breaches).
the combination of specifications in the x9.59 standard drastically
reduced the sensitive nature of account numbers. the crooks could have
all the skimming, security breaches and data breaches involving account
number sources and it would be insufficient to execute fraudulent
transaction.
a few recent posts mentioning x9.59 drastically reducing sensitive
nature of account numbers.
http://www.garlic.com/~lynn/2006c.html#34 X.509 and ssh
http://www.garlic.com/~lynn/2006d.html#26 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006f.html#16 trusted repositories and
trusted transactions
http://www.garlic.com/~lynn/aadsm22.htm#1 GP4.3 - Growth and Fraud -
Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a
desktop near you
and my old long time standby of security proportional to risk ... with
regard to the possible large discrepancy involving the value of skimmed
account number data to the crooks (in the current infrastructure)
vis-a-vis the worth of account number data to retail merchants
(the crooks can possibly afford to mount a massive attack that merchants
can't reasonably be expected to afford to defend against)
http://www.garlic.com/~lynn/2001h.html#61
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
