4 ms·
If the typical successful response takes 10msec, don't send response for at least 15msec. So whether the authentication challenge succeeds or fails, the respon
by jac_no_k 16y ago
If the typical successful response takes 10msec, don't send response for at least 15msec. So whether the authentication challenge succeeds or fails, the response always comes at 15msec or later.
- astrofinch 16y agoWouldn't it be possible to raise the typical response time above 15msec with a denial-of-service type attack? It seems to me that your system has to be able to adapt to situations where the typical response time changes drastically, and the attacker can exploit discrepancies in the way the typical response time will change depending on whether a packet's nth byte is valid or not. It might be possible to make keys arbitrarily difficult to crack using methods like what you and joe_the_user suggest, but the more security you add in the form of padding on extra response time, the more your regular users will suffer.
- jac_no_k 16y agoYou're right of course. So if it was done in say multiples of 15msec. The first window for a response is at 15msec. The second window at 30msec. The third window at 45msec and so on. And I agree it's difficult to keep the balance between an acceptable user experience and keeping the crackers at bay.
- fragmede 16y ago>You're right of course. So if it was done in say multiples of 15msec. The first window for a response is at 15msec. The second window at 30msec. The third window at 45msec and so on. Instead of the comparison that checks the whole field, start two threads, one per real cpu core, and run the unknown comparison against an a known good, and in parallel, and only return when both have completed. Not the most efficient, but would scale properly for faster and slower cpus.