1 |
On Thu, 2020-05-21 at 12:45 +0200, Jaco Kroon wrote: |
2 |
> Even for v4, as an attacker ... well, as I'm sitting here right now I've |
3 |
> got direct access to almost a /20 (4096 addresses). I know a number of |
4 |
> people with larger scopes than that. Use bot-nets and the scope goes up |
5 |
> even more. |
6 |
|
7 |
See how unfair the world is! You are filling your bathtub with IP |
8 |
addresses, and my ISP has taken mine only recently. |
9 |
|
10 |
> > Option 3: explicit CAPTCHA |
11 |
> > ========================== |
12 |
> > A traditional way of dealing with spam -- require every new system |
13 |
> > identifier to be confirmed by solving a CAPTCHA (or a few identifiers |
14 |
> > for one CAPTCHA). |
15 |
> > |
16 |
> > The advantage of this method is that it requires a real human work |
17 |
> > to be |
18 |
> > performed, effectively limiting the ability to submit spam. |
19 |
> > |
20 |
> Yea. One would think. CAPTCHAs are massively intrusive and in my |
21 |
> opinion more effort than they're worth. |
22 |
> |
23 |
> This may be beneficial to *generate* a token. In other words - when |
24 |
> generating a token, that token needs to be registered by way of capthca. |
25 |
> |
26 |
> > |
27 |
> > Other ideas |
28 |
> > =========== |
29 |
> > Do you have any other ideas on how we could resolve this? |
30 |
> > |
31 |
> Generated token + hardware based hash. |
32 |
|
33 |
How are you going to verify that the hardware-based hash is real, |
34 |
and not just a random value created to circumvent the protection? |
35 |
|
36 |
> Rate limit the combination to 1/day. |
37 |
> |
38 |
> Don't use included results until it's been kept up to date for a minimum |
39 |
> period. Say updated at least 20 times 30 days. |
40 |
|
41 |
For privacy reasons, we don't correlate the results. So this is |
42 |
impossible to implement. |
43 |
|
44 |
> The downside here is that many machines are not powered up at least once |
45 |
> a day to be able to perform that initial submission sequence. So |
46 |
> perhaps it's a bit stringent. |
47 |
|
48 |
Exactly. Even once a week is a bit risky but once a day is too narrow |
49 |
a period. |
50 |
|
51 |
To some degree, we could decide we don't care about exact numbers |
52 |
as much as some degree of weighed proportions. This would mean that, |
53 |
say, people who submit daily get the count of 7, at the loss of people |
54 |
who don't run their machines that much. It would effectively put more |
55 |
emphasis on more active users. It's debatable whether this is desirable |
56 |
or not. |
57 |
|
58 |
> |
59 |
Both the token and hardware hash can of course be tainted and is under |
60 |
> "attacker control". |
61 |
|
62 |
Exactly. So it really looks like exercise for the sake of exercise. |
63 |
|
64 |
|
65 |
-- |
66 |
Best regards, |
67 |
Michał Górny |