On Wednesday 28 August 2002 23:22, you wrote:
> I'm willing to be convinced that the nonce does in fact work in real-world
> Web applications with real-world Web browsers and that my original analysis
> of this technique earlier this year was flawed. Please point me to your
> research

I guess I haven't done "research" on the topic. I kinda figured it wasn't that
hard or opaque...

> How do you deal with the impact of
> proxy servers and proxy cache on the reliable delivery of every updated
> nonce?

expire all content, use SSL, and if you're really, really worried about it,
you can embed the nonce in the URL to ensure a fresh request.

> How do you deal with the reality that browsers behave differently
> with respect to accepting a Set-Cookie header sent in an HTTP response that
> the end user cancels before the entire body has been received?

First, we're talking about an un-reliable, stateless protocol. There's no such
thing as HTTP QoS = )

There are some lingering issues about what is atomic and what isn't that I
left out of the earlier discussions far for the sake of brevity. The
possibility exists that there could be a race condition on nonce requests
from "parallel" requests such as dynamically generated images and the like.
Your following suggestion about a "window" is one possible answer to this
problem.

> I had
> considered allowing a moving window of validity that would always encompass
> the two most recent nonce values, either one of which would be considered
> valid...

yeah, that's one (good) way to deal with it. Time limiting non-current nonces
also reduces your exposure. If the goal is to ensure that the attacker
doesn't have enough time to brute force the next sessionID, whatever method
you choose for your window is likely to be adequate.

> As for randomness and session IDs generated with hardware random number
> generators rather than produced through keyed hashing and encryption of
> randomness produced with software random number generators or a non-random
> but unique identifier algorithm as a means to create provably-secure
> session IDs ... I don't think we're in disagreement.

entropy is entropy. You can get it or fake it any number of ways. So long as
we pass a random oracle test, I really don't care much how we do it = )

> -- is unnecessary to achieve security for session IDs.

reasonable people can dissagree on this one. I was throwing /dev/random and
/dev/urandom out there as examples, but there are obviously other ways to get
streams of bits that are "random enough". Seeding a PRNG with a random value,
and then hashing hashes is another cheap way to get most of the way there. I
obviously prefer true entropy, but it's hard to get lots of it sometimes.

-- 
Alex Russell
alexSecurePipe.com
alexnetWindows.org

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]