Skip to main content
replaced http://tools.ietf.org/html/rfc with https://www.rfc-editor.org/rfc/rfc
Source Link

As @Rory said, it depends on your security posture, but if it's not a very high risk site and you are worried about blocking multiple users who happen to be sharing the same IP, one approach you could use would be to track the number of login attempts per IP and apply some very moderate (for a human) throttling that would make a brute-force attack prohibitively expensive.

For example, if more than X tries from a given IP address have been attempted in the last second (where X is your estimated number of concurrent login attempts per second from a single IP address) send a 403403 (or better, a 429429) with a message that says something like "Too many attempts have been made recently, please wait a few moments and try again."

This way, it is very unlikely that a human will ever have a problem even if they have a shared IP, while any brute force attack will be limited to X per second, which is hundreds to thousands of times slower than a non-throttled attack.

If you wanted to make it a little more secure without resorting to auto-banning, you could also send an automated email to support whenever the maximum login threshold has been reached an excessive number of times (maybe 100) from a single IP. That way you could inspect the logs and decide for yourself if that particular IP address is worth perma-banning or not.

This approach trades a little security for usability, since we are avoiding captchas or anything else that would slow a human down.

As @Rory said, it depends on your security posture, but if it's not a very high risk site and you are worried about blocking multiple users who happen to be sharing the same IP, one approach you could use would be to track the number of login attempts per IP and apply some very moderate (for a human) throttling that would make a brute-force attack prohibitively expensive.

For example, if more than X tries from a given IP address have been attempted in the last second (where X is your estimated number of concurrent login attempts per second from a single IP address) send a 403 (or better, a 429) with a message that says something like "Too many attempts have been made recently, please wait a few moments and try again."

This way, it is very unlikely that a human will ever have a problem even if they have a shared IP, while any brute force attack will be limited to X per second, which is hundreds to thousands of times slower than a non-throttled attack.

If you wanted to make it a little more secure without resorting to auto-banning, you could also send an automated email to support whenever the maximum login threshold has been reached an excessive number of times (maybe 100) from a single IP. That way you could inspect the logs and decide for yourself if that particular IP address is worth perma-banning or not.

This approach trades a little security for usability, since we are avoiding captchas or anything else that would slow a human down.

As @Rory said, it depends on your security posture, but if it's not a very high risk site and you are worried about blocking multiple users who happen to be sharing the same IP, one approach you could use would be to track the number of login attempts per IP and apply some very moderate (for a human) throttling that would make a brute-force attack prohibitively expensive.

For example, if more than X tries from a given IP address have been attempted in the last second (where X is your estimated number of concurrent login attempts per second from a single IP address) send a 403 (or better, a 429) with a message that says something like "Too many attempts have been made recently, please wait a few moments and try again."

This way, it is very unlikely that a human will ever have a problem even if they have a shared IP, while any brute force attack will be limited to X per second, which is hundreds to thousands of times slower than a non-throttled attack.

If you wanted to make it a little more secure without resorting to auto-banning, you could also send an automated email to support whenever the maximum login threshold has been reached an excessive number of times (maybe 100) from a single IP. That way you could inspect the logs and decide for yourself if that particular IP address is worth perma-banning or not.

This approach trades a little security for usability, since we are avoiding captchas or anything else that would slow a human down.

updated error response codes
Source Link
thomij
  • 241
  • 1
  • 6

As @Rory said, it depends on your security posture, but if it's not a very high risk site and you are worried about blocking multiple users who happen to be sharing the same IP, one approach you could use would be to track the number of login attempts per IP and apply some very moderate (for a human) throttling that would make a brute-force attack prohibitively expensive.

For example, if more than X tries from a given IP address have been attempted in the last second (where X is your estimated number of concurrent login attempts per second from a single IP address) send a 403403 (or better, a 429) with a message that says something like "Too many attempts have been made recently, please wait a few moments and try again."

This way, it is very unlikely that a human will ever have a problem even if they have a shared IP, while any brute force attack will be limited to X per second, which is hundreds to thousands of times slower than a non-throttled attack.

If you wanted to make it a little more secure without resorting to auto-banning, you could also send an automated email to support whenever the maximum login threshold has been reached an excessive number of times (maybe 100) from a single IP. That way you could inspect the logs and decide for yourself if that particular IP address is worth perma-banning or not.

This approach trades a little security for usability, since we are avoiding captchas or anything else that would slow a human down.

As @Rory said, it depends on your security posture, but if it's not a very high risk site and you are worried about blocking multiple users who happen to be sharing the same IP, one approach you could use would be to track the number of login attempts per IP and apply some very moderate (for a human) throttling that would make a brute-force attack prohibitively expensive.

For example, if more than X tries from a given IP address have been attempted in the last second (where X is your estimated number of concurrent login attempts per second from a single IP address) send a 403 with a message that says something like "Too many attempts have been made recently, please wait a few moments and try again."

This way, it is very unlikely that a human will ever have a problem even if they have a shared IP, while any brute force attack will be limited to X per second, which is hundreds to thousands of times slower than a non-throttled attack.

If you wanted to make it a little more secure without resorting to auto-banning, you could also send an automated email to support whenever the maximum login threshold has been reached an excessive number of times (maybe 100) from a single IP. That way you could inspect the logs and decide for yourself if that particular IP address is worth perma-banning or not.

This approach trades a little security for usability, since we are avoiding captchas or anything else that would slow a human down.

As @Rory said, it depends on your security posture, but if it's not a very high risk site and you are worried about blocking multiple users who happen to be sharing the same IP, one approach you could use would be to track the number of login attempts per IP and apply some very moderate (for a human) throttling that would make a brute-force attack prohibitively expensive.

For example, if more than X tries from a given IP address have been attempted in the last second (where X is your estimated number of concurrent login attempts per second from a single IP address) send a 403 (or better, a 429) with a message that says something like "Too many attempts have been made recently, please wait a few moments and try again."

This way, it is very unlikely that a human will ever have a problem even if they have a shared IP, while any brute force attack will be limited to X per second, which is hundreds to thousands of times slower than a non-throttled attack.

If you wanted to make it a little more secure without resorting to auto-banning, you could also send an automated email to support whenever the maximum login threshold has been reached an excessive number of times (maybe 100) from a single IP. That way you could inspect the logs and decide for yourself if that particular IP address is worth perma-banning or not.

This approach trades a little security for usability, since we are avoiding captchas or anything else that would slow a human down.

Source Link
thomij
  • 241
  • 1
  • 6

As @Rory said, it depends on your security posture, but if it's not a very high risk site and you are worried about blocking multiple users who happen to be sharing the same IP, one approach you could use would be to track the number of login attempts per IP and apply some very moderate (for a human) throttling that would make a brute-force attack prohibitively expensive.

For example, if more than X tries from a given IP address have been attempted in the last second (where X is your estimated number of concurrent login attempts per second from a single IP address) send a 403 with a message that says something like "Too many attempts have been made recently, please wait a few moments and try again."

This way, it is very unlikely that a human will ever have a problem even if they have a shared IP, while any brute force attack will be limited to X per second, which is hundreds to thousands of times slower than a non-throttled attack.

If you wanted to make it a little more secure without resorting to auto-banning, you could also send an automated email to support whenever the maximum login threshold has been reached an excessive number of times (maybe 100) from a single IP. That way you could inspect the logs and decide for yourself if that particular IP address is worth perma-banning or not.

This approach trades a little security for usability, since we are avoiding captchas or anything else that would slow a human down.