3 ms·

Easily accommodated for. I can get the execution run-time and store in an average in memory for some time-period and have the sleep function top-up the differen

by animex 6y ago

Easily accommodated for. I can get the execution run-time and store in an average in memory for some time-period and have the sleep function top-up the difference between the two paths. Not sure what the "proper security" method is to prevent execution deltas.

renewiltord 6y ago
Why not just run the thing (which takes some small fraction of time), then pad to five seconds, and respond. Since your work will be done in milliseconds, padding to nearest five seconds will remove any noise. And it's not a thing anyone has a legitimate interest in submitting more than that per second.
- odonnellryan 6y ago
  Adding five seconds to everything just adds five seconds, it doesn't matter if the difference between the two requests is .01s or 5.01s.
  - throwaway894345 6y ago
    The parent said "pad to 5 seconds" not "add 5 seconds". Thus everything would be 5 seconds (never 5.01). The difference between a hit and a miss would be exactly 0s. Note that I'm not advocating for or against this solution; rather, clarifying the conversation.
  - renewiltord 6y ago
    Pad to, not pad by. I.e. the padding to add is (5 - duration_of_operation) with duration of operation being far lower than 5 s.
bitexploder 6y ago
Depends. With comparison functions you can implement a constant time comparison that takes the same amount of time. In this case it isn’t really a crypto problem, so anything where we are confident about things taking the same amount of time is fine. Basically in some parent method/func make sure we always spend 2000ms or whatever time is that is always greater than the max runtime of the slowest path. Secondary / defense in depth mitigations would be rate limiting this page and making it purposefully slow on response, just to make it that much harder to collect samples / abuse it without being noticed. The captcha is a nice touch, but it didn’t seem particularly strong (a good captcha solver could break it). Still, captcha will chase off a lot of script kiddies. You don’t have to be faster than the bear, just faster than the slowest person ;)

by animex 6y ago

renewiltord 6y ago

Why not just run the thing (which takes some small fraction of time), then pad to five seconds, and respond. Since your work will be done in milliseconds, padding to nearest five seconds will remove any noise. And it's not a thing anyone has a legitimate interest in submitting more than that per second.

odonnellryan 6y ago
Adding five seconds to everything just adds five seconds, it doesn't matter if the difference between the two requests is .01s or 5.01s.
- throwaway894345 6y ago
  The parent said "pad to 5 seconds" not "add 5 seconds". Thus everything would be 5 seconds (never 5.01). The difference between a hit and a miss would be exactly 0s. Note that I'm not advocating for or against this solution; rather, clarifying the conversation.
- renewiltord 6y ago
  Pad to, not pad by. I.e. the padding to add is (5 - duration_of_operation) with duration of operation being far lower than 5 s.

bitexploder 6y ago

Depends. With comparison functions you can implement a constant time comparison that takes the same amount of time. In this case it isn’t really a crypto problem, so anything where we are confident about things taking the same amount of time is fine. Basically in some parent method/func make sure we always spend 2000ms or whatever time is that is always greater than the max runtime of the slowest path. Secondary / defense in depth mitigations would be rate limiting this page and making it purposefully slow on response, just to make it that much harder to collect samples / abuse it without being noticed. The captcha is a nice touch, but it didn’t seem particularly strong (a good captcha solver could break it). Still, captcha will chase off a lot of script kiddies. You don’t have to be faster than the bear, just faster than the slowest person ;)