On 1/21/13, Matt Palmer <mpalmer@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