Yes. Now find every place that can be slow in some cases and do the same thing.
Note: just doing this in your app isn't enough, because you run in a framework and on a virtual server, and things like memory usage affect the speed of these components.
Yes. That will make it tougher to figure out. Your assumption that timing attacks are impossible because they are hard to trace seems optimistic, though.
This is specifically a security problem. Saying "I'll sweep it under the rug" and considering it solved is historically a bad idea.
This chain of "I'll just do X", "no, X isn't enough", "then I'll do Y", "no, Y isn't enough", "then I'll do Z" are typical of these problems.
Unfortunately, each "I'll just" is code for "I'm not going to think through this problem because I think it's easy." As with X and Y above, Z is likely to have serious problems.
Example problem with the queue approach: hacker puts in lots of password reset requests for his own domain(s) and sees that the queue workers have delays of 0.22 seconds between sending back responses to his domain, with gaps which add 0.37 seconds or 0.22 seconds, to within some error. Inference: a wrong email takes slightly longer because it often has a retry, and the 0.22 second entries are other correct password reset requests to valid domains.
Now he can send back a stream of passwd requests to his domain interspersed with three or four requests to a given email address. Now he knows if it's valid or not. ("I'll just block his domain?" "He'll use a botnet, he is anyway" "I'll just rate-limit password resets!" "Good idea - now, do you really believe that that was the last hole in your swiss-cheese security?")
Now you could fix this, too. But see how we've gone through yet another "I'll just?" You can make sure to do the delay in lookup and email sending on each entry in the queue (by the way, you've slowed down all your queue workers and likely increased your hardware costs), but trying to not think about this and sweep it under the rug is really hard.
When patio11 says that timing attacks aren't trivial to fix, this is what he means.
Is the "put it in a queue, add a delay to the queue" method perfect? That is, is "I'll just do Z" the answer? No. Having the queue sleep() is less load on other components, which an attacker can check for by pinging other services. Having it busy-wait is a different load profile than receiving an email. That's the microsecond-precision thing that patio11 mentions where an attacker can get another instance on the same Rackspace network and measure with a side-channel attack.
This is a really hard problem because there are an almost unlimited number of side channels here, and your OS doesn't try to keep information from leaking out on them.
Would it be possible to limit these via an outbound filter? I'm thinking something like a 'do not respond before' header and a web server plugin.
That would be relatively expensive, but if you just do it for login/registration/password resets it might go a fair way towards mitigating those sorts of attacks.
How is your "do not respond before" implemented? Does it sleep? Or busy-wait? Either is basically detectable because it affects (or doesn't) the performance of everything else on the machine (such as pings, other web requests, SSH login, etc).
But yes. Every layer you add (maybe) makes it a bit harder for an attacker. You simply can't stop a dedicated attacker, reasonably speaking.
"Do not respond before" would at least make an attacker have to use a (somewhat) less reliable second channel to find out. Expensive, but it would do you a bit of good against casual attackers.
Beyond that, you can't really block unless you block all the channels -- i.e. add a "do not respond before" to everything, not even just web requests.
Also, when you say "do not respond before" is a header, I assume you mean set by your reverse proxy before the back en handles it. Clearly setting that from the client won't do you any good at all :-)
I have no idea how it would be implemented (other than "some sort of web server plugin"), and I was thinking from the PoV of a web app, so ssh would (might?) be out of scope.
The concept was just that no request for paths related to logins or passwords would take less than an amount of time, eg. 0.1s or 0.5s. It could even just be a config option.
Configuring it at the firewall/web server side would be an easy way to make life harder for an attacker, without having to fiddle with (or even understand) the internals of a web app.
If the web app uses extra memory or CPU, SSH response time may be affected. So delaying in the web app doesn't do a good job of concealing CPU and memory use by the web app, because it's a shared-resource system.
Note: just doing this in your app isn't enough, because you run in a framework and on a virtual server, and things like memory usage affect the speed of these components.