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

[Amir Herzberg]

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 majordomo at metzdowd.com