uid 1 not being blocked
| Project: | Login Security |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
No prevention of Admin lockout?
If the coders already accomodated this and perhaps I missed the documentation somewhere then please disregard this. I don't see anywhere any indication that there is prevention from locking out the admin account. If anyone is trying a brute force they would know that the default administrator login to drupal is 'admin' which is typically in general. If this module is set to lock out an account after x # of attempts then someone could simply lock out an administrator by repeatedly trying to log in until they hit the threshold and the Admin would be SOL at that point.
Based on the existing documentation that is exactly what will happen unless there is information I missed somewhere that there is a failsafe to prevent this from happening. Until I hear otherwise I will only be using the progressively increasing time to log in option which is better than nothing and no chance of locking out the admin account permanently.
#1
I'm not sure if I did understand your question, but this is I guess the first answer I could provide you.
Please, go to Login Security, sneak out the documentation link (look for "Resources: Read Documentation") that is located here. Browse that handbook page untill you reach the "Block account" description. Probably you will realize there is a big bolded sentence: "Note: the user with uid 1 can not be blocked.". Additionally, the sentence just suggests: "I strongly recommend you to not name it admin/administrator/adminuser or any other 'admin' related name.".
Actually, the user with uid 1 is not being blocked because it is too exposed. If you want to protect that user from being bruteforce, the first thing to do is to avoid showing its username, but as you said, admin is the most common option most of the times. So, in any case, the uid 1 will never be blocked, and it does not mean "not protected".
If you read carefully the module documentation you will find other notices and protections that may efectively protect that and the rest of users. Setting a right threshold for being advised with "ongoing attack" behaviours will notify you about password guessing operations. Setting up the "Increase delay" (as you did) would help you also reducing password guessing operations. Setting a good "host soft blocking protection" would stop password guessing operations without blocking any user. Please, don't be stucked in the delay protection, and find the one you are looking for.
By the way: "If this module is set to lock out an account after x # of attempts then someone could simply lock out an administrator by repeatedly trying to log in until they hit the threshold and the Admin would be SOL at that point." Don't you think this should be the expected behaviour, because user admin should be protected also? It was not introduced in the module because people was not instructed to protect the admins username.
Now, close your fingers, count to ten, and wait for someone putting the request in the issue: "I've changed username of uid 1, now, I would like this user to be protected", as I do..
I guess the issue title is incorrect, just fixing. I'll write something about this in the README.txt file, I guess that was your only doc source, and there's nothing about the topic in that file, but this issue will be used to make the option of uid 1 being blocked configurable for the site administrator.
Thanks for your submission, I hope you could find your answer :)