All of the feedback here seems valid. Security Assist does a good job of making sure someone needs to enter a username and password before accessing a page that is secured with SecurityAssist code.
However if you have database update pages that aren't secured, have sql injection holes on pages that aren't secured, or if someone gets a hold of a username and password in some other way there isn't much security assist can do.
I worked with the user that reported this issue directly today. I showed him how to use SecurityAssist for IP blocking, discussed how to add UserID fields to his database so that if someone uses a web page you know what user it was and therefor what account has been compromised, and suggested adding google analytics to the admin section so that if it does happen again he will know what user account they logged in with and can track their path and page views to see if SQL injection attempts were made. I also suggested making passwords so that they contain numbers and special characters so that a reverse lookup couldn't be used to determine the password from the encrypted string.
We never found the actual security hole, but based on what we found it appears that someone logged in. So what we don't know is whose account they used, or how they got the login information to begin with, but following my suggestions should help prevent it and/or track down the issue better if it happens again. I also suggested forcing admins to update their passwords and backing up the database often since we weren't able to necessarily correct the problem.