httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <>
Subject Re: PUT authoring
Date Tue, 18 Jun 1996 15:41:01 GMT
> Which, by my understanding, was exactly how digest auth worked.  Except
> you don't need to create a challenge specific to "brian", "brian" is sent
> back with the hash of the secret password and the challenge.

interesting. as you've already guessed I've not looked at digest auth.

> I guess the disconnect I'm having is that one-time-password systems I'm
> familiar with involve some external mechanism to map challenges to
> responses - a piece of paper with challenge/response pairs, a small
> calculator-sized box with an lcd screen, etc

It can be embedded into any client application. If telnet had it
as standard, then there would be far fewer successful attacks which
originate from sniffed passwords flying over the net in the clear.
A telnet client could detect an skey server and automatically handle the
one-time password generation on the local machine by intercepting the
secret password and replacing it with the o-t-p. 

Anyway that's another thing on lots of people's wish lists.

> - and more importantly, it
> involves a true, unbroken session, as in a telnet session.

No each connection can use a new o-t-p  ... which is a feature that
can be used to limit the number of requests made by any client. Very
useful for pay-per-view applications. 

> HTTP at a
> semantic level (if not a functional level anymore) breaks the connection
> with every object request, so the system which asks for reauthentication
> needs to be automated to some degree, unless you want people to enter a
> new password for every object.  And that's where digest auth fits in, no?

On the client-side, it would appear that skey and digest auth have very
similar requirements. Both can be automated.

Anyway, let's see what Bill? can come up with.


View raw message