I have been thinking about this for some time, during a brute force attack the audit logs may be full of login attempts that will (as you explained) hide relevant information from other events. I will add an option in the settings page to filter out the failed login attempts from the audit logs, that may help.
That would be perfect. If you could have all the filters and uncheck to hide it would be ideal.
We have decided to keep the code as it is and improve the pagination instead. Analyzing the logs without retrieving all of them is (technically speaking) impossible with the performance that most hosting services provide in their PHP installations. My co-workers agree that implementing this change will be helpful but this is not a priority right now.
With commit ac6fcd4 [1] I added a new panel in the “Last Logins” page to allow admins to block specific usernames from trying to log into the website, this will help you reduce the number of failed logins and consequently reduce the size of the audit logs.
And with commit [2] I refactored the code that powers the audit logs panel to load its content via Ajax, improved the pagination, and reduce the latency of the HTTP requests.
Feel free to download the development version of the code from here [3] if you want to test the changes now, or wait until we release the new public version via WordPress.
[1] https://github.com/cixtor/sucuri-wordpress-plugin/commit/ac6fcd4
[2] https://github.com/cixtor/sucuri-wordpress-plugin/commit/34e9f02
[3] https://github.com/cixtor/sucuri-wordpress-plugin/archive/master.zip
