The problem is here, we are blaming the protective device for not being able to protect against the deliberate use of an attack that bypasses, not challenges it - by exploiting the gullibility or tendency to take the path of least resistance of the user. The real weakness in HTTPS is the tendency of certificates signed by Big Name CAs to be automagically trusted - even if you have never visited that site before. yes, you can fix this almost immediately by untrusting the root certificate - but then you have to manually verify each and every site at least once, and possibly every time if you don't mark the cert as "trusted" for future reference.
that is why we coined the term merchant "comfort" certificates some time ago. my wife and I having done early work for payment gateway with small client/server startup in menlo park ... that had this thing called SSL/HTTPS ... and then having to perform due diligence on the major issuers of certificates .... we recognized 1) vulnerabilities in the certificate process and 2) information hiding of transaction in flight only addressed a very small portion of the vulnerabilities and exploits.
lots of past discussions related to our use of merchant comfort certificates from the past:
http://www.garlic.com/~lynn/subpubkey.html#ssl
we concluded that a real issue is that way too much of the infrastructure is based on shared-secrets and there was no realistic way of providing blanket protection to all the exposures and vulnerabilities of such shared-secret infrastructures. somewhat related discussion in the security proportional to risk posting:
http://www.garlic.com/~lynn/2001h.html#61
so rather than trying to create a very thick blanket of encryption covering the whole planet .... a synergistic approach was attempting to provide alternatives to as much of the shared-secret paradigm as possible. As in the referenced post:
http://www.garlic.com/~lynn/aepay11.htm#53 authentication white paper
strong encryption of identification and privacy (and shared-secret) information is good ... but not having identification, privacy and shared-secret information is even better.
there are all sorts of ways of obtaining shared-secret information (and/or privacy and identification information prelude to identity theft) .... including various kinds of social engineering.
as previously mentioned requirement for X9.59 standard was to preserve the integrity of the financial infrastructure for ALL electronic retail payments. As per previous notes, X9.59 with strong authentication eliminates the account number as a shared-secret as well as eliminating requirements for name, address, zip-code, etc as part of any credit card authentication process (strong encryption of vulnerable information is good, not having the information at all is even better).
ALL in addition to referring to things like credit cards, debit cards, atm transactions, stored-value transaction, over the internet, at point-of-sale, face-to-face, automated machines, etc .... also refers to ACH transactions. ACH information allows for unauthenticated push or pull transactions. Social engineering requesting bank account information so somebody can push tens of millions into your account also allows for them to generate a pull transaction removing all the money from your account. Part of the above posting on the authentication white paper .... makes references to securing ACH transactions:
http://www.asuretee.com/company/releases/030513_hagenuk.shtm
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
