|
Posted by Paul Rubin on October 24, 2007, 9:29 pm
If you were Registered and logged in, you could reply and use other advanced thread options
daw@taverner.cs.berkeley.edu (David Wagner) writes:
> >You really want hardware authentication tokens like Paypal is now using.
> >https://www.paypal.com/securitykey
>
> How does this defend against man-in-the-middle phishing attacks?
> (I'm talking about attacks where the attacker presents a spoofed
> web site, and acts as a man-in-the-middle relaying challenges and
> responses between the victim and the legitimate website.)
Fair enough--I may have missed or forgotten some of the earlier
discussin in the sporge flood. I have to say I don't think client
certs help with that so much either. Authentication tokens do, at
least, stop the phisher from capturing the user's credential
(i.e. password) and re-using it later, in the case where the attacker
gets control of the client computer and compromises the key store.
|
|
Posted by David Wagner on October 24, 2007, 10:28 pm
If you were Registered and logged in, you could reply and use other advanced thread options
Paul Rubin wrote:
>I have to say I don't think client
>certs help with [man-in-the-middle phishing attacks] so much either.
Can you elaborate? If the bank's web server uses SSL and knows the
public key of each of their account holders, then I would have thought
that would defeat MITM attacks.
>Authentication tokens do, at
>least, stop the phisher from capturing the user's credential
>(i.e. password) and re-using it later, in the case where the attacker
>gets control of the client computer and compromises the key store.
Yup.
|
|
Posted by Paul Rubin on October 25, 2007, 12:05 am
If you were Registered and logged in, you could reply and use other advanced thread options
> >I have to say I don't think client
> >certs help with [man-in-the-middle phishing attacks] so much either.
>
> Can you elaborate? If the bank's web server uses SSL and knows the
> public key of each of their account holders, then I would have thought
> that would defeat MITM attacks.
Oh yes, that would do it, I guess. Typically in SSL one just checks
the validity of the signature on a certificate. That means the
attacker could present a legitimate client certificate (from an
illicit or hijacked account) to the server while opening a session
logging in under the phished account. Using the certificate serial
number to identify the account (assuming one trusts the CA to keep
them unique) is one obvious fix that avoids messing with the actual
public keys. I guess one should always do this.
|
|
Posted by Anne & Lynn Wheeler on October 25, 2007, 6:40 am
If you were Registered and logged in, you could reply and use other advanced thread options
> Can you elaborate? If the bank's web server uses SSL and knows the
> public key of each of their account holders, then I would have thought
> that would defeat MITM attacks.
we claimed that in x9.59 financial standard we eliminated the
requirement to encrypt the transmission.
we had been called in to consult with this small client/server
startup that wanted to do payment transactions on their server
http://www.garlic.com/~lynn/subnetwork.html#gateway
they had this technology they called SSL they had invented and they
wanted to use it in conjunction with the payment transactions. They had
the SSL domain name certificates as part of webserver authentication
... but for payment transactions we had to enhance it with mutual
authentication ... for interaction between the webserver and the payment
gateway. we also had to do detailed end-to-end business process analysis
of the while operation ... including this things that were starting to
call themselves certification authorities.
recent postings on the subject in some other threads
http://www.garlic.com/~lynn/2007q.html#30
http://www.garlic.com/~lynn/aadsm27.htm#62
afterwards we got involved in the x9a10 financial standards working
group that had been given the requirement to preserve the integrity of
the financial infrastructure for all retail payments. As part of that
effort we eventually did a much detailed vulnerability and threat model
study (including analysing exactly what benefits did the digital
certificates provide in the previous effort related to SSL ... which is
now frequently referred to as electronic commerce).
x9a10 effort resulted in the x9.59 payment standard that required every
transaction to be authenticated.
http://www.garlic.com/~lynn/x959.html#x959
In the x9.59 standards document, it shows how this can be done with
ec/dsa digital signature on every transaction and validated with a
public key on file with the authorizing financial instituation (w/o
requiring any digital certificate, the on-file public key making digital
certificates redundant and superfluous).
part of the detailed vulnerability study found that there were actually
much larger exploits of the transaction logs stored at various end
points (and required for quite a few backroom business processes related
to payment transactions) than were ever happening with evesdropping on
transmitted transactions. so part of x9.59 financial standard (as part
of the requirements given the x9a10 financial standard working group to
preserve the integrity of the financial infrastructure for all retail
payments) ... was to eliminate all the exploits ... not just the replay
attacks from evesdropping attacks ... but also replay attacks resulting
from harvesting things like transaction logs. the other issue was there
have been studies that something upwards of 70percent of account fraud
involves insiders (who have valid, required access to the information).
so part of the solution in x9.59 financial standard was to make
evesdropping and/or havesting of previous transaction useless for
performing fraudulent transactions ... i.e. even if attackers obtained
the information (regardless of the means), it wouldn't be useful for
doing things like various kinds of replay attacks or other fraudulent
transactions. x9.59 didn't do anything about preventing unauthorized
access to the information ... it just made it so that whatever kind of
access there was ... the information couldn't be used by crooks to
perform fraudulent transactions.
as part of the mutual authentication work for the original SSL, we came
to realize that the digital certificates were redundent and superfluous
(setting up long live encrypted sessions between the webservers and the
payment gateway) ... because they both had to have registered
information (including public key) of the entities that they were
dealing with.
this was further highlighted when x9a10 working group looked as some of
the other payment efforts going on at the same time that were oriented
towards including digital certificates as part of a public key and
digital signature operation.
one of the issues was that x.509 identity digital certificates from
the early 90s were starting to become overloaded with personal
information. by the mid-90s, numerous institutions had started to
realize this represented significant liability and privacy problems
... and had regressed to something they called relying-party-only
certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo
these involved only including some sort of account number and/or other
kind of database record locator (say userid) in the digital certificate
... and all the required information was onfile (and not being
repeatedly sprayed all over the world in digital certificates). However,
it is trivial to show that part of registration process that preceeds
generating the digital certificate, the person's public key is also
place on-file. As a result, it is then trivial to demonstrate that the
digital certificate becomes redundant and superfluous.
The other part ... at least as far as payment transactions were
concerned ... for even the reduced "relying-party-only" digital
certificate processing (i.e. appending digital certificates
to typical payment transaction) ... increased the payload (and
typical processing) overhead by two orders of magnitude
http://www.garlic.com/~lynn/subpubkey.html#bloat
not only were the digital certificates redundant and superfluous ... but
in the typical payment transaction operation, they represented a
100-fold increase in payload and processing overhead.
the x9 financial standards group did make some effort to look at the
(redundant and superfluous) digital certificate enormous payload bloat
in payment transactons with a standard project for compressed digital
certificates (possible objective of reducing the enormous payload bloat
from 100 times to possibly only 3-10 times).
one of the suggestions for compressed digital certificates was to
eliminate all fields that were the same across all the digital
certificates. my suggestions was doing information compression ...
i.e. eliminate all fields that were already on-file with issuing
relying-party. I was then able to show that all fields would be
already on-file and therefor all fields could be eliminated. Rather
than having a certificateless infrastructure
http://www.garlic.com/~lynn/subpubkey.html#certless
there would be a transition to issuing zero-byte digital certificates
... and that all transactions would always have zero-byte digital
certificates appended.
i.e. the redundant and superfluous nature of the digital certificates
were futher reinforced (at least in payment transactions) by their
enormous (two orders of magnitude) payload and processing bloat.
|
|
Posted by Anne & Lynn Wheeler on October 25, 2007, 7:00 am
If you were Registered and logged in, you could reply and use other advanced thread options
> Oh yes, that would do it, I guess. Typically in SSL one just checks
> the validity of the signature on a certificate. That means the
> attacker could present a legitimate client certificate (from an
> illicit or hijacked account) to the server while opening a session
> logging in under the phished account. Using the certificate serial
> number to identify the account (assuming one trusts the CA to keep
> them unique) is one obvious fix that avoids messing with the actual
> public keys. I guess one should always do this.
re:
http://www.garlic.com/~lynn/2007q.html#72 Value of SSL client certificates?
... see the "yes card" scenario ... where they refer to "static data"
authentication ... basically the digital certificate w/o the individual
digital signature (which has been referred to as "active data")
http://www.garlic.com/~lynn/subintegrity.html#yescard
some of this (again) is related to the enormous processing and payload
bloat associated with digital certificates (at least in the payment
transaction scenario)
part of the issue is whether there is session level authentication
... but actual transactions still remain vulnerable (potentially
requiring enormous amounts of encryption and other security mesures to
try and hide the vulnerable transactions)... discussed in these postings
on the "naked transaction" metaphor
http://www.garlic.com/~lynn/subintegrity.html#payment
|
| Similar Threads | Posted | | VPN vs SSL client side certificates | September 6, 2005, 12:48 pm |
| how to purge my local client-certificates from my pc? | February 26, 2006, 5:00 am |
| VPN Client Software | July 6, 2004, 7:48 am |
| Second Life Client - Security? | May 17, 2007, 10:11 pm |
| 用了F-Secure AntiVirus Client Security的掃瞄結果 | November 16, 2004, 8:02 pm |
| Windows 98 client authentication failure | November 27, 2006, 7:04 am |
| X.509 Digital Certificates | March 7, 2005, 8:56 pm |
| Chaining x.509 certificates | April 27, 2005, 3:46 pm |
| Chaining x.509 certificates | April 27, 2005, 3:48 pm |
| What are the differences between the certificates *.pfx *.p12 *.cer *.crt *.spc *.p7b ?? | July 19, 2005, 2:02 pm |
|
XML site map