RE: Repost of CompuServe Position on Passphrases

Tom Weinstein wrote:

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

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

The distinction between whether the application server or the
authentication authority knows the passphrase is much more than
semantics.  Multiple online services are interested in allowing their
members to visit external *hot* websites based on the online service
membership.  First, if the application server gains knowledge of the
password it becomes trivial for a rogue server to impersonate the user,
and incur charges against the user's online membership.  Second, if the
external website becomes affiliated with multiple online services, it
cannot be allowed access to credentials in a way that could be usefully
divulged between competing services. 

Don Schmidt		donsch@microsoft.com

>----------
>From: 	Tom Weinstein[SMTP:tomw@netscape.com]
>Sent: 	Monday, July 22, 1996 11:25 PM
>To: 	John Macko
>Cc: 	'ietf-tls@w3.org'
>Subject: 	Re: Repost of CompuServe Position on Passphrases
>
>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 15:56:56 UTC