OSCommerce Product Manager

OSCommerce Product Manager for Windows
Tasklist

FS#339 - Brute-force attack (password guessing) detection and blocking...

Attached to Project: OSCommerce Product Manager
Opened by Mario A. Valdez-Ramirez (mvaldez) - Monday, 14 May 2007, 07:12 GMT-6
Last edited by Mario A. Valdez-Ramirez (mvaldez) - Friday, 01 June 2007, 11:05 GMT-6
Task Type Bug Report
Category Backend / Core
Status Closed
Assigned To Mario A. Valdez-Ramirez (mvaldez)
Operating System All
Severity Very Low
Priority Immediate
Reported Version any
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

As stated in Bug #301: "As the user most likelly will not change the password that often, we can add a brute-attack detection feature, so the script is blocked for a certain amount of time and for an IP address if it receives too many failed login attempts from that IP address. That should be a different feature request."...

The server-side script should detect and stop brute-force attacks that try to guess the password.

Pending to see what database table to use for temporary storage, but we should not create new tables for this.

This bug is related to Bug #301.
This task depends upon

Closed by  Mario A. Valdez-Ramirez (mvaldez)
Friday, 01 June 2007, 11:05 GMT-6
Reason for closing:  
Comment by Mario A. Valdez-Ramirez (mvaldez) - Tuesday, 15 May 2007, 01:42 GMT-6
After evaluating this feature request, I think it is very important.

Raising its severity to Critical, like all important security issues.

Comment by Mario A. Valdez-Ramirez (mvaldez) - Tuesday, 15 May 2007, 02:48 GMT-6
We can use the sessions table or the whos_online table.

Pending to check if:
* sessions is available even if the user had selected to use file-based sessions storage,
* if we populate whos_online with invalid data what happen to all the stats.

Comment by Mario A. Valdez-Ramirez (mvaldez) - Tuesday, 15 May 2007, 04:36 GMT-6
Closing as Implemented.

We use the whois_online database table to store the tracking information for each IP address attempting to connect. By default, the script will allow eight login attempts, forcing a delay of 15 seconds between logins after the first failure; after those eight failures, it will block the IP address for one hour. The tracking information is kept for five minutes, except for blocked clients, which are followed for one hour.

Those parameters are configurable.

So, in a brute force (dictionary / cracking) attack to guess the password, each IP address can only try 20 passwords per hour without being blocked. If the client tries to login without throttle, it will only be able to try 8 passwords per hour (as it will be blocked).
Comment by Mario A. Valdez-Ramirez (mvaldez) - Tuesday, 15 May 2007, 04:47 GMT-6
Correction: the tracking time are not five minutes, but fifteen minutes. So...

...in a brute force (dictionary / cracking) attack to guess the password, each IP address can only try 4 passwords per hour without being blocked (as it is tracked for 15 minutes). If the client tries to login without throttle, it will only be able to try 8 passwords per hour (as it will be blocked and then tracked for one hour).

Loading...