4 ms·

Proof of work system. Require your clients to perform some amount of computation to do a request. Something like this: https://www.npmjs.com/package/work-toke

by r32a_ 8y ago

Proof of work system. Require your clients to perform some amount of computation to do a request. Something like this: https://www.npmjs.com/package/work-token https://www.npmjs.com/package/work-token

ryanlol 8y ago
Does this actually run fast enough in browsers to be useful?
gruez 8y ago
I know blockchain and PoW is the thing to talk about right now, but if you think about it, client-side PoW is kind of a bad system. the whole point of such a system -PoW or captcha- is to increase the cost for the attacker to do the attack, so rather than $0.00000001/request (if you're renting a russian botnet or something), it costs a bit more, hopefully more enough that it's not worth it for the attacker to continue. a quick search on google says that recaptcha2 solvers can be obtained for $0.003/solve, which makes the cost per attack $0.003. on the other hand, the PoW is much lower. let's assume most of your visitors have a dual core system, and you require 30 seconds of PoW to log in. a dual core ec2 instance (c5.large) can be rented for $0.096/hour. at 30 seconds per solve, it can generate 120 solutions, for a final cost of $0.0008 per attempt. so in this case, going with the captcha solution is clearly the better solution as it costs almost 4x as much per attempt. there's a bunch of other factors not accounted for that makes PoW worse: * native code can almost certainly run faster than javascript code, even if you're using webassembly. in my experience js cryptominers operate at around half the speed compared to their native counterpart on the same machine * the attacker can leverage GPUs to compute solutions hundreds of times faster than what your users can * users have to wait 30 seconds before they can login. you can generate the key while the user's filling in the form to shave off a few perceived seconds, but that will result in a sluggish login form * users with slow CPUs (ie. anything slower than what's in a c5.large) will take even longer to generate a solution. this is especially problematic for people on smartphones * users might think that your site's high CPU usage is because you're running a cryptominer on your site!
- ShadowBanker98 8y ago
  >native code can almost certainly run faster than javascript code What if you write it in Electron though?
- inetknght 8y ago
  > which makes the cost per attack $0.003. on the other hand, the PoW is much lower. If your attacker isn't even paying for the resources they use, such as from botnets or borrowed, then your attack value has gone out of the window. If the indivdual attack is free to the attacker, then you're left with time. PoW guarantees a time value. If a single PoW is too cheap, then ask for more values.
bullen 8y ago
I use single salt SHA256 hashing for all HTTP login. https://github.com/tinspin/rupy/blob/master/src/se/rupy/http/User.java#L126 https://github.com/tinspin/rupy/blob/master/src/se/rupy/http... It's secure and solves this problem too.
- minitech 8y ago
  How does it solve this problem? A single SHA-256 isn’t a significant amount of work.
  - bullen 8y ago
    You can just loop it to require more CPU. Dynamically even! So it solves this problem AND it's secure! No brainer. But you can keep using HTTPS if you want.
kazinator 8y ago
> Someone who wishes to abuse your API by sending large numbers of requests would then need to spend large amounts of time computing the work tokens. Someone who wishes just to abuse your API with no intention to actually log in will just flood you with reams of requests to obtain new work tokens without executing any of them. So you're back to regular rate limiting, etc.

by r32a_ 8y ago

ryanlol 8y ago

Does this actually run fast enough in browsers to be useful?

gruez 8y ago

I know blockchain and PoW is the thing to talk about right now, but if you think about it, client-side PoW is kind of a bad system. the whole point of such a system -PoW or captcha- is to increase the cost for the attacker to do the attack, so rather than $0.00000001/request (if you're renting a russian botnet or something), it costs a bit more, hopefully more enough that it's not worth it for the attacker to continue. a quick search on google says that recaptcha2 solvers can be obtained for $0.003/solve, which makes the cost per attack $0.003. on the other hand, the PoW is much lower. let's assume most of your visitors have a dual core system, and you require 30 seconds of PoW to log in. a dual core ec2 instance (c5.large) can be rented for $0.096/hour. at 30 seconds per solve, it can generate 120 solutions, for a final cost of $0.0008 per attempt. so in this case, going with the captcha solution is clearly the better solution as it costs almost 4x as much per attempt. there's a bunch of other factors not accounted for that makes PoW worse: * native code can almost certainly run faster than javascript code, even if you're using webassembly. in my experience js cryptominers operate at around half the speed compared to their native counterpart on the same machine * the attacker can leverage GPUs to compute solutions hundreds of times faster than what your users can * users have to wait 30 seconds before they can login. you can generate the key while the user's filling in the form to shave off a few perceived seconds, but that will result in a sluggish login form * users with slow CPUs (ie. anything slower than what's in a c5.large) will take even longer to generate a solution. this is especially problematic for people on smartphones * users might think that your site's high CPU usage is because you're running a cryptominer on your site!

ShadowBanker98 8y ago
>native code can almost certainly run faster than javascript code What if you write it in Electron though?
inetknght 8y ago
> which makes the cost per attack $0.003. on the other hand, the PoW is much lower. If your attacker isn't even paying for the resources they use, such as from botnets or borrowed, then your attack value has gone out of the window. If the indivdual attack is free to the attacker, then you're left with time. PoW guarantees a time value. If a single PoW is too cheap, then ask for more values.

bullen 8y ago

I use single salt SHA256 hashing for all HTTP login. https://github.com/tinspin/rupy/blob/master/src/se/rupy/http/User.java#L126 https://github.com/tinspin/rupy/blob/master/src/se/rupy/http... It's secure and solves this problem too.

minitech 8y ago
How does it solve this problem? A single SHA-256 isn’t a significant amount of work.
- bullen 8y ago
  You can just loop it to require more CPU. Dynamically even! So it solves this problem AND it's secure! No brainer. But you can keep using HTTPS if you want.

kazinator 8y ago

> Someone who wishes to abuse your API by sending large numbers of requests would then need to spend large amounts of time computing the work tokens. Someone who wishes just to abuse your API with no intention to actually log in will just flood you with reams of requests to obtain new work tokens without executing any of them. So you're back to regular rate limiting, etc.