For the string comparison, could you really use that in a timing attack. Wouldn't the difference between comparison taking one char longer be measured in nanoseconds, while the overall network lag would be milliseconds?
I don't see string comparisons on tiny strings as feasible from either the Crosby/Wallach (suggests you need hundreds of nanoseconds of difference in execution time to be detectable) paper nor the Brumley/Boneh paper (which talks about a specific vulnerability in modular exponentiation which ends up revealing key details, not string comparison).
This is just a guess on how you would do it... but it would involve making many many many requests until you could establish a mean against a given confidence level. Then you could compare that mean for each starting character (once again, many many many requests for each character). If the mean of any of them (or heck, even the distribution of the timings) differ than the others, then you know you you hit the right mark.
This assumes that 1: you can reliably measure at that small of a time difference and 2: you can submit enough requests without being detected.
Yes, I don't see that being detectable for things like web-based APIs. For these string lengths (eg., HMAC with SHA-256), the network lag would add sufficient randomness that you would not be able to measure any difference in timings in the string comparison.
It turns out that it is possible, over a WAN, on some frameworks. The rule of thumb is, if the comparison is effectively being done by libc's memcmp(), the timing attack is very difficult to do even across a single switch; however, some platforms don't drop to memcmp and instead compare each byte explicitly. These are timeable.
If you're wondering, "how do I detect nanosecond differences over a network when my measurement will be swamped by other things happening on the target, the network, and my host", the answers boil down to:
* You're going to move your measurement code as close to the drivers as possible, and fix interrupt handling so that interrupts don't confound your measurements.
* You're going to get yourself on the same hosting provider as your target; for instance, a good chunk of all target apps can be attacked via Amazon EC2 for not very much money.
* You're going to take lots and lots and lots and lots of measurements and then use high school statistics to process the results.