Below is a proposal, based on the problem statement by Paul Hoffman:
In many deployments of "SSL first, then authenticate the user with a
password", the "site" consists of two or more machines. Many or most
high-traffic secure sites use SSL front-end systems to terminate the SSL
connection, then pass the raw HTTP back to one or more web servers
inside the network.
The reason I bring this up is that the SSL server generally does not
have access to the users' credentials. It could, of course, but in
today's environments, it doesn't. Changing to TLS-PSK involves not only
changing all the client SSL software and server SSL software, but also
the what the SSL server's role in the transaction is.
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.
Now, we need to consider two cases: a `nomad` user, vs. a `stationary`
user. Stationary case is much nicer, and can use a single PW for all
sites (`single sign on`), and/or biometric/device solutions (which I
won't discuss).
For a stationary user, the extension compares _Iterations_ and confirm
it is at most one less than previous value of _Iterations_ used with
this site. Also, the extension keeps a table r(PK) mapping the public
key PK of each login site to an independant random value (we need this
as real random value and can't derive them from the PW, to prevent
dictionary attacks by fake sites).
Now, using a single PW, extension computes for a site with given PK the
value H(0)=h(PK, h(r(PK), PW). It then sends to the web server
H(_Iterations_), by H(i)=h(H(i-1)) - the usual trick. This looks pretty
good at first sight, so let's see who finds a big, unfixable hole in
this simple design - which requires `only` support by a script on the
web server (and of course an appropriate extension, but that's something
we know how to do... and we can do some `secure UI` to deal with
spoofing by other applications on the PC).
Well, the case of nomad users - using a public terminal, without any
secure storage facility - is less cool, imho, but there are some
solutions there as well. The first is to use the old S/Key scratchpad
method - user prints a few `one time passwords` for each of his login
sites at home, to use on the road. Well, maybe not the most friendly
solution, but will work (for known sites only). Notice that the `public
PC` does not even need to have the extension for this low-tech solution
to work (of course, this may allow a rogue site/PC to learn a specific
OTP for a specific login site).
Another solution is to use site-specific randomizers, i.e. user will
provide the value for the r(PK) table - or, we can give to the user the
values of r(PK) table... these do NOT have to be passwords, since their
role is really to act as `salt` - make it impractical for sites to do
dictionary attack on the `main` password. Maybe we can get away with
this, and try to prevent users from using the same values for multiple
sites... Of course, in this solution, user still enters her real PW to
the hosting, public PC - and security fails against key loggers etc.
Also this still requires us to use the extension on these machines... so
I like the previous solution better.
Ok, enough for now; now tell me what's wrong, etc.... It is definitely
too simple to be any good.
--
Best regards,
Amir Herzberg
Associate Professor
Department of Computer Science
Bar Ilan University
http://AmirHerzberg.com
Try TrustBar - improved browser security UI:
http://AmirHerzberg.com/TrustBar
Visit my Hall Of Shame of Unprotected Login pages:
http://AmirHerzberg.com/shame
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
