Subject: Re: Two more thoughts about credentials download protocols

From: Stephen Farrell <[email-masked]>
Date: Wed, 03 Jan 2001 13:09:09 +0000

Hi Radia,

> The second thought is about the issue someone brought up about how if
> you get out of sync with typing name and password, you could wind up
> sending your password over the wire in the clear. Charlie suggested
> a low-tech fix to that, which is that the password be required to
> contain a character which is illegal in a name. For instance, if
> "=" isn't legal in a name, and the user's
> password is "mypassword", the user could be required to type ==mypassword.
> And this might make a good user interface for putting in a hint. If
> the hint is, say, "J", then the user could either type
> =J=mypassword (which includes the hint), or ==mypassword (no hint)

First, I do kind of like the idea, however, I'm not sure that 
its easy to enforce, given I18N. Also if == is always prepended
then s/w will likely be developed that automatically enters 
that, which defeats the purpose. Finally its not that user friendly
to reqiure additional crud to be typed (even if its just a few 
characters).

I'd be interested in what others think about the requirement and
especially other ideas for (possibly partly) solving the problem.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Darren Moffat <[email-masked]>
Date: Wed, 03 Jan 2001 09:22:57 -0800

> especially other ideas for (possibly partly) solving the problem.

My thoughts on this are that this is a user interface design problem and really
isn't
anything to do with the protocol.  If an application on the client side sends
the users
password across in the "username" part of the protcol then it is because the UI
of
that client was unable to present information in a sufficiently clear maner to
the user
to get the correct data.

Thats not to say it isn't an interesting problem, I just don't think it is one
that can
be solved at a protocol layer.

--
Darren J Moffat

---

From: Mike DeGraw-Bertsch <[email-masked]>
Date: Wed, 3 Jan 2001 13:01:31 -0500 (EST)

Perhaps I misunderstand the problem, but...  While I agree that this is
mostly a user interface issue, not a protocol issue, shouldn't the
username transmission be encrypted anyway?  It's my understanding that the
protocol should be authentication-type agnostic, and therefor whatever is
being sent should be encrypted as a whole, irrespective of if it's a
username, password, private key, or whatever.

  -Mike Bertsch