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 [EMAIL PROTECTED]
