Timeline for Why are brute-force password-cracking attacks not automatically detected and thwarted?
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 13, 2016 at 7:42 | comment | added | Alexis Wilke | Note that if you get many failing login attempts, even from many variable IP addresses, attempts that do not end up being valid, you can detect such and block all logins for a while. Depending on the type of websites you have that could be more secure than leaving the door open... | |
| Jun 27, 2014 at 15:37 | history | edited | TildalWave | CC BY-SA 3.0 |
Copy edited. Removed meta information (this can be put in comments). IP is a protocol; it is IP addresses that are static, blocked, assigned, bound, resolved, checked, banned, tracked, detected, dynamic, scanned, have different representations, that devices have, etc., not the protocol itself.
|
| S Jun 27, 2014 at 15:36 | history | suggested | Peter Mortensen | CC BY-SA 3.0 |
Copy edited. Removed meta information (this can be put in comments). IP is a protocol; it is IP addresses that are static, blocked, assigned, bound, resolved, checked, banned, tracked, detected, dynamic, scanned, have different representations, that devices have, etc., not the protocol itself.
|
| Jun 27, 2014 at 15:31 | review | Suggested edits | |||
| S Jun 27, 2014 at 15:36 | |||||
| Jun 27, 2014 at 15:13 | comment | added | Shadur-don't-feed-the-AI | But still about an order of magnitude less tries than without fail2ban. Possibly enough to make the difference. | |
| Jun 27, 2014 at 15:09 | comment | added | sixtyfootersdude | @Shadur - That that is probably two tries per IP address per hour, which could still be a lot of tries. | |
| Jun 27, 2014 at 10:03 | comment | added | Shadur-don't-feed-the-AI | In the case of the botnet, assuming you've got something like fail2ban running and each bot only gets two tries before it's locked out for an hour, you're still putting up a decent defense... | |
| Jun 27, 2014 at 7:19 | comment | added | PiTheNumber | I don't like the captcha solution. Maybe just add some delay to the account validation. Increase the delay with the number of failed logins. Also check your user accounts for very simple passwords. Lockout those accounts and send a password change mail. | |
| Jun 27, 2014 at 4:58 | comment | added | ErikE | Even captcha is not the barrier it might seem to be. Put up some desirable resource on the internet, and put it behind a captcha. Only, instead of generating a new captcha, on each page load, just grab a captcha challenge from the site you want to crack. When your own human visitor gives you the answer, use it on the original site. The resources could be game ROMs, MP3 audio files, pornography, or any other downloadable content that people desire. One could even, with a botnet of compromised machines, do a captcha once an hour randomly on the desktop. Captcha is not the end-all answer. | |
| Jun 26, 2014 at 20:23 | comment | added | sixtyfootersdude | @hexafraction I think that any changes that you can do to the login could also be made to the bots. This may buy you some time but it isn't really a reliable security mechanism. Good point on the captcha. | |
| Jun 26, 2014 at 19:33 | comment | added | nanofarad | For the botnet situation, isn't it possible to change the login page/handler just enough so that existing bots cannot authenticate to it without receiving new code from the "master", or, better yet, to require a captcha? | |
| Jun 26, 2014 at 19:11 | history | edited | sixtyfootersdude | CC BY-SA 3.0 |
added 1 character in body
|
| Jun 26, 2014 at 18:57 | history | edited | sixtyfootersdude | CC BY-SA 3.0 |
added 1 character in body
|
| Jun 26, 2014 at 16:34 | review | First posts | |||
| Jun 26, 2014 at 16:35 | |||||
| Jun 26, 2014 at 16:15 | history | answered | sixtyfootersdude | CC BY-SA 3.0 |