W3C home > Mailing lists > Public > ietf-tls@w3.org > July to September 1996

Re: Repost of CompuServe Position on Passphrases

From: Tom Weinstein <tomw@netscape.com>
Date: Mon, 22 Jul 1996 23:25:00 -0700
Message-ID: <31F4703C.2F1C@netscape.com>
To: John Macko <jmacko@nisa.compuserve.com>
CC: "'ietf-tls@w3.org'" <ietf-tls@w3.org>
Personally, I'm opposed to password (or passphrase) authentication for
a number of reasons.  In my response, I've mostly restricted my comments
to technical issues.  Basically, I think passwords work fine if you
only have one, but after that they become a problem.

John Macko wrote:
> 
> PASS PHRASES ARE INSECURE--One sometimes hears the argument that pass
> phrases are inherently insecure. Generally, there are three such
> arguments, all false.
> 
> First, the argument goes, pass phrases are insecure because someone
> who intercepts network traffic between the user and service learns the
> pass phrase. Such an argument is predicated on the concept of
> transmitting pass phrases in the clear. Anyone who transmits pass
> phrases in the clear should be shot. This is not an argument against
> pass phrases, but an argument against a particular implementation of
> pass phrases.

[ ... ]

> There are simple, secure challenge-response mechanisms that prevent an
> eavesdropper from learning the pass phrase. These mechanisms are, in
> fact, identical in concept to mechanisms used with public keys--we
> generate challenges, you sign it, and I check the result--although
> they're quite a bit faster than the public key algorithms.

Unfortunately, they all rely on the fact that the challenger knows the
password.

> Next, the argument goes, pass phrases are insecure because an
> eavesdropper can discover your pass phrase by using a dictionary
> attack. The old, Unix-style, across-the-board dictionary attack is not
> applicable, but one could attack an individual challenge-response
> pair.
>
> That is certainly a valid concern. But we call them pass phrases for a
> reason: most implementations encourage, or even require, the use of a
> very short "password," and that's wrong. You can avoid a dictionary
> attack simply by using a pass phrase that won't be discovered by a
> dictionary attack. Furthermore, the underlying mechanism is based on a
> binary string of bits. If you don't mind giving up the ability to type
> your pass phrase, your pass phrase can be a random binary number,
> which is not at all subject to dictionary attack.

That works fine if there's only one passphrase to remember.  If you have
to remember many, you'll either end up writing them down (bad), or using
the same passphrase for each service (really bad).  If you rely on your
computer to remember the random binary strings of bits, then you lose
the biggest advantage of passwords, the ability to carry them around in
your head.

> Finally, the argument goes, pass phrases are insecure because the
> service must know your pass phrase to verify that you used the right
> one. But the service needn't know your pass phrase; many schemes, such
> as Kerberos, KryptoKnight, RPA, and even the typical, if not terribly
> general purpose, RADIUS scheme used by PPP servers to support CHAP,
> accomplish pass-phrase authentication without requiring the service to
> know, nor allowing the service to learn, the pass phrase.

This is semantics.  You claim that these systems don't require the
service to know your passphrase, but that's only true if you don't
consider the authentication authority to be part of the service.  In
Kerberos this is the ticket-granting server.  In RADIUS, this is
password daemon.  I'm not familiar with KryptoKnight and RPA, but I'm
sure they are the same.

> CUSTOMER SERVICE--If a user loses his credentials, either in the sense
> of their being compromised or they're no longer existing, it should be
> easy to fix. With pass phrases, a customer service representative may
> easily change the user's pass phrase and tell the user the new one,
> during the customer's telephone call. The customer may immediately use
> that pass phrase to authenticate himself. (Obviously, he may
> immediately change it afterward.) With public key authentication, the
> problem can't be solved in one telephone call. Similar issues arise
> for a newly signed up user.

I don't see how this is any different for certificates.  The user loses
his private key (for whatever reason).  He calls customer service, they
invalidate his current certificate.  He then logs in and generates a
new certificate, going through the Equifax (or whatever) authentication
process he went through initially to generate an account.  Customer
service can even generate a one-time PIN that he can use for this
purpose.

> PASSPHRASES AS A SEPARATE LAYER--There are two good reasons for
> including passphrase-based authentication directly into the protocol,
> rather than layering it on top, as must be done with currently
> available protocols.
>
> One reason has to do with the messy details of export controls:
> if incorporated into the protocol, an authentication response can
> be protected by a stronger key than is permitted for exportable
> encryption of generic bulk data.  The other reason has to do with
> interoperability; if a single, well-designed passphrase-based
> authentication protocol can be selected as the standard for use in
> conjunction with TLS, then those who choose to use it (and only those
> who do) need not worry about designing and implementing such a
> protocol from scratch, and ensuring that all clients and servers are
> supplied with the same implementation.

I don't think we should be burdening an international standard with
idiosyncrasies imposed by brain-damaged US regulations that will
hopefully be repealed in the near future.

-- 
You should only break rules of style if you can    | Tom Weinstein
coherently explain what you gain by so doing.      | tomw@netscape.com
Received on Tuesday, 23 July 1996 02:25:14 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:34:50 EDT