Subject: Re: [Ietf-http-auth] Pondering some issues on the phishing draft
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Cc: [email-masked], Sam Hartman <[email-masked]>
Date: Wed, 24 Oct 2007 10:07:47 -0500
List-Id: ietf-http-auth.osafoundation.org

On Wed, Oct 24, 2007 at 10:36:41AM +1000, [email-masked] wrote:
> I'd recommend something different; outside the box.  If you're worried
> about people using UI clues, and you need mutual auth, and you need
> per-site security (like pwdhash), it might be best to build all these
> in together in a way that users cannot ignore.  eg: If PayPal assigned
> me a yellow tennis shoe jpeg, and I've got to click that to log in,
> that's an elegant small part of the solution that solves all these
> problems (and, doesn't need everyone to have admin rights to install
> crypto extensions on every PC they use)

Phishers want your money.  Your passwords are gravy.  As long as
phishers can mount an MITM attack your scheme fails.  Phishing is
essentially a MITM attack or built on MITM attacks.

You need mutual authentication and end-to-end integrity and (if you want
it) confidentiality protection, where the ends are the user agent and
the relying party.

Some folks are talking about pushing authentication down the stack
(e.g., into TLS) to achieve this.  Others are talking about pushing
integrity and confidentiality protection up the stack (e.g., using
S/MIME and to hell with TLS).  Still others are talking about channel
binding (leaving authentication above TLS and integ/conf protection at
the TLS layer and binding the two to prevent MITMs).  Any of these
solutions could do.  But there will be a big UI component -- that little
lock icon doesn't cut it.

Nico
-- 

From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-http-auth] Pondering some issues on the phishing draft
Date: Wed, 24 Oct 2007 10:55:00 -0400
Cc: [email-masked]

>>>>> "christopher" == christopher  <[email-masked]> writes:

    christopher> Hi Sam, I'd recommend something different; outside
    christopher> the box.  If you're worried about people using UI
    christopher> clues, and you need mutual auth, and you need
    christopher> per-site security (like pwdhash), it might be best to
    christopher> build all these in together in a way that users
    christopher> cannot ignore.  eg: If PayPal assigned me a yellow
    christopher> tennis shoe jpeg, and I've got to click that to log
    christopher> in, that's an elegant small part of the solution that
    christopher> solves all these problems (and, doesn't need everyone
    christopher> to have admin rights to install crypto extensions on
    christopher> every PC they use)

Personally I'm more interested in decreasing the extent to which the
document over-sells specific UI solutions rather than thinking more
outside the box.  I'd appreciate others comments.

In particular, I think we can say that strong authentication allows us
to provide confidential information to the authenticated user without
unacceptable risk that it is being disclosed to the wrong party.  So,
for example, if you use strong authentication and are using something
like sitekey to get mutual authentication, then you would not need to
rely on cookies for the image if you sent the sitekey after login.

The current document says that this confidential information will
help.  That's not clear because it's not clear that users will take
advantage of the clues.

Now, I think it would be appropriate to mention that interacting with
confidential components is something to explore.  I.E. if it turns out
that rather than ignoring the problem, people will tend to call their
bank and complain when they cannot find the right shoe to click after
they login, then your shoes could abe a part of the answer.
Personally I think this is rather unlikely to work.  However it is
different than sitekey in that you have to make some decision--you
have to click something.  With sitekey, you can more easily ignore the
image.  Of course I think the usability concerns of having an extra
step in the login process might bother a lot of people.  I don't think
it would be appropriate to recommend this or really any of the
specific UI items as anything other than something to explore.

--Sam

Date: Wed, 24 Oct 2007 06:39:13 -0700
From: Eric Rescorla <[email-masked]>
To: Chris Drake <[email-masked]>
Subject: Re: Re[6]: [Ietf-http-auth] Pondering some issues on the phishing draft
Cc: [email-masked], Sam Hartman <[email-masked]>

At Wed, 24 Oct 2007 23:02:52 +1000,
Chris Drake wrote:
> The "game" was a test to see if you're interested in solving the
> problem, or have a hidden agenda (networkresonance.com I'd guess?).

I have no idea what you're insinuating. It's not any secret what
I do for a living, and it's not really related to this kind of
sign-on or authentication problem at all.

> Yes - there's an elegant solution.  The Unix/DOS MD5's of it are
> below.  If you add constructive contributions (aka - play the game),
> I'll send an answer.

Sorry, that's not the way things work at IETF. If you have
something to contribute, publish it in the open literature. If
not, you're just wasting everyone's time.

> Cookies do work.  Everyone knows it; you - of all people - with CDT -
> you know that. 

Actually, I don't know it. At least one site I deal with regularly
seems to lose my cookie and forces me to do challenge questions.  As I
noted previously, that's a phishing target. Moreover, the available
evidence [SDOF07] suggests that people don't in fact check
for the presence of secret images, so even if one ignores the cookie
loss issue, it's not clear that this technique works.

> Adequate recovery is the same as any enrollment
> problem,

No, again, it's not. Because it happens frequently, it has to be
lightweight and automated (challenge questions being the typical
thing). 

-Ekr

Date: Wed, 24 Oct 2007 23:02:52 +1000
From: Chris Drake <[email-masked]>
To: Eric Rescorla <[email-masked]>
Subject: Re[6]: [Ietf-http-auth] Pondering some issues on the phishing draft
Cc: [email-masked], Sam Hartman <[email-masked]>

Hi Eric,

The "game" was a test to see if you're interested in solving the
problem, or have a hidden agenda (networkresonance.com I'd guess?).
Yes - there's an elegant solution.  The Unix/DOS MD5's of it are
below.  If you add constructive contributions (aka - play the game),
I'll send an answer.

Meanwhile, others are invited to ask off-list for the solution, if they
like.

Cookies do work.  Everyone knows it; you - of all people - with CDT -
you know that.  Adequate recovery is the same as any enrollment
problem, not that it's relevant 99.9% of the time (I already said
cookies aren't the answer btw.). 

Kind Regards,
Chris Drake

Wednesday, October 24, 2007, 10:03:06 PM, you wrote:

ER> At Wed, 24 Oct 2007 15:48:01 +1000,
ER> [email-masked] wrote:
>> 
>> Hi Eric,
>> 
>> Cookies work, yes

ER> No, cookies don't work.

ER> The problem, as I said, is that any mechanism which relies on cookies
ER> needs a recovery mechanism in case the cookie gets lost. That recovery
ER> mechanism generally entails a bunch of challenge questions. But
ER> now those challenge questions themselves become a phishing target.

>> - so you answered your own question for 99.9% of use
>> cases (the remaining 0.1% being folks who regularly use machines they
>> can't store their cookies on).  You also highlighted the drawbacks of
>> pwdhash - how does a user do anything on the theoretical "new device",
>> especially one like a phone or work PC that has no plugin or admin
>> rights?

>> Anyhow - while cookies work - that's still boringly "inside the box"
>> and assuming far too much.  Here's the MD5s of my next reply to you:
>> 1134102756cd5c895709aeb9d821b4da 82b4f03e38fc086ade8d35a4a743c7b9
>> 
>> Have a go at lateral-thinking, jump outside the box, and let me know
>> what better ideas you can come up with besides cookies.  Hint:
>> challenge *all* your assumptions :-)

ER> How about instead we skip the game playing and you describe what
ER> you have in mind?

ER> -Ekr

Date: Wed, 24 Oct 2007 05:03:06 -0700
From: Eric Rescorla <[email-masked]>
To: [email-masked]
Subject: Re: Re[4]: [Ietf-http-auth] Pondering some issues on the phishing draft
Cc: [email-masked], Sam Hartman <[email-masked]>

At Wed, 24 Oct 2007 15:48:01 +1000,
[email-masked] wrote:
> 
> Hi Eric,
> 
> Cookies work, yes

No, cookies don't work.

The problem, as I said, is that any mechanism which relies on cookies
needs a recovery mechanism in case the cookie gets lost. That recovery
mechanism generally entails a bunch of challenge questions. But
now those challenge questions themselves become a phishing target. 

> - so you answered your own question for 99.9% of use
> cases (the remaining 0.1% being folks who regularly use machines they
> can't store their cookies on).  You also highlighted the drawbacks of
> pwdhash - how does a user do anything on the theoretical "new device",
> especially one like a phone or work PC that has no plugin or admin
> rights?

> Anyhow - while cookies work - that's still boringly "inside the box"
> and assuming far too much.  Here's the MD5s of my next reply to you:
> 1134102756cd5c895709aeb9d821b4da 82b4f03e38fc086ade8d35a4a743c7b9
> 
> Have a go at lateral-thinking, jump outside the box, and let me know
> what better ideas you can come up with besides cookies.  Hint:
> challenge *all* your assumptions :-)

How about instead we skip the game playing and you describe what
you have in mind?

-Ekr

Date: Wed, 24 Oct 2007 15:48:01 +1000
From: [email-masked]
To: Eric Rescorla <[email-masked]>
Subject: Re[4]: [Ietf-http-auth] Pondering some issues on the phishing draft
Cc: [email-masked], Sam Hartman <[email-masked]>

Hi Eric,

Cookies work, yes - so you answered your own question for 99.9% of use
cases (the remaining 0.1% being folks who regularly use machines they
can't store their cookies on).  You also highlighted the drawbacks of
pwdhash - how does a user do anything on the theoretical "new device",
especially one like a phone or work PC that has no plugin or admin
rights?

Anyhow - while cookies work - that's still boringly "inside the box"
and assuming far too much.  Here's the MD5s of my next reply to you:
1134102756cd5c895709aeb9d821b4da 82b4f03e38fc086ade8d35a4a743c7b9

Have a go at lateral-thinking, jump outside the box, and let me know
what better ideas you can come up with besides cookies.  Hint:
challenge *all* your assumptions :-)

Chris

Wednesday, October 24, 2007, 3:05:43 PM, you wrote:

ER> At Wed, 24 Oct 2007 14:50:13 +1000,
ER> [email-masked] wrote:
>> 
>> Hi Eric,
>> 
>> The shoe's the mutual auth - if it's wrong or missing, you're being
>> phished. When present, you've subtly compelled users to use the
>> "clue", which was Sam's other big worry.

ER> And what stops the attacker from entering your userid and seeing the
ER> same picture? In the past, when I've seen systems like this, the
ER> client stores some cookie which tells the server which picture to
ER> show. But when the user uses a new device, or the client forgets the
ER> cookie, they get prompted with some extended authentication
ER> dialog---which is a good candidate for phishing. And since due to
ER> various glitches this happens somewhat frequently...

ER> -Ekr

Date: Tue, 23 Oct 2007 22:05:43 -0700
From: Eric Rescorla <[email-masked]>
To: [email-masked]
Subject: Re: Re[2]: [Ietf-http-auth] Pondering some issues on the phishing draft
Cc: [email-masked], Sam Hartman <[email-masked]>

At Wed, 24 Oct 2007 14:50:13 +1000,
[email-masked] wrote:
> 
> Hi Eric,
> 
> The shoe's the mutual auth - if it's wrong or missing, you're being
> phished. When present, you've subtly compelled users to use the
> "clue", which was Sam's other big worry.

And what stops the attacker from entering your userid and seeing the
same picture? In the past, when I've seen systems like this, the
client stores some cookie which tells the server which picture to
show. But when the user uses a new device, or the client forgets the
cookie, they get prompted with some extended authentication
dialog---which is a good candidate for phishing. And since due to
various glitches this happens somewhat frequently...

-Ekr

Date: Wed, 24 Oct 2007 14:50:13 +1000
From: [email-masked]
To: Eric Rescorla <[email-masked]>
Subject: Re[2]: [Ietf-http-auth] Pondering some issues on the phishing draft
Cc: [email-masked], Sam Hartman <[email-masked]>

Hi Eric,

The shoe's the mutual auth - if it's wrong or missing, you're being
phished. When present, you've subtly compelled users to use the
"clue", which was Sam's other big worry.

This is just the phishing resistant and mutual authentication parts:
an implementation has more stuff before (eg: enrollment, SSL), after
(eg: DoS avoidance, failure reporting,...), and "in the middle" (eg:
optional tokens, biometrics, audio alternatives for the blind,...) 

Chris

Wednesday, October 24, 2007, 2:10:32 PM, you wrote:

ER> At Wed, 24 Oct 2007 10:36:41 +1000,
ER> [email-masked] wrote:
>> I'd recommend something different; outside the box.  If you're worried
>> about people using UI clues, and you need mutual auth, and you need
>> per-site security (like pwdhash), it might be best to build all these
>> in together in a way that users cannot ignore.  eg: If PayPal assigned
>> me a yellow tennis shoe jpeg, and I've got to click that to log in,
>> that's an elegant small part of the solution that solves all these
>> problems (and, doesn't need everyone to have admin rights to install
>> crypto extensions on every PC they use)

ER> Hmm... 

ER> Could you explain in more detail how this works and why it's
ER> phishing resistant?

ER> -Ekr

Date: Tue, 23 Oct 2007 21:10:32 -0700
From: Eric Rescorla <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-http-auth] Pondering some issues on the phishing draft
Cc: [email-masked], Sam Hartman <[email-masked]>

At Wed, 24 Oct 2007 10:36:41 +1000,
[email-masked] wrote:
> I'd recommend something different; outside the box.  If you're worried
> about people using UI clues, and you need mutual auth, and you need
> per-site security (like pwdhash), it might be best to build all these
> in together in a way that users cannot ignore.  eg: If PayPal assigned
> me a yellow tennis shoe jpeg, and I've got to click that to log in,
> that's an elegant small part of the solution that solves all these
> problems (and, doesn't need everyone to have admin rights to install
> crypto extensions on every PC they use)

Hmm... 

Could you explain in more detail how this works and why it's
phishing resistant?

-Ekr

Date: Wed, 24 Oct 2007 10:36:41 +1000
From: [email-masked]
To: Sam Hartman <[email-masked]>
Subject: Re: [Ietf-http-auth] Pondering some issues on the phishing draft
Cc: [email-masked]

Hi Sam,

I'd recommend something different; outside the box.  If you're worried
about people using UI clues, and you need mutual auth, and you need
per-site security (like pwdhash), it might be best to build all these
in together in a way that users cannot ignore.  eg: If PayPal assigned
me a yellow tennis shoe jpeg, and I've got to click that to log in,
that's an elegant small part of the solution that solves all these
problems (and, doesn't need everyone to have admin rights to install
crypto extensions on every PC they use)

Chris

Wednesday, October 24, 2007, 5:43:30 AM, you wrote:

SH> Hi, folks.
SH> I wanted to let you know where I am  and to solicit some comments.

SH> I've been pondering two big issues that came up in ekr's review.

SH> The first is pwdhash.  Eric correctly points out that the requirements
SH> for mutual authentication rule out pwdhash.  I don't justify this;
SH> Eric says that's a problem and he's right.

SH> It's a bit complicated.  I'm quite sure that pwdhash is an improvement
SH> over what we have today.  However I'm also quite sure that it is
SH> worthwhile to actually go as far as mutual authentication.  So, I
SH> don't want to discourage people from deploying something like pwdhash
SH> instead of keeping with the status quo.  But I also think it is
SH> valuable to actually get as far as mutual authentication.  I think we
SH> should recommend developing authentication systems that meet that
SH> goal.  However I don't have a coherent justification to propose for
SH> your review.  I need to come up with that.  I've been working on that.
SH> I also need to work on text to make it clear that schemes
SH> like pwdhash are an improvement.

SH> The second issue is response to whether people will actually take
SH> advantage of UI clues.  I'm also pondering what to say here.
SH> _______________________________________________
SH> Ietf-http-auth mailing list
SH> [email-masked]
SH> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth

From: Sam Hartman <[email-masked]>
To: [email-masked]
Date: Tue, 23 Oct 2007 15:43:30 -0400
Subject: [Ietf-http-auth] Pondering some issues on the phishing draft

Hi, folks.
I wanted to let you know where I am  and to solicit some comments.

I've been pondering two big issues that came up in ekr's review.

The first is pwdhash.  Eric correctly points out that the requirements
for mutual authentication rule out pwdhash.  I don't justify this;
Eric says that's a problem and he's right.

It's a bit complicated.  I'm quite sure that pwdhash is an improvement
over what we have today.  However I'm also quite sure that it is
worthwhile to actually go as far as mutual authentication.  So, I
don't want to discourage people from deploying something like pwdhash
instead of keeping with the status quo.  But I also think it is
valuable to actually get as far as mutual authentication.  I think we
should recommend developing authentication systems that meet that
goal.  However I don't have a coherent justification to propose for
your review.  I need to come up with that.  I've been working on that.
I also need to work on text to make it clear that schemes like pwdhash are an improvement.

The second issue is response to whether people will actually take
advantage of UI clues.  I'm also pondering what to say here.