Login ratelimit
Is there a way to set some rate-limit for login form? This can prevent brute-force attacks to guess usernames and passwords.
Most options would rely on a counter being stored either on a database or on a session variable; a database would increase the dependency on a DBMS, a session counter could be ignored/reset by the attacker.
I've added 2FA authentication in mine (although requires a device like smartphone, etc). I was supposed to add 2FA options interactively, but didn't have the time or patience to get around doing that so the setup is mostly static. Here's the commit where I introduced 2FA in one of my branches: https://github.com/prasathmani/tinyfilemanager/commit/af2a70d51fb4d0cf6499bd99f2e7d9230dbc4981, and also this fix to the previous commit https://github.com/prasathmani/tinyfilemanager/commit/b0a2e20f3224de32276ea88680790075ea07f346
Can you PR that? Also when talking about 2FA, support for hardware keys should be added
Can you PR that?
I don't feel confident in the way it is implemented, if I do make it cleaner like I was supposed to then sure, I might. Anyone is free to do it though. Things I want to see done first (especially the first couple ones):
- Clear with author how he feels about adding a dependency to an otherwise monolith application;
- Toggle function in settings;
- Request 2FA only after user/password login to decide if user's 2FA needs to be initialized first or not;
- Do more research to see if there are better 2FA classes than the one I used.
hardware keys should be added
I don't own any, so I couldn't test that, maybe someone else could do that.
@ririko5834 I'm fairly happy with https://github.com/prasathmani/tinyfilemanager/pull/1054, so I'm thinking that'd be it for now in relation to my contribution to 2FA auth implementation. It adds subtle functionality refinements over the initial implementation, mostly UI/UX stuff.
Again, this is regardless of approval or adoption by the author of the original repository.