headers
Sam Hartman | 23 Oct 2007 21:43
Picon
Favicon

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.
Permalink | Reply | 10 comments |
headers
christopher | 24 Oct 2007 02:36
Picon
Favicon

Re: Pondering some issues on the phishing draft

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
(Continue reading)

Permalink | Reply | 9 comments |
headers
Eric Rescorla | 24 Oct 2007 06:10

Re: Pondering some issues on the phishing draft

At Wed, 24 Oct 2007 10:36:41 +1000,
christopher <at> pobox.com 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
Permalink | Reply | 6 comments |
headers
christopher | 24 Oct 2007 06:50
Picon
Favicon

Re[2]: Pondering some issues on the phishing draft

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> christopher <at> pobox.com 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?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Eric Rescorla | 24 Oct 2007 07:05

Re: Re[2]: Pondering some issues on the phishing draft

At Wed, 24 Oct 2007 14:50:13 +1000,
christopher <at> pobox.com 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
Permalink | Reply | 4 comments |
headers
christopher | 24 Oct 2007 07:48
Picon
Favicon

Re[4]: Pondering some issues on the phishing draft

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> christopher <at> pobox.com 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.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Eric Rescorla | 24 Oct 2007 14:03

Re: Re[4]: Pondering some issues on the phishing draft

At Wed, 24 Oct 2007 15:48:01 +1000,
christopher <at> pobox.com 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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Chris Drake | 24 Oct 2007 15:02
Picon
Favicon

Re[6]: Pondering some issues on the phishing draft

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> christopher <at> pobox.com wrote:
>> 
>> Hi Eric,
>> 
>> Cookies work, yes

ER> No, cookies don't work.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Rescorla | 24 Oct 2007 15:39

Re: Re[6]: Pondering some issues on the phishing draft

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,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sam Hartman | 24 Oct 2007 16:55
Picon
Favicon

Re: Pondering some issues on the phishing draft

>>>>> "christopher" == christopher  <christopher <at> pobox.com> 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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane