An attack on paypal

Anne & Lynn Wheeler lynn at garlic.com
Sun Jun 8 22:00:40 EDT 2003


At 02:09 AM 6/9/2003 +0100, Dave Howe wrote:
>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 majordomo at metzdowd.com



More information about the cryptography mailing list