Re: [Ietf-http-auth] New draft on anti-phishing requirements

[Eric Rescorla <[e-mail]>]

1. This is not principally a protocol problem but rather a UI problem.
   The protocol problems are generally well understood. If the UI
   problems are solved, nearly any protocol will work. In particular,
   there have been a number of published designs [1] [2] that have mostly
   adequate (though not perfect) protocols, though without complete
   solutions to the UI problem. Indeed, a slightly different design
   for Digest (in which the absolute URI was hashed) combined with
   a secure UI would pretty much defeat current phishing attacks.

2. It's really important to distinguish between different levels of
   attack.  Conventional phishing attacks rely on generating a reference
   which appears to be valid but actually points at the attacker's
   site. (This is why SSL/TLS doesn't help much).

   But this is different from attacks in which the attacker actually
   intercepts the user's communication. In these settings, some sort
   of cryptographic protection for the channel (a la HTTPS) or the
   messages (a la S-HTTP) must be provided.

   On a similar note, in current phishing attacks the attacker 
   attempts to directly extract the user's password. If C-R mechanisms
   are used, a dictionary attack is natural. I assume that's why
   you wave in the direction of ZKPPs in S 4.3. However, it's 
   worth asking whether we would be satisified with a system that
   was only partly strengthened against dictionary attacks (see [2]
   again).

3. The term "password equivalent" is a bit confusing. See draft-iab-auth-mech
   for some discussion of strong versus weak password equivalent.

4. I agree that server authentication is a good, but I'm not totally
   sold that it's a necessity. It's principally important when you're
   changing credentials, but even then with a properly designed scheme
   where the server has a weakly password equivalent credential, the
   exposure is fairly limited. A standard practice is to hash the
   hostname into the password hash stored on the server.


5. You write:

   The risk of dictionary attack is always a significant concern for
   password systems.  Users can (but typically do not) minimize this
   risk by choosing long, hard to guess phrases for passwords.  The risk
   can be removed once a password is already established by using a
   zero-knowledge password protocol.

This is not strictly true. A ZKPP removes the risk of offline dictionary
attack, but not online attack. These attacks do still get mounted [3]

   However the risk of dictionary
   attack is always present when setting up a new password  or changing
   a password.  Minimizing the number of services that use the same
   password and being extra careful to make sure the right server is
   used when establishing a password can minimize this risk.

It's not clear to me that this helps, unless you're assuming a ZKPP.
If the attacker can capture a hashed password or C-R handshake (which
a phisher can generally force in non-ZKPP cases) then they can mount an
offline dictionary attack anyway. Consider a typical design where the user has
a master password P and then generates per-site passwords as
H(Site-Name || P). In the C-R handshake, the user provides:

H(challenge || H(Site-Name || P).

Dictionary attacking this isn't significantly harder than dictionary attacking
H(Site-Name || P).


6. You write:

   In situations where there is an identity provider that is separate
   from the website as a relying party, additional requirements are
   needed.  The identity provider MUST verify that the website  is a
   valid relying party for this identity.  Some identity providers will
   allow anyone to accept their identity.  However particularly for
   financial institutions and large service providers it will be common
   that only authorized business partners will be able to accept the
   identity.  The confirmation that the the relying party is such a
   business partner  will often be a significant part of the value
   provided by the identity provider, so it is important that the
   protocol enable this.  The relying party MUST prove its identity is
   the one expected by the identity provider.

I agree that this is is a likely business goal for identity providers,
but it's not required for protection against phishing. Really, there
are two interests here:

1. To prove to the user (the guy with the browser) that he is doing
   business with an "authorized" provider.
2. To allow the identity provider to extract rents from the relying
   parties.

Neither strictly requires the relying party authenticating to the
identity provider during the transaction. The first can obviously
done by issueing the relying party a long-term credential. The
second can be done by encrypting the credential under the relying
party's key. You don't necessarily need the identity provider to
receive a proof that the relying party was able to decrypt it.

-Ekr



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

[2] Halderman, J. A., Waters, B., and Felten, E. W. 2005. A convenient
method for securely managing passwords. In Proceedings of the 14th
international Conference on World Wide Web (Chiba, Japan, May 10 - 14,
2005). WWW '05. ACM Press, New York, NY, 471-479. DOI=
http://doi.acm.org/10.1145/1060745.1060815
      
[3] http://www.whitedust.net/article/27/Recent%20SSH%20Brute-Force%20Attacks/