[FYI] Did Encryption Empower These Terrorists?

lynn.wheeler at firstdata.com lynn.wheeler at firstdata.com
Tue Sep 25 11:41:38 EDT 2001





what I (attempted?) to say was that the "typical" merchant and or
"typically" at merchants ... the account number file is vulnerable and
frequently is also on the same system as that running the web server. The
original/first implementation had the account file and the transactions
performed on a separate back-end system. That original implementation
didn't become the prevailing deployed operational infrastructure.
It doesn't matter that the original implementation of a separate back-end
system was better or worse ... it didn't prevail.

In general, the harvesting of the account number master file is a major
vulnerability ... whether it is on the same system or a different system.
Moving it to a different system may or may not make it less vulnerable to
harvesting by internet-mounted attacks. Mostly, in the past, "insider"
attacks have been considered 90% of the vulnerability problem (although
recently internet-mounted external attacks get more of the press).

For the very first implemetation, we believed we had an implementation for
back-room credit card transactions that was significantly less vulnerable
to internet-mounted attacks. The point was that is not what prevailed and
is not what is commoningly deployed.


ben laurie <ben at algroup.co.uk> wrote:

It is easy to avoid this piece of bad design, for example by
transferring asymmetrically encrypted order details to a back-end system
(via email is a popular choice).

Of course, the system is still vulnerable to trojan-style attacks (in
fact it seems to me that even this could be avoided with some cunning
client-side work - it would even be valuable to extend, say, SSL to
permit this - I wonder if it would be worth describing how this could be
done?).

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to
majordomo at wasabisystems.com







---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com




More information about the cryptography mailing list