Sign in to follow this  
Followers 0
shasdf

Account Lockout Policy: Friend or Foe for Admins

8 posts in this topic

I was listening to something from one of Microsoft's security folks, and he had said something like, "Turn off account lockout policy, all it does is generate help desk calls to unlock accounts." I imagine that his thought process is that most hackers arent going to brute force a user account and would rather just attack an exploit. I also assume that he is referring to controlling a windows box at system level and having close to direct access to the password hashes as well.

Whats your opinion? Is plain old brute forcing dead? Are there any other useless policies that generate more administration than necessary?

0

Share this post


Link to post
Share on other sites

Brute forcing isn't dead. Note that I also include dictionary attacks with and without mofication rules in this. It's definitely an effective tactic in situations where non-security-conscious people have the ability to set their own passwords. You'd be surprised how effective a dictionary attack with modifications/additions of numbers and letters is against a lot of admins even.

That said, I would only recommend account lock-out in very specific situations and with some caveats. I would prefer to have enough intelligence (such as an IDS) in place on the network to be able to alert when many connections are being made consistent with brute forcing behavior. That way, you can detect and stop brute-force attempts, and not inconvenience the users. If this isn't possible, then I think that locking an account for a short time period before allowing more attempts is a good compromise. Even as short of a delay as 5 to 10 minutes makes a brute force attack completely unfeasible, and yet isn't that bad of an inconvenience for the users. I've noticed that these forums have a timed lockout on them, for example.

Note that the three main tenets of security are availability, confidentiality, and data integrity. If, in the process of attacking your organization, I realize that you are locking out accounts when I try to log in too many times, then I have stumbled upon a way to bring work to a screeching halt there. It's very likely that I could use the ensuing chaos to my benefit as well, if in no other way than social engineering ("Hello, I'm with helpdesk. It seems your account as been locked out. Seems to be a widespread problem. Allow me to help you get things back to normal...").

To answer you other question... Other useless policies? There's a lot of policies that are useless when implemented poorly (see above). Another that sticks out in my mind right now is forcing password changes every X months. This is a a really good idea, however it's useless without very password complexity policies, and checks put in place to prevent people from "cycling" between two (or more) passwords every time the change date comes along. It's also a good way to drive people to writing down passwords on post-its, which you'll have to step up enforcement against as well. It's not a useless policy (most policies do have some use), it's just not implemented correctly in a lot of situations.

0

Share this post


Link to post
Share on other sites
It's also a good way to drive people to writing down passwords on post-its, which you'll have to step up enforcement against as well.

Not really, say that my password is meade12, all I have to remember is "meade" and that this is the twelfth time that I've had to change my password.

0

Share this post


Link to post
Share on other sites
It's also a good way to drive people to writing down passwords on post-its, which you'll have to step up enforcement against as well.

Not really, say that my password is meade12, all I have to remember is "meade" and that this is the twelfth time that I've had to change my password.

That's precisely an example of a security police bad implemented. Let's start with the fact that the password, as you put it, doesn't enforce the use of a good security policie, there are no complex format for the password, one of the problems relating to passwords is the use of easy-to-remember password and is because is breakable during a brute force or dictionary attack.

On the other hand, if someone have been able to watch the system's security for something, keep a record of it and is able to break someone's password, using an increment police (x1 because is the first time I use this password, x2 because is the second time I'm changing the password, and so on) will put system's security in future danger, it will be better in that case use random numbers. One important thing that people should realize is that password change can't show relation with previous used passwords.

Regards

0

Share this post


Link to post
Share on other sites
It's also a good way to drive people to writing down passwords on post-its, which you'll have to step up enforcement against as well.

Well I think problems like this can be easily be cured with user training. We techie folks are always focused on the technical side but i am not going to run around desks and start flipping out on people.

Users are the biggest threat to an organization because they can invite so much bad things in without common knowledge. They dont care that the AD structure is using IP-sec for secure communication, they just want to do their job. To mitigate poor passwords of increments or barely meeting standards, Encourage them to write it down BUT keep it somewhere safe. I cant remember half of my passwords because i cant remember $%k3sL@1aks. Its so easy to start slacking on simple security when it becomes tedious and half the time impossible without forgetting something else.

Users dont understand why poop23 is a bad password, how easy it is to guess, and what could happen because it was guessed. I am a firm believer that if users understood the dangers, they would help you more than undermine you/sec policies.

0

Share this post


Link to post
Share on other sites
It's also a good way to drive people to writing down passwords on post-its, which you'll have to step up enforcement against as well.

Not really, say that my password is meade12, all I have to remember is "meade" and that this is the twelfth time that I've had to change my password.

That's precisely an example of a security police bad implemented. Let's start with the fact that the password, as you put it, doesn't enforce the use of a good security policie, there are no complex format for the password, one of the problems relating to passwords is the use of easy-to-remember password and is because is breakable during a brute force or dictionary attack.

On the other hand, if someone have been able to watch the system's security for something, keep a record of it and is able to break someone's password, using an increment police (x1 because is the first time I use this password, x2 because is the second time I'm changing the password, and so on) will put system's security in future danger, it will be better in that case use random numbers. One important thing that people should realize is that password change can't show relation with previous used passwords.

Regards

You can do this in every security policy of every fortune 100 company and government agency that I've ever worked for. Might not be ideal but it's the norm. Obviously meade1 would not match password policy, but you can still increment passwords. I don't think any enterprise-worthy LDAP implementations even have a feature that would protect against it. My radius experience lies completely in tacacs and steel-belted (but that's what everyone uses anyway), and you can't prevent it there either.

0

Share this post


Link to post
Share on other sites
It's also a good way to drive people to writing down passwords on post-its, which you'll have to step up enforcement against as well.

Well I think problems like this can be easily be cured with user training. We techie folks are always focused on the technical side but i am not going to run around desks and start flipping out on people.

Users are the biggest threat to an organization because they can invite so much bad things in without common knowledge. They dont care that the AD structure is using IP-sec for secure communication, they just want to do their job. To mitigate poor passwords of increments or barely meeting standards, Encourage them to write it down BUT keep it somewhere safe. I cant remember half of my passwords because i cant remember $%k3sL@1aks. Its so easy to start slacking on simple security when it becomes tedious and half the time impossible without forgetting something else.

Users dont understand why poop23 is a bad password, how easy it is to guess, and what could happen because it was guessed. I am a firm believer that if users understood the dangers, they would help you more than undermine you/sec policies.

User training might work in theory but it's a stinking pile of shit in the real world in any sizable organization. It's not that they don't know, it's that they just don't care.

The only answer is two-factor.

0

Share this post


Link to post
Share on other sites
That said, I would only recommend account lock-out in very specific situations and with some caveats. I would prefer to have enough intelligence (such as an IDS) in place on the network to be able to alert when many connections are being made consistent with brute forcing behavior. That way, you can detect and stop brute-force attempts, and not inconvenience the users. If this isn't possible, then I think that locking an account for a short time period before allowing more attempts is a good compromise. Even as short of a delay as 5 to 10 minutes makes a brute force attack completely unfeasible, and yet isn't that bad of an inconvenience for the users. I've noticed that these forums have a timed lockout on them, for example.

Exactly the point. Admins tend to be excessive when it comes to policies, using the general 'click all security options' method rather than evaluating what is the roll out of defense or what levels of compromise is possible. Some brute force tools allow you to gauge lockout's however think of what was mentioned above in a minute value. 1 minute per every 5 tries. A decent brute force is going to be fairly lengthy as it is, so expect that number to triple with the lockout pause. It isn't common to see attacks like this for this very reason of not wanting to wait that long for results.

On another note however most places do not implement proper IDS or firewall logging so they never know when they are being attacked, they just assume the projection condom is up and it ain't gonna break.

0

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  
Followers 0