[whatwg] fixing the authentication problem

[Aaron Swartz]

>> 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.

That's a good idea. The UA could add "&_random=..." where ... is a
bunch of random characters to the end of every form submission.

> 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.

Some sites already have the login box as an iframe loading from a
different page; that could be done here as well. The UA could also
request a new nonce via XHR as the form was being filled out.

> How will the server limit each nonce to being used once? If it stores

I would suggest Bloom Filters, which permit fast checks with low
storage requirements at reasonable levels of security.

The big problems with Digest are: a) it uses MD5, which is broken, and
b) it requires the server to store passwords in cleartext, which is
bad security practice. This proposal has neither of those problems.