[13525] in cryptography@c2.net mail archive
Re: An attack on paypal
daemon@ATHENA.MIT.EDU (Anne & Lynn Wheeler)
Sun Jun 8 22:07:02 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Sun, 08 Jun 2003 20:00:40 -0600
To: "Dave Howe" <DaveHowe@gmx.co.uk>
From: Anne & Lynn Wheeler <lynn@garlic.com>
Cc: "Anne & Lynn Wheeler" <lynn@garlic.com>,
"James A. Donald" <jamesd@echeque.com>,
"Email List: Cypherpunks" <cypherpunks@lne.com>,
"Email List: Cryptography" <cryptography@metzdowd.com>
In-Reply-To: <007301c32e23$cdddbce0$01c8a8c0@DaveHowe>
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@metzdowd.com
