somewhat related
Study Finds Bank of America SiteKey is Flawed
http://it.slashdot.org/it/07/02/05/1323243.shtml
Study Finds Security Flaws on Web Sites of Major Banks
http://www.nytimes.com/2007/02/05/technology/05secure.html?ref=business
The Emperor's New Security Indicators
http://www.usablesecurity.org/emperor/
from above:
We evaluate website authentication measures that are designed to protect users from
man-in-the-middle, "phishing", and other site forgery attacks. We asked 67 bank
customers to conduct common online banking tasks. Each time they logged in, we presented
increasingly alarming clues that their connection was insecure. First, we removed HTTPS
indicators. Next, we removed the participant's site-authentication image---the
customer-selected image that many websites now expect their users to verify before
entering their passwords. Finally, we replaced the bank's login page with a warning page.
After each clue, we measured whether participants entered their passwords or withheld
them.
... snip ...
somewhat the issue ... from previous posts in this thread:
http://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL
and recent post/thread from early last month on the subject
http://www.garlic.com/~lynn/2007b.html#53
http://www.garlic.com/~lynn/2007b.html#54
... originally SSL was going to prevent man-in-the-middle attack because the
person
knew the website that they were going to talk to and the corresponding URL.
They would
enter that URL into the browser and the browser would validate that the
contacted website
was in fact the website for that URL (assuming the entered URL was HTTPS and
not HTTP)
early on, SSL was perceived to be too expensive, and so relegated it to just
checkout/payment.
now the user entered URL with HTTP and the website wasn't validated ... so
could be man-in-the-middle. at some point the user clicked on https
(checkout/payment) button provided by the website. now instead of HTTPS
validating that the user was talking to the webserver that they thot they were
talking to ... HTTPS was validating that the webserver was whatever webserver
that the webserver was claiming to be
(since the webserver was providing both the HTTPS URL and the SSL digital
certificate).
so as the user convention of clicking on provided buttons proliferated ... the
cracks/gaps widened between what webserver the user thot they were talking to and
the webserver they might actually be talking to (since there was less & less a
connection between what they thot of as a browser and the URLs that were being
validated by SSL).
So one of the possible countermeasures was for a website to provide unique "something you know" authentication ... i.e. something hopefully only you knew (so you had higher degree of confidence that you were actually talking to the website you thot you were talking to.
The problem was that if the communication was already talking to
man-in-the-middle website impersonation ... there is nothing that would prevent
the man-in-the-middle from impersonating the website to the consumer ... and
impersonating the consumer to the actual website. Effectively, by definition
for man-in-the-middle, the man-in-the-middle transparently passes communication
in both directions (except possibly modifying URLs and internet addresses
contained in the traffic as needed).
in effect, the mechanism is a countermeasure to simple website impersonation
attacks ... but not to website man-in-the-middle attacks.
other refs
http://www.garlic.com/~lynn/2007c.html#3 "New Universal Man-in-the-Middle Phishing
Kit"?
http://www.garlic.com/~lynn/2007c.html#51 Securing financial transactions a
high priority for 2007
misc. past posts mentioning man-in-the-middle attacks
http://www.garlic.com/~lynn/subintegrity.html#mitm
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
