[whatwg] fixing the authentication problem

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

Received on Tuesday, 21 October 2008 07:59:21 UTC