Caller ID "spoofing" 2973

we had worked on the original payment gateway for what has since become to be called e-commerce

part of using this technology called SSL that a small client-server startup in the valley had ... for hiding the account numbers while they were being transmitted over the internet.

however, major exploits (predating the internet) have been skimming the account number at the transaction site and data breaches copying the transaction log file ... minor reference trying to put into perspective security proportional to risk

using SSL for hiding the account number during transmission did nothing to address the major existing vulnerabilities. furthermore, the arrival of the internet tended to create additional vulnerabilities for the transaction log file (which weren't addressed by SSL). some amount of work was done on adding additional authentication processes for internet transactions; however that also failed to address the major vulnerabilities of skimming and breaches ... and then using the account number in non-authenticated transactions.

x9.59 looked at the requirement for preserving the integrity of the financial infrastructure for all retail payments from two ways

1) authenticated transactions (similar to other types of efforts going on in the mid-90s)

and

2) business rule that account numbers used for x9.59 transactions could not be used in non-authenticated transactions.

the second issue was a recognition that with the account numbers being needed by a broad range of different business processes ... not just any initial transaction authorization. therefore you could blanket the earth under miles of crypto attempting to hide account numbers ... and there would still be leakage. with x9.59, "x9.59" account numbers could be subject to all sorts of breaches and skimming, and the crooks could still not use them for account fraud.

not too long ago there was a question in some forum about security would require equal strength confidentiality and authentication. this is somewhat from the security taxonomy PAIN

P - privacy (sometimes CAIN, confidentiality) A - authentication I - integrity N - non-repudiation

the existing account vulnerabilities and fraud is because just knowning the account number is sufficient to perform fraudulent transactions. as a result, the countermeasure is to have ever increasing amounts of cryptography for hiding the account numbers. In practice this is not viable, inpart because of the number of business processes that require access to the account numbers. Also, there has been a relatively recent study, re-affirming long standing information, that majority of data breaches involve insiders.

So the approach by x9.59 was to eliminate the "shared-secret" status of (x9.59) account numbers (i.e. akin to pbuttwords, just knowing the value enables impersonation and-or fraud) ... using strong authentication as a subsbreastute for strong privacy-confidentiality.

For x9.59, it is no longer necessary to have strong encryption to enforce privacy-confidentiality ... as part of preserving the integrity of the financial infrastructure for all retail payments ... it is just necessary to have consistent strong authentication applied to all transactions (transactions for the buttociated account number w-o required authentication are rejected).

for other drift ... merged security taxonomy and glossary

for some additional drift ... discussion of SSL exploits-vulnerability buttociated with MITM-attacks and-or phishing (in part, because SSL is frequently not deployed as originally intended):

--