Re: [pmg-devel] [PATCH pmg-api/gui] add quarantine self service button

[Dominik Csapak <d.csapak@proxmox.com>]

On 11/18/20 9:01 AM, Thomas Lamprecht wrote:
> On 18.11.20 08:56, Dominik Csapak wrote:
>> On 11/18/20 8:44 AM, Thomas Lamprecht wrote:
>>> On 17.11.20 17:38, Dietmar Maurer wrote:
>>>>
>>>>> On 11/17/2020 5:27 PM Dietmar Maurer <dietmar@proxmox.com> wrote:
>>>>>
>>>>>    IMHO this is too dangerous.
>>>>>
>>>>> This needs at least some kind of captcha ...
>>>>
>>>> i.e. This would allow direct DOS attacks to the internal mail server.
>>>>
>>>
>>> I found this captcha solution, relatively sophisticated but not a PITA for the
>>> (human) user, Friendly Captcha[0] used by some official European Union websites.
>>>
>>> It uses Proof of Work[2] (i.e. crypto puzzel ones device needs to solve by
>>> computation), the specific library used is "Friendly PoW"[1].
>>>
>>> If we go for a captcha I'd like something like this (could be rebuild), as
>>> it avoids the issues with picture texts (easily solved by computers, bad
>>> accessibility for humans) and similar captchas.
>>>
>>>
>>> [0]: https://github.com/friendlycaptcha/friendly-challenge
>>> [1]: https://github.com/friendlycaptcha/friendly-pow
>>> [2]: https://de.wikipedia.org/wiki/Proof_of_Work
>>>
>>
>> i'd rather go with a rate limited approach
>> e.g. a file with a
>> mail -> last click time
>> mapping
>> and refuse if the last click time is not older than 5min ?
>> and only 1 per 5 seconds overall?
> 
> or an hour or day? what do you need the mail such often??
> The ticket doesn't even expires that fast..

sure, that was just an example (an hour would be ok)
it should not be that far apart that if a user
accidentally deletes the mail he cannot request
a new one in reasonable time frame

the overall timeout would have to be much shorter so that
legitimate users do not block each other, but long
enough to discourage an attacker.. (thus my 5 seconds,
it is short enough that the api call can block without
much hassle for the user, but long enough so that
an attacker can not dos the internal mail server)

> 
>>
>> a captcha would be much harder to implement (more dependencies,
>> backend as well as dependent frontend code and in this example
>> it seems the code is only available for js/ts), though
>> if we find a simple solution, i am not against it
>>
> 
> but also more efficient, as the client actually needs to put in
> work. JS is no problem, the backend would be nice in rust or
> so - maybe in the future when someone gets around some day...
> 

yes js is no problem, but the much bigger "problem" is that for a
captcha you generally have to save a state for each client
(else it would be easy to precalculate or reuse the work)
which is probably much bigger than my 'last click time'
approach from above