Phillip Hallam-Baker wrote: > That would seem to me to point to a more general fix. > > I don't like fixes that depend on the skill and intelligence of the > implementer. They tend to come unstuck. Fixing this timing bug is > good, but how many others are there? > > A much easier fix to implement and one that would have general > applicability against timing attacks would be to insert a delay before > returning an error condition. This has the additional benefit of > slowing down the attacker. > > I record the time I receive a packet as a matter of course. It would > not be difficult to write some code that ensures that the time take to > return an error is quantized at a pretty coarse level (10ms or so).
No. The attack then evolves to: 1. Ping server with correct login to known account, timing for expected RTT on success. 2. Perform timing attack on forged cookie: a. Each guess, wait predicted RTT+epsilon. If server has not responded by deadline, issue TCP RST and connect again. b. Parallelize this to guess across multiple sessions In order to help people skip the standard progression of awareness to timing attacks, we wrote this post 6 months ago. It might be worth reading before the next suggestion I expect (random delays): http://rdist.root.org/2010/01/07/timing-independent-array-comparison/ -- Nate Lawson Root Labs :: www.rootlabs.com +1 (510) 595-9505 / (415) 305-5638 mobile Solving embedded security, kernel and crypto challenges _______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
