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