3 ms·

If the idea is to create a bottleneck, then why not throttle login at the server? Eg. have mutex for logging in, only allow one request at a time and then slow

by troels 16y ago

If the idea is to create a bottleneck, then why not throttle login at the server? Eg. have mutex for logging in, only allow one request at a time and then slow that down with a slight wait (Say, 1 second). You'll have to balance the exact throttle with the number of legitimate users on the system, and you'd probably want a timeout-and-retry mechanism in place.

aw3c2 16y ago
I love the idea for login systems that exponentially (or somewhat exponentially) prolong the waiting period. Eg 1 second, 2, 4, 8 and so on. There should be a reasonable maximum of course, say 5 minutes. That would leave 300 attempts per day which renders brute force useless yet is low enough to not annoy users too much if you explain the motive.
- troels 16y ago
  Yes, that's probably a better solution.
JoachimSchipper 16y ago
The system you propose doesn't work: either you don't lock anyone out, or you lock out a similar percentage of legitimate users and spammers. Imposing a separate delay on each attempt (but with no global mutex) is actually done in practice; see "greylisting".
- troels 16y ago
  "The system you propose doesn't work: either you don't lock anyone out, or you lock out a similar percentage of legitimate users and spammers" How so? Requests are piled in a queue, waiting for the mutex. If the request can't be completed for a given timeout (Say, 3 times the delay), you'll respond with an error message and the client will retry his request. You could automate the retry, so the user will only experience that it takes time - not a failure. The biggest problem I see here is that it's a clear DoS attack vector.
  - JoachimSchipper 16y ago
    If you set your logins/hour limit higher than the actual logins/hour, your scheme does nothing except smooth some peaks by forcing people to wait. If you set it lower, there will always be (a growing number of) people waiting to log in. In either case, you annoy real users and spammers to the same degree.

by troels 16y ago

aw3c2 16y ago

I love the idea for login systems that exponentially (or somewhat exponentially) prolong the waiting period. Eg 1 second, 2, 4, 8 and so on. There should be a reasonable maximum of course, say 5 minutes. That would leave 300 attempts per day which renders brute force useless yet is low enough to not annoy users too much if you explain the motive.

troels 16y ago
Yes, that's probably a better solution.

JoachimSchipper 16y ago

The system you propose doesn't work: either you don't lock anyone out, or you lock out a similar percentage of legitimate users and spammers. Imposing a separate delay on each attempt (but with no global mutex) is actually done in practice; see "greylisting".

troels 16y ago
"The system you propose doesn't work: either you don't lock anyone out, or you lock out a similar percentage of legitimate users and spammers" How so? Requests are piled in a queue, waiting for the mutex. If the request can't be completed for a given timeout (Say, 3 times the delay), you'll respond with an error message and the client will retry his request. You could automate the retry, so the user will only experience that it takes time - not a failure. The biggest problem I see here is that it's a clear DoS attack vector.
- JoachimSchipper 16y ago
  If you set your logins/hour limit higher than the actual logins/hour, your scheme does nothing except smooth some peaks by forcing people to wait. If you set it lower, there will always be (a growing number of) people waiting to log in. In either case, you annoy real users and spammers to the same degree.