simple (&secure??) PW-based web login (was Re: Another entry in theinternet security hall of shame....)

[Anne & Lynn Wheeler]

Amir Herzberg wrote:
> Excellent point. From which follows the question: can we improve the
> security of password-based web login, with less drastic changes - at
> least in the servers? Or is TLS-PSK the best/only way for us to improve
> pw-based web login?
> 
> I think we can. For simplicity and concreteness, let's say we have the
> following architecture: regular SSL-supporting client and server, and
> behind the SSL server we have a web server with the improved pw-login
> mechanism. We want to support some `improved pw-login clients`, let's
> say these will be regular browsers with an extension such as (a new
> version of) TrustBar.
> 
> Client and server begin with SSL `as is`. Now, the web server sends over
> this SSL-protected page a login page. Browsers without the extension,
> will handle it as a `classical` login form. But if the extension exists,
> it will detect that the server supports improved pw-based login,
> signalled e.g. with a META tag. The tag may also include number, denoted
> _Iterations_, which is the request number of hash-function iterations.

by the time all the authentication options are being created ... you
might as well move to radius or kerberos as core authentication
technology ... if nothing else to manage and administer the myriad of
co-existing authentication possibilities.

once you have an effective administrtative infrastructure for managing
different and co-existing authentication technologies ... there is an
opportunity to examine the level of technology required for some of the
password-based technologies vis-a-vis a straight forward certificateless
public key (where public key is registered in lieu of password) and
digital signature verification
http://www.garlic.com/~lynn/subpubkey.html#certless

so the requirements are somewhat ... resistant to evesdropping on the
interchange and related replay-based attacks; possibility of using the
same password with multiple servers ... w/o cross security domain
compromises; availability of the software to perform the operations.

so if the assuption is that SSL is part of the basic infrastructure ...
that should satisfy whether there is availability of public key software
available at both the client and the server (even tho it may tend to be
entangled with digital certificate processing).

from the client prospect, i would contend that having the client keep
track of server-specific details as to things like login iterations or
other details ... creates client operational management complexity ...
but at least requires some form of container. such a container
technology could possibly be as easily applied to keeping track of
private key.

the meta tag scenario applies equally well to returning a digital
signature as one-time-password ... possibly as well as any of the other
schemes (especially if you have something like radius on the server side
for the administrative management of the variety of co-existing
authentication technologies). Note that some flavor of this is used for
ISP PPP dial-up authentication (and raidus infrastructures) ... where
client may have option of multiple different authentication technologies.

In many ways the administrative management of multiple concurrent,
co-existing authentication technologies ... is at least as complex issue
as the implementation details of any specific technology (especially if
you are considering a large complex infrastructure that is facing
operational environment spanning large number of years and dealing with
a wide variety of different client and server requirements). One of the
advantages of dumping the PKI concept (which is really targeted at first
time interaction with strangers) ... and going with single management
and administrative infrastructure (using a radius-like model) is that a
wide variety of co-existing authentication technologies can be managed
in a single administrtive environment (w/o requiring the cost and effort
duplication of having two or more deployed authentication operations ...
aka the real-time production environment and any redundant and
superfluous duplicate PKI environment).

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com