I’m not sure if this feature exists and I missed it, but I’m wondering if there’s a way to throttle GUI password sign-in attempts to prevent the password from being bruteforced. I’m thinking some kind of global timer (maybe with exponential backoff) would be plenty.
Use case: I have a headless server running syncthing and the GUI endpoint is exposed to the internet. Although I’ve chosen a strong, unique password, I’m still worried that someone might try to brute force it.
Does this seem useful? Would it be difficult to implement?
I would be happy to take a crack at it, but I’m not familiar with Go or the codebase.
They are already throttled somewhat, in that a login failure takes a minimum of 100ms or something like that. You can integrate with external tools (like fail2ban) to get more control if you like.
Just to add more details, it uses bcrypt with some specific “work factor”, which claims to be bruteforce resistant.
That plus we do a random amount of sleep before returning an auth failure.
Oh okay, cool. I trust the bcrypt difficulty factor. Do you know what factor is being used now, or if there’s a way to set a custom factor in the syncthing config file?
It looks like the code uses
0 which falls back to the default configured which might be 10? I remember the advice was to use a hash cost of 12 a few years ago, and stack exchange seems to agree?
I mean, you should still just setup fail2ban.
We don’t throttle the number of requests in any way, even if it takes 10s per auth attempt, you can just fire 10s of thousands of requests in parallel, but it will be obvious from logs that that is happening.
Okay, that sounds good. Thank you all!