Subject: Re: Symptoms vs. Causes (was next step on web phishing draft)

From: Bernard Aboba <[email-masked]>
Date: Mon, 10 Sep 2007 18:06:55 -0700 (PDT)

Michael Dillon said:

"Personally, I would like to see some more criticism of the fact that
this draft is about Phishing, a symptom of security problems, rather
than about strengthening a weakness in Internet security. It is entirely
possible to "solve" the phishing problem without strengthening the
network, and possibly even introducing new weaknesses. Being too focused
on one symptom is not a good way to approach security. Indeed, it is
entirely possible that the solution to phishing lies with the banking
system, not with the Internet or IETF."

I think this is a very good point.  Ultimately, the explosion of attacks 
that we are seeing is fed by the ability of miscreants to convert personal
information into cash.  Phishing is only one avenue for this - the 
miscreants have shown an ability to quickly develop new attacks and 
business models.  

So we need to think carefully about distinguishing symptoms from 
underlying causes.  If we just focus on symptoms, we will be 
playing a game of Wack-a-mole.  For example, the document states that 
anti-phishing measures MUST support passwords, yet with the increasing 
prevalance of key stroke logging malware, it is not clear to me that 
merely avoiding the sending of cleartext passwords over the wire is 
enough. 

In terms of underlying causes, the ease with which personal information 
(social security number, bank account #s, birthdate, etc.) can be 
utilized for identity theft and subsequent fraud is sobering.  A sampling 
of recent stories in the news:

http://www.identitytheftdaily.com/
http://www.forbes.com/feeds/ap/2007/08/16/ap4027723.html
http://www.schneier.com/blog/archives/2005/08/identity_thief.html
http://mortgagefraud.squarespace.com/journal/2004/4/7/id-theft-leads-to-charges-for-six-amerifunding-scheme.html
http://www.usdoj.gov/usao/pae/News/Pr/2006/jul/whitesmith_release.pdf
http://www.courant.com/news/custom/topnews/hcu-mortgage-0828,0,3482889.story
http://money.guardian.co.uk/scamsandfraud/story/0,,1669152,00.html

While I'm willing to accept that many of these stories originate in 
fundamental weaknesses within the financial system, I'm not so sure that 
the IETF has no role to play with respect to development of technology 
that could help. 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Shumon Huque <[email-masked]>
Date: Tue, 11 Sep 2007 15:35:22 -0400

> system, not with the Internet or IETF."

Phishing is not a problem only for the banking industry. We have 
discovered phishing websites on the Internet designed to mimic
web authentication systems deployed at my University, obviously
designed to steal our passwords.

I certainly agree with attacking the cause rather than symptom. But a
portion of Sam Hartman's draft is in fact dealing with a cause of the
symptom. Namely the part that is trying to protect user credentials
from disclosure to an unauthorized party -- by proposing to eliminate
the near ubiquitous phenomenon of sending passwords over TLS to an 
application server. And using proper cryptographic authentication 
techniques that don't transmit long-lived passwords or keys over the 
network period. It's about time the IETF stood up and said that.

And yes, I agree that a new properly designed version of HTTP Digest 
authentication might be one way to help. As well as the various zero
knowledge protocols.

> merely avoiding the sending of cleartext passwords over the wire is 

We can have a discussion about whether long lived human memorizable
passwords have a future. But we have to deal with the reality today.
I suppose that some time in the distant future we might all be using
public key authentication, carrying around our PKI credentials on
smart cards, mechanisms to interface those cards to endsystems are
commonplace, systems and federations of PKIs are ubiquitous, proper
certificate revocation infrastructure is in place etc etc .. But we
are very far from that world.

If passwords altogether are eliminated, then I presume malware will
just evolve to deal with it. So the whack-a-mole game will continue 
as usual. Users could be tricked into installing a trojan horse that
captured their private key or logged the passphrase that they typed 
to unlock it. Should we be recommending non-reusable passwords or
smartcards/tokens everywhere?

At some level, you have to trust the software on your endstation.
Even if you've protected your authentication credentials, not 
trusting endstation software means that you may not be able to 
conduct any private or sensitive tasks on it. I don't think this 
problem can be solved until we have radically more secure designs 
in both operating systems and applications. Even that may not be 
enough.

--Shumon.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 11 Sep 2007 16:33:15 -0400

>>>>> "Shumon" == Shumon Huque <[email-masked]> writes:

    Shumon> And yes, I agree that a new properly designed version of
    Shumon> HTTP Digest authentication might be one way to help. As
    Shumon> well as the various zero knowledge protocols.

I believe that http digest plus channel bindings does meet all the
requirements that draft-hartman-webauth-phishing discusses for
authentication systems.  Clearly the protocol cannot define the UI issues.

I'm not sure I prefer the approach of revising http digest, but I do
believe it would meet the requirements of my draft.

---

From: David Morris <[email-masked]>
Date: Tue, 11 Sep 2007 13:55:54 -0700 (PDT)

Actually, a fundamental problem with the current protocol is that there
was little attention paid to the requirements of UI design experts. The
natural result is that application developers worked with what they had to
produce an interface usable by their average user. Any critique of the
protocol or new protocal in this space MUST be consider interactive
usage AND unattended program to program authentication.

In the end 'phishing' is about UI and not protocols.

Dave Morris

---

From: David Morris <[email-masked]>
Date: Tue, 11 Sep 2007 13:55:54 -0700 (PDT)

Dave Morris

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Sep 2007 17:07:34 -0400

> In the end 'phishing' is about UI and not protocols.
+1

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 11 Sep 2007 16:24:43 -0700 (PDT)

> network period. It's about time the IETF stood up and said that.

I agree with that. 

> passwords have a future. But we have to deal with the reality today.

Why is it an either/or?  Can't we do both?  My  issue with was with saying 
that solutions MUST support passwords.  

> public key authentication... but we

Smartcards aren't the only alternative here.  For example, folks in the 
KEYPROV WG make an argument that token authentication has the potential to 
become a mass market phenomenon. 

> Should we be recommending non-reusable passwords or

Frankly, I think it would be best if the IETF would develop solutions 
compatible with a range of approaches, and let customers choose. 

> conduct any private or sensitive tasks on it. 

Right.  But there's a difference between violation of privacy and being 
able to empty someone's bank account.  It's a distinction that is worth 
making, and one which the current document is not clear about.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Sep 2007 16:49:48 -0700

At Tue, 11 Sep 2007 13:55:54 -0700 (PDT),
> In the end 'phishing' is about UI and not protocols.

Quite so.

There are a large number of protocol designs--even existing
protocols--which are compatible with the general paradigm of "user U
proves possession of password P to server A without giving A a
credential which can be used to impersonate U to server B". 
HTTP Digest, TLS-PSK, SRP, and PwdHash all come to mind. The
difficult parts are:

(1) putting a sensible UI on it--including one that isn't easily
    spoofed (see the extensive literature on how hard it is 
    to build a secure UI.
(2) Getting everyone to agree on one protocol.

-Ekr

---

From: Christian Huitema <[email-masked]>
Date: Wed, 12 Sep 2007 00:51:33 -0700

> (2) Getting everyone to agree on one protocol.

Please add:

(3) The chosen solution is immune to dictionary attacks.

-- Christian Huitema

---

From: Eliot Lear <[email-masked]>
Date: Wed, 12 Sep 2007 09:59:25 +0200

>> In the end 'phishing' is about UI and not protocols.

It's about both.  We can severely limit phishing through the use of 
mutual authentication.  The UI part is that whatever mutual 
authentication you use has to be both mandatory AND easy to use.  The 
IETF has a responsibility in as much as we need to provide the protocol 
infrastructure that allows the UIs to be correct.  IMHO it's not just 
our responsibility - W3C has a role to play, and so do the IEEE and the 
ITU in as much as today's smart cards aren't really that smart.

Eliot

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 12 Sep 2007 10:00:46 +0200

The entire issue depends to some extend also on the communication model 
you have in mind.

If you consider an approach that is closer to SAML or OpenID then the 
end host interacts with the identity provider directly. If you, however, 
focus on something that is close to the AAA model then the end host 
interacts with the service provider (who then relays the information it 
gets to the identity provider, i.e., AAA server).

In the latter case the mentioned dictionary attack is more important 
since you obviously don't want to give your username/password away to an 
arbitrary entity. Still, there are obviously a number of solutions 
available to provide protection.

Ciao
Hannes

---

From: "Dan Schutzer" <[email-masked]>
Date: Wed, 12 Sep 2007 05:26:31 -0400

I agree with Eliot and based upon what we know about phishing and UI, the
more mandatory and automatic and easy to use you make the mutual
authentication, and the less you leave to the user the better off you are.

  _____  

From: Eliot Lear [mailto:[email-masked]] 
Sent: Wednesday, September 12, 2007 3:59 AM
To: Eric Rescorla
Cc: [email-masked]
Subject: Re: Symptoms vs. Causes

Eric Rescorla wrote:

 
Quite so.

It's about both.  We can severely limit phishing through the use of mutual
authentication.  The UI part is that whatever mutual authentication you use
has to be both mandatory AND easy to use.  The IETF has a responsibility in
as much as we need to provide the protocol infrastructure that allows the
UIs to be correct.  IMHO it's not just our responsibility - W3C has a role
to play, and so do the IEEE and the ITU in as much as today's smart cards
aren't really that smart.

Eliot

---

From: Michael Thomas <[email-masked]>
Date: Wed, 12 Sep 2007 05:05:57 -0700

> (3) The chosen solution is immune to dictionary attacks.
Well if we're going here then:

    (4) The chosen solution requires that I have to remember zero or fewer
          non-dictionary passwords

       Mike

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 12 Sep 2007 05:21:46 -0700

I think this discussion here is completely off base. It is thinking in terms of 1980s authentication protocol design where the relying party is the authentication authority. It is also attempting to solve a problem for a constituency that isn't here (Dan excepted) and has not been asked what its real requirements are.

First need to separate the two so that the choice of authentication mechanism is a decision between the user and the authentication authority and the relying party's role is limited to deciding whether a particular authentication authority and mechanism are adequate for their needs.
 
This means that we need to have a consistent mechanism wherby the relying party can route authentication queries to the appropriate authentication authority. In the case of a federated system where one credential can be used at multiple locations it means we need a discovery layer.
 
We have no shortage of authentication protocols (SAML, WS-*, EAP, &ct. &ct.). We have a standard for a personal identifier. What we lack is a standard discovery mechanism. OpenID has several mechanisms that are designed to integrate into the infrastructure as it is. That and SRV appear to be very useful starting points.

What has to be avoided at all costs is yet another meta-neogtiation layer to select the authentication protocol or for that matter more authentication protocols.
 
________________________________

From: Michael Thomas [mailto:[email-masked]]
Sent: Wed 12/09/2007 8:05 AM
To: Christian Huitema
Cc: [email-masked]
Subject: Re: Symptoms vs. Causes

       Mike

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Sep 2007 06:56:15 -0700

At Wed, 12 Sep 2007 00:51:33 -0700,
> (3) The chosen solution is immune to dictionary attacks.

Well, I'm not convinced that this is in fact a requirement (I note
it's not in Sam's document, not that I take that as gospel). That
said, if you want this property, then it severely narrows the
scope of possible solutions, more or less down to either ZKPP/PAKE
protocols and to public key-based authentication using random
(as opposed to password generated) keys.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Sep 2007 06:59:20 -0700

At Wed, 12 Sep 2007 09:59:25 +0200,
Eliot Lear wrote:
> 
> [1  <text/plain; ISO-8859-1 (7bit)>]
> Eric Rescorla wrote:
> mutual authentication. 

This is one possible approach, but not the only one. In fact, it's
one of my principal objections to Sam's document, so I'll refer
you to my review here.

> The UI part is that whatever mutual 
> authentication you use has to be both mandatory AND easy to use.

And, of course, spoofing resistant, which is the major unsolved
problem.

>  The 
> infrastructure that allows the UIs to be correct.

As I noted in my review, we already have a number of protocols which
potentially provide this functionality, including mutual authentication.

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Wed, 12 Sep 2007 16:20:09 +0200

Eric,
> potentially provide this functionality, including mutual authentication.

And I think looking at protocols without an understanding of how they 
are used and how they interact with the UI is just as wrong as 
attempting to fix the problem simply within the UI.  You wrote that some 
mechanisms could be made to work.  You might be right, but I'm not 
convinced.  Someone actually has to write out how these mechanisms, such 
as challenge/response ARE made to work with a web browser and a 
transactional protocol, such that they also actually solve Eliot's Dad's 
probem (EDP ;-) of the user not shooting themselves in the foot by 
transmitting the same credential to multiple disparate relying parties 
(or authenticating services, if you will).

That's fully in scope for this organization, btw.  Or for W3C.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Sep 2007 07:21:26 -0700

At Wed, 12 Sep 2007 16:20:09 +0200,
> (or authenticating services, if you will).

None of the systems I mentioned (TLS-PSK, SRP, PwdHash) has this
problem--provided that the user actually uses the new authentication
method and doesn't type his password into some Web form. But of 
course that's a UI problem, not a protocol problem.

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Wed, 12 Sep 2007 16:32:34 +0200

> course that's a UI problem, not a protocol problem.
As I wrote, the problem is in both places.  For one thing, TLS-PSK, SRP, 
and PwdHash all have the problem that they require some sort of secure 
interface on what is generally an insecure platform.  What is needed is 
a way to modularize and isolate those authentication transactions.  Sam 
claims it can be done in software - fine.  What is the communication 
path to and from?  What's the architecture?

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Sep 2007 07:40:09 -0700

At Wed, 12 Sep 2007 16:32:34 +0200,
Eliot Lear wrote:
> interface on what is generally an insecure platform.

Yes, but this is not a protocol problem, it's a UI problem--an unsolved
one, I might add, but not an issue for the IETF.

> What is needed is 

Each of these approaches has a fairly obvious architecture. In fact,
Digest, which I forgot to mention in my previous message,
already has a pre-existing architecture, and PwdHash works with
the existing architecture.

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Wed, 12 Sep 2007 16:58:12 +0200

Erik,

You have to put the two together.  If we do, we find that we can solve 
the UI problem by taking authentication OUT of known insecure 
components.  But that requires a protocol to that authentication 
component.  If one exists, what is it?  It requires process 
interactions.  What are those?   All of this needs to be written down IN 
THIS CONTEXT.  The secure communication path must be capable of opaquely 
traveling through a host without knowledge of IP address, for instance.  
We've done stuff like this before, but not in this context.  TLS depends 
on IP address.  Oops.

And then there's registration.  Uyh.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 12 Sep 2007 17:08:05 +0200

Eric,
> the existing architecture.

You have to put the two together.  ALL of the approaches that you 
mention fail given an insecure UI.  NONE of them are likely to be 
applicable given a secure UI.  What will be necessary is a secured 
channel from the authentication module of the user to the authenticating 
party.  What is that?  It's almost assuredly not going to include IP 
addresses.  How will PSK-TLS work in such circumstances?  What is the 
communication between the module and the browser?  And add on top of ALL 
of that the UI and don't forget registration.
Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Sep 2007 08:07:23 -0700

At Wed, 12 Sep 2007 16:58:12 +0200,
> Erik,

Eric.

> traveling through a host without knowledge of IP address, for instance.  

I have no idea what you're talking about here. This problem can
be solved entirely in the client side software without any
intervension on the wire or in the server, as PwdHash demonstrates
[though of course one could argue that a superior protocol is needed.]
What you're describing sound like secure software architecture issues,
not protocol issues.

> on IP address.  

TLS does not depend on IP address.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Sep 2007 08:11:23 -0700

At Wed, 12 Sep 2007 17:08:05 +0200,
Eliot Lear wrote:
> mention fail given an insecure UI.

It depends what you mean by "secure UI". If you mean "unspoofable
password entry prompt", that's one thing. If you mean "client side
software that's not susceptible to malware, keyloggers, etc.", 
that's quite another. All the approaches I mention work just fine
with the first class of secure UI--provided we knew how to build
one that people could actually use.

> NONE of them are likely to be 
> applicable given a secure UI.

I don't agree with this assertion.

>  What will be necessary is a secured 
> party. 

What's an "authentication module"? You seem to be assuming a particular
system architecture that you haven't laid out. 

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Wed, 12 Sep 2007 17:24:04 +0200

> system architecture that you haven't laid out. 

Many others have.  I myself did so in a USENIX Login: Winter Security 
issue some years ago. SubOS would be a software example.  Potentially 
CardSpace could be made this way.  Kerberos 5 is not far from this if 
you think of the authentication module being a KDC.  Using today's 
vernacular, let this module be the identity provider and the 
authenticating service be a relying party.
And finally, having a token or some sort of SmartER Card that can handle 
large numbers of credentials would all qualify as examples.

I'm not ready to say which one is quite right, or if there is another.

Eliot

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Sep 2007 11:27:07 -0400

> course that's a UI problem, not a protocol problem.
and IMHO, any solution that doesn't let the user type his password into
some Web form is a non-starter,
both for reasons of backward compatibility and because sites (quite
legitimately) want to provide a
visually attractive interface to users which is consistent across all
platforms (for support reasons).

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Sep 2007 08:32:29 -0700

At Wed, 12 Sep 2007 11:27:07 -0400,
> platforms (for support reasons).

This may well be true. 

However, I'm not aware of any technique which both meets this constraint
and is phishing resistant.

-Ekr

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Sep 2007 11:39:53 -0400

> and is phishing resistant.
nor I.  but the first step in solving an unsolvable problem is realizing
what you're up against.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 12 Sep 2007 08:49:49 -0700

And one that W3C is currently working on.
 
I am on the W3C Web Security Context call at this very minute.

From: Eliot Lear [mailto:[email-masked]]
Sent: Wed 12/09/2007 10:20 AM
To: Eric Rescorla
Cc: [email-masked]; Eliot Lear
Subject: Re: Symptoms vs. Causes

Eric,

Eliot

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 12 Sep 2007 08:58:00 -0700

I suggest people take a look at CardSpace before continuing this thread. 
 
I don't use username/password at all and it is one heck of a lot nicer to use than any system that does. I can in addition make use of a password, smart-token or OTP token but there is no need for a username.
 
Kick this to the IRTF and start an interest/research group there if we are going to do anything. 

From: Keith Moore [mailto:[email-masked]]
Sent: Wed 12/09/2007 11:39 AM
To: Eric Rescorla
Cc: [email-masked]; Eliot Lear
Subject: Re: Symptoms vs. Causes

---

From: <[email-masked]>
Date: Thu, 13 Sep 2007 12:21:48 +0100

> > and IMHO, any solution that doesn't let the user type his password 
> > into some Web form is a non-starter, both for reasons of backward 
> > compatibility and because sites (quite
> However, I'm not aware of any technique which both meets this 
> constraint and is phishing resistant.

Bank issues a SecurID token (or SD chip with onetime pad) and requires a
six-digit PIN to be entered which cannot be reused. In order to get to
the bank in the first place, user must enter a URL that is printed on
their monthly statement. It changes every month and you may not use any
other URL.

So much for typing. How about selecting password letters from dropdown
boxes, or from an image map with scrambled letters that was sent to the
browser. 

My bank requires my surname, a customer number that is not the account
number, a 5 digit pin code typed in, and a challenge response where the
challenge is two random letter positions from my secret word, and the
response is two letter selections from two dropdown boxes.

No protocols needed.

It would be interesting if someone submitted a best practices draft for
banking services over the Internet, which documented how banks could
prevent, or avoid phishing. Such a draft could say  something like,
never send customers an email with URLs for a site which requires login.

--Michael Dillon

From: <[email-masked]>
To: <[email-masked]>
Subject: RE: Symptoms vs. Causes

> > and IMHO, any solution that doesn't let the user type his password 
> > into some Web form is a non-starter, both for reasons of backward 
> > compatibility and because sites (quite
> However, I'm not aware of any technique which both meets this 
> constraint and is phishing resistant.

Bank issues a SecurID token (or SD chip with onetime pad) and requires a
six-digit PIN to be entered which cannot be reused. In order to get to
the bank in the first place, user must enter a URL that is printed on
their monthly statement. It changes every month and you may not use any
other URL.

So much for typing. How about selecting password letters from dropdown
boxes, or from an image map with scrambled letters that was sent to the
browser. 

My bank requires my surname, a customer number that is not the account
number, a 5 digit pin code typed in, and a challenge response where the
challenge is two random letter positions from my secret word, and the
response is two letter selections from two dropdown boxes.

No protocols needed.

It would be interesting if someone submitted a best practices draft for
banking services over the Internet, which documented how banks could
prevent, or avoid phishing. Such a draft could say  something like,
never send customers an email with URLs for a site which requires login.

--Michael Dillon

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Sep 2007 07:02:57 -0700

> their monthly statement. It changes every month and you may not use any

Sorry, my fault for remembering to mention the constraint that
you also don't have to carry a token around. Obviously, if people
are prepared to carry tokens the problem is much easier. That
said, this scheme is actually not very secure because it's
susceptible to active MITM attacks on the connection to
the bank. The schemes I mentioned are substantially more
secure.

> boxes, or from an image map with scrambled letters that was sent to the

Sorry, what about these? They have essentially the same security
properties as cleartext passwords.

> response is two letter selections from two dropdown boxes.

This is complicated, but actually not particularly phishing resistant--
something that is true of a lot of the mechanisms banks are currently
adopting. First, it's vulnerable to the MITM attack mentioned above.
Second, it doesn't take that many phishing attacks to extract most
of the secret word.

-Ekr

---

From: <[email-masked]>
Date: Thu, 13 Sep 2007 16:14:47 +0100

> > boxes, or from an image map with scrambled letters that was sent to 
> > the browser.
> 
> Sorry, what about these? They have essentially the same 
> security properties as cleartext passwords.

One would hope that all communication from the browser to the server is encrypted as in SSL regardless of whether passwords go in cleartext or whether there is some Javascript to encrypt them first. In that case, the big issue is keylogging software that has been widely installed by malware distributed by Phishing organizations. Key-stroke loggers do not look at mouse-clicks.

> Second, it doesn't take that many phishing attacks to extract 
> most of the secret word.

Depends on length of said word/phrase. Also, I can see how naïve people are fooled by the first email, but surely the percentage who would click on each successive email, decreases.

At the end of the day, phishing is a social problem, not a technical problem. It can't be solved by purely technical means. All technical solutions to phishing involve some form of behavior change.

You've mentioned man-in-the-middle attacks. Such attacks cannot be prevented if the user interface requires cleartext inputs. Remember, this is not like typical cryptography MITM attacks where the MITM receives an ecrypted stream and is able to decrypt it, modify it, and reencrypt it. In this case, the user asks the MITM to provide a web page and associated Javascript. While the look of this page will be identical to the bank's page, the functionality does not need to be identical. It can send everything cleartext to the MITM who them emulates the human user.

To defeat MITM you need a secure channel, but how can you establish a secure channel to a human being who has already defeated the bank's security system by enlisting the phishing organization as their agent?

I would rather see the focus of effort go to building simple embedded computer systems that one can plug into a USB port and rely on to establish an encrypted channel to the bank. That way, the human user does not play any significant role in establishing the channel of communication and cannot subvert the process.

--Michael Dillon

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Sep 2007 08:27:03 -0700

At Thu, 13 Sep 2007 16:14:47 +0100,
<[email-masked]> wrote:
> One would hope that all communication from the browser to the server
> is encrypted as in SSL regardless of whether passwords go in
> cleartext or whether there is some Javascript to encrypt them
> first. In that case, the big issue is keylogging software that has
> been widely installed by malware distributed by Phishing
> organizations. Key-stroke loggers do not look at mouse-clicks.

(1) No, this technique is still easily phished by someone who
    impersonates the image map.
(2) It's easy to write keyloggers that would capture mouse clicks.
    Nobody does it because the imagemap technique is not widely
    used. If it were, that would change.

> Depends on length of said word/phrase. Also, I can see how naïve
> people are fooled by the first email, but surely the percentage who
> would click on each successive email, decreases.

That's far from clear, but even if it were so, the phisher can force
multiple trials on the same phishing email, as if you had mistyped,
thus recovering significant portions of the secret word. And of 
course, this either requires multiple secret words or a strong
password equivalent on the server side.

> You've mentioned man-in-the-middle attacks. Such attacks cannot be
> prevented if the user interface requires cleartext inputs.

I suppose it depends on what you mean by "cleartext inputs". See:

  [0] J. Alex Halderman, Brent Waters, and Edward W. Felten, "A Convenient
  Method for Securely Managing Passwords", In Proceedings of the 14th
  International World Wide Web Conference (WWW 2005)
  
  [1] Blake Ross, Collin Jackson, Nicholas Miyake, Dan Boneh and John C. Mitchell
  Stronger Password Authentication Using Browser Extensions.
  Proceedings of the 14th Usenix Security Symposium, 2005.

-Ekr

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 13 Sep 2007 09:59:01 -0700

You are both wrong.
 
Mouseclick loggers are commonplace. They have been around for at least four years, about six months after banks in Brazil started to use mouse based keyboards. Some of them capture the screen area round the mouse pointer at the time of the click.

From: Eric Rescorla [mailto:[email-masked]]
Sent: Thu 13/09/2007 11:27 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Symptoms vs. Causes

 

-Ekr