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.
_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth

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> Ietf-http-authosafoundation.org
SH> http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth



_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth

At Wed, 24 Oct 2007 10:36:41 +1000,
christopherpobox.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
_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth

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> christopherpobox.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?

ER> -Ekr



_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth

At Wed, 24 Oct 2007 14:50:13 +1000,
christopherpobox.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


_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth

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> christopherpobox.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.

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




_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth

At Wed, 24 Oct 2007 15:48:01 +1000,
christopherpobox.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
you have in mind?

-Ekr
_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth

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> christopherpobox.com 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



_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth

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



_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth

>>>>> "christopher" == christopher 
<christopherpobox.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
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
_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth