[159768] in North American Network Operators' Group
Re: Suggestions for the future on your web site: (was cookies, and
daemon@ATHENA.MIT.EDU (Jimmy Hess)
Mon Jan 21 03:24:09 2013
In-Reply-To: <20130121061926.GS31028@hezmatt.org>
Date: Mon, 21 Jan 2013 02:23:53 -0600
From: Jimmy Hess <mysidia@gmail.com>
To: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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
