Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)

Mon Jan 21 08:23:53 UTC 2013

On 1/21/13, Matt Palmer <mpalmer at hezmatt.org> wrote:

> Nonce on the server is a scalability hazard (as previously discussed).  You

It's not really a scalability hazard.   Not if its purpose is to
protect a data driven operation, or the  sending of an e-mail;   in
reality,  that   sort of abuse is likely need to be protected against
via a captcha challenge as well,   requiring  scalability hazards such
as performing image processing operations on the fly....

The logistical challenge with a nonce, is ensuring that the server
generated and stored a long enough list of nonces for request load;
you need to make sure that you never give out the same nonce twice,
and  you make sure  you  wipe out  old sets of of nonces frequently,
and then the only really hard part:  when a nonce is used, you persist
the fact that it is no longer valid.

So you come to consider,  the bottleneck: "Persisting the fact that
nonce X was used"
versus   "Sending this e-mail message"  or    "Posting entries to the
database to complete the operation this form is supposed to do"

"The operation this form is supposed to do"   will normally be the
larger scalability hazard,  usually involving more  complicated
database operations,   than some nonce   record maintenance.

> can't put a timestamp in a one-way hash, because then you've got to hash
> all possible valid timestamps to make sure that the hash the user gave you
> isn't one you'll accept.

No, but you can use

 codevalue =  "<at_timestamp>:SHA1(<secret>:<at_timestamp>:<submission_id>:<formaction>:<client
ip>)"

If      current_time - at_timestamp    > X   :
        require_resubmission

> The problem with this method, though, is that the only thing that stops the
> attacker from retrieving the entire chunk of data out of your form and

Yeah... about that... if they can do that, they can surely steal a cookie,
which persists,  beyond the time the form is displayed in a browser.

The adversary may be able to get the actual site to set the cookie in
the unwitting user's browser by using an invisible IFRAME or other
techniques,   including ones to set a cookie for a different domain,
circumventing  the use of cookie as abuse prevention methods.

The cookie is also susceptible to replay attack if something such as
the client IP address is not a factor.

> Which is decidedly more user-friendly than most people implement, but
> suffers from the problem that some subset of your userbase is going to be
> using a connection that doesn't have a stable IP address, and it won't take

That would be quite unusual, and would break many applications for that user...

Although there is nothing mutually exclusive about cookies and other methods.
It is possible to set a cookie to be used as an additional factor,
after detecting that
the user's  IP address might be unstable.

> I just realised that I may have been insufficiently clear in my original
> request.  I'm not looking for *any* solution to the CSRF problem that
> doesn't involve cookies; I'm after a solution that has a better
> cost/benefit  than cookies.

How about the issue that:  cookies don't necessarily address CSRF?
Cookies are OK  for storing user preferences,  but not to authenticate
 that the user actually authorized  that their browser make that HTTP
request.

The user can have been browsing the form legitimately.
The user unwittingly opens a malicious web page in another window,
after having accessed the form  recently.

The required cookie is already set:  the user might even have a logged
in session,  with an authentication cookie set in the browser.

The malicious page can abuse an already-logged-in session by sending a
POST request to it.   Or have persuaded the user to login,  while the
malicious page is still in memory,
and able to make  quiet discrete  POST requests.

Cross-site POST operations are allowed operations;  and the cookie was
already set.

On the other hand...  a value in the form presented,  should be
protected  against the malicious site,  by the same origin policy.

So perhaps if you need  to use a value in the form anyways,  the
cookie is redundant

-- 
-JH