[whatwg] fixing the authentication problem

[Philip Taylor]

On Tue, Oct 21, 2008 at 2:52 PM, Aaron Swartz <me at aaronsw.com> wrote:
>> As I understand it: As an attacker, I can intercept that "dXN..."
>> string. Then I can simply make a login POST request myself at any time
>> in the future, sending the same encrypted string, and will get the
>> valid login cookies even though I don't know the password. So it
>> doesn't seem to work very well at keeping me out of the user's
>> account. Also this seems vulnerable to dictionary attacks, e.g. I can
>> easily encrypt "user=joesmith01&password=..." for every word in the
>> dictionary and will probably discover the user's password.
>
> I was simplifying; [...]

Simplifications make it hard to tell whether it's possible to use the
feature securely (and hard to tell what "securely" means in this
context), which is a necessary condition for usefulness, so it's
probably best to explain in detail exactly how you expect it'll be
used, and then people can try to pick holes in it :-) . (But at least
in my case, I know little enough about security that even if I can't
pick holes then I'd be unwilling to assume it's secure...)

> in real life, I expect the server will include a
> nonce with the form (as a hidden input), which they'll only permit to
> be used once.

That still doesn't help with the dictionary attacks, since the
attacker knows the nonce too. I'd guess the client has to add an extra
nonce (which is never transmitted in the clear) to avoid that problem.

For the server-generated nonce, the login form will have to be on a
page that is never cached, so that every client will get a new nonce
every time they load the page. That would prevent it being used in a
lot of cases where sites put a login box on every page (instead of
requiring the user to go through an extra login page), which is a
minor disadvantage of this scheme.

How will the server limit each nonce to being used once? If it stores
a list of every nonce that was ever used, it's going to be a pretty
large table and slow to check on any reasonably popular site. If it
encodes a timestamp in the nonce, it won't work if a user opens the
login page (causing the new nonce to be generated) in a background tab
and leaves it for a few days before trying to log in, which breaks the
usually-valid assumption that you can wait indefinitely between
separate HTTP requests. (Digest authentication avoids that problem
because it's defined at the HTTP level and can say that the browser
ought to respond immediately and to retry silently if the nonce was
stale.)

Probably more importantly, does this solve any of the security flaws
you indicated Digest authentication has? (i.e. how would it be better
than inventing a mechanism for allow custom styling of the browser's
username/password dialog box?)

-- 
Philip Taylor
excors at gmail.com