Re: Review of draft-hartman-webauth-phishing-05

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Sam.

> I'm confused by your comments on 3.1.  I agree with you that an
> attacker could take for example a login password in today's systems
> and use that to to gain the information necessary to spoof other UI.
>
> The primary goal of this document is to propose requirements that make
> it difficult for the attacker to capture such a password.

Alright, I see that the intent of section 3.1 is actually to describe
capabilities that an attacker will *always* have, i.e., even in case it
does not know (and cannot acquire) a username/password from a victim
user.  Maybe you can clarify this by changing the latter part of paragraph
2 of section 3.1 like this:

   OLD

                                                     However the
   attacker probably could not replicate the account summary page until
   the attacker learned the user name and password because the attacker
   would not know what accounts to list or approximate balances that
   will look convincing to a user.  Of course attackers may know some
   personal information about a user.  Websites that want to rely on
   attackers not knowing certain information need to maintain the
   privacy of that information.

   NEW

                                                     However the
   attacker probably could not replicate the account summary page
   until the attacker learned the user name and password because the
   attacker would not know what accounts to list or approximate
   balances that will look convincing to a user.  Preventing the
   attacker from acquiring a victim's user name and password would thus
   make it impossible for an attacker to spoof a user interface that
   shows such individual data.

What I did is replacing the last two existing sentences with a new
one.  Would you agree?

> Also in 3.1 you talk about on-path attacks.  I guess this needs better
> wording because basically everyone who has read the document has
> commented on that phrase.  So, examples of an on-path attack include
> mounting a MITM against TLS and hoping the user will click "accept
> this certificate" for the bogus cert you provide; DNS attacks; etc.
> I'm trying to say that attackers have these capabilities and that we
> need to evaluate both current and future systems against such attacks.
> How can I help clarify what I'm trying to say?

Here is some text that you could take to replace the currently last
sentence in paragraph 1 of section 3.1.  If you wish, feel free to
copy and paste:

   Mechanisms attackers use to accomplish this include links with a
   misleading name or URI, which they may distribute in emails;
   attacks against DNS; and man-in-the-middle attacks against a TLS
   handshake.  The former two attacks allow the attacker to pass
   authentication because the victim user can be tricked into
   accepting the attacker's certificate.  The latter attack will
   typically create a warning on the victim user's side, but many
   users cannot make informed decisions on how to respond to such a
   warning, making them inclined to accept the bogus certificate.

Hope this helps,
- Christian



_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]