Timing attack countermeasures

[mf59816]

I've written down a simple idea that may help a great deal. We should implement it, if only because it's simple and because it'll make it easier to reason about it effectively.

• branch: 2015-06-06-mf-against-timing-attacks
• browse the branch: https://github.com/liqd/thentos/tree/2015-06-06-mf-against-timing-attacks
• open a pr: https://github.com/liqd/thentos/compare/2015-06-06-mf-against-timing-attacks?expand=1

[mf59816]

more thoughts:

• timing attacks will be much less accurate with this. in the case where there is only one time value and it never times out, there is no timing information for the attacker at all. (of course, the no-timeouts condition is infeasible in practice. what can we achieve anyway?)
• perhaps this can be done on a per-action basis for better response times with same security level. this may make security guarantees more difficult, though.

[fhartwig]

Some additional points:

• in general, timing attack vulnerabilities are caused by timing of operations being dependent on secret data. This means that to protect against them, we have to have a notion of what information specifically we consider secret. For the purposes of this problem, I'll assume that all individual user data is secret (maybe excluding the user name?), and user passwords especially so. (Oh, and service keys).
• I think we're covered for all operations on passwords (and service keys), since we only operate on them using the scrypt functions whose timing should already be independent of the password contents.
• The lookup operations that use user data as keys (e.g. lookupUserByEmail) may be problematic since they branch on secret data. I think we could easily improve these by using HashMap instead of Map, which should make it much harder to draw conclusions about the contents of these Maps from lookup times.

[mf59816]

Using HashMap may be a good countermeasure, but I would like to come up with a more rigorous approach that covers everything we can think of plus those things we can't.