5 ms·
It can all be done client-side: the client can try (un)capitalizing the letters after the original password fails
by joaomacp 5y ago
It can all be done client-side: the client can try (un)capitalizing the letters after the original password fails
- freemint 5y agoThis would be bad for rate limiting though.
- jacurtis 5y agoNote that the client would only need to do this on a failed attempt. So if i typed "Password" on mobile. The client would first send the request as "Password". If that succeeds, then no worries. If it fails, then the client could send a second request by reversing the case of the first letter. In this case, it would send a second request for "password". At most, it is 2 login requests per password. Many other commenters here are incorrectly stating that 3 requests would be necessary, but this is untrue. A letter can only have 2 possible cases (uppercase or lowercase). So the client sends the originally typed one, and if that fails, then it flips the case of that first letter. That is the only alternative. There is not a third option. A well-built login form would restrict users after 3-5 login attempts anyway and require a password-reset process. So that is 6-10 client requests to the backend (n * 2). That shouldn't be hitting any sort of rate limit.
- ipaddr 5y agoWhy would you need the client to send the request over and over when you control the backend?
- volkanvardar 5y agoNot to send the password in plain, maybe?
- freemint 5y agoAre you aware of transport encryption?
- ehsankia 5y agoIt would only half the rate limit, but any real brute force attempt requires way way more than what a normal human would try. Something like 5 attempts would double to 10 in the backend, still nowhere enough to bruteforce, but enough for human trial and error.
- konschubert 5y agoAnd it should. Better not to clutter the security-critical parts of the back end.