RE: Re: Password change via HTTP

Unfortunately, there are problems with certificate security.
Shamir recently demonstrated how easy it is find the private key
in a PC because of different entropy of the objects.

Also, how can I be sure that the "client" serving up the 
certificate is the endpoint? A toolkit like WIDL would appear to
provide a screen scraping capability for http which effectively
creates a potential proxy, of which I, at the server end have
no knowledge. Even if I have a cryptographically secure tunnel,
and have a certificate, how do I know that someone hasn't added
their own plumbing to the client?

There are times when it pays to use both belt and suspenders ...
and even that may not be enough.

Steve

> -----Original Message-----
> From: Alex Kodat [mailto:ALEX@SIRIUS.sirius-software.com]
> Sent: Sunday, June 13, 1999 6:10 PM
> To: hallam@ai.mit.edu
> Cc: http-wg@hplb.hpl.hp.com
> Subject: Re: Re: Password change via HTTP
> 
> 
> In-Reply-To:  Message of Sun, 13 Jun 1999 19:21:13 -0400 from 
> <hallam@ai.mit.>
> 
> Promise I'll take this thread off-line after this note unless anyone
> else is at all interested.
> 
> > Smartcards are not a requirement for PKI. I have installed many PKIs
> > and very few use smartcards.
> 
> Yes, but in many situations involving "public"/shared PC's 
> there doesn't
> seem to be much of an alternative. Walking around with 
> diskettes containing
> client certificates won't fly at a lot of places even if they 
> are password
> protected. Not only are the diskettes easily copied, but they'll often
> sit on networked PC's that have virtually no real security built into
> them (or at the very least configured). Now the protection of 
> the client
> certs depends on passwords that are probably easily guessed 
> in many instances.
> 
> > Actually management of password systems in a large enterprise is far
> > from easy.
> >
> > Management of passwords in a small system is no simpler than
> > locally issued certificates.
> 
> Yes, but in either case it's already considered a "solved" problem
> or at least one that's relatively under control. Password systems
> are the devil one already knows and the devil one is stuck with anyway
> while supporting legacy systems. While I'm sure a lot of forward
> looking companies are using PKI there are a lot more that aren't.
> I notice the W3C members only archives are password protected (and
> not even over SSL it seems ?).
> 
> > Either way, I don't think that the HTTP working group should spend
> > any more time trying to make passwords work when applications such
> > as SSH have demonstrated that public key based systems are more
> > feasible and easier to manage.
> 
> Mine is not to say what the working group should be working on
> and once again profound apologies if I've wasted anyone's time on
> this. I just wanted to point out that since HTTP *does* support
> password authentication there *seemed* to be a bit of a hole in
> its support of password change/expiration. I was hoping (and am
> still hoping) someone would point out how that hole is not there.
> I also still believe that people will be using centrally stored
> passwords at least 10 years from now (Y2K programmers now know that
> 10 years is not such a long time, after all).
> 
> Assuming I'm not missing anything, my recommendation to our
> customers would be PKI (though, they'll laugh at me: we have 
> a hospital
> customer with 10,000 more or less public PC's with twice the number
> of users), use some change password HTML page technology with all
> its incumbent problems or use a hacked version of the publicly
> available Netscape Communicator that supports the sort of headers
> I had suggested in my first note. I suspect most will go with the
> second alternative as being the least attractive but requiring the
> least work and/or money. Less work almost always seems to trump
> most other considerations.
> 
> Thanks again for your comments.
> 
> Alex Kodat
> Sirius Software
> Cambridge, MA
> 
>

Received on Sunday, 13 June 1999 21:31:00 UTC