7

I have been in a discussion lately with our security team, and I want to get an answer from this group.

Currently our security policy states that domain accounts will lock out after 5 failed attempts. This goes for all domain accounts, including service accounts. To be clear, I refer to a service account as an account used by applications to authenticate and "run" as that user.

I see a big problem with allowing service accounts to lockout, it creates an easy DoS for that service. Any rogue employee who knows the account, can simply fail 5 login attempts and the service will stop as it can no longer communicate with databases, and other servers. I have locked out accounts setting up a new server and having an extra space at the end of the password.

I ask, given the risks, why should service account be allowed to lock out after x number of failed logins?

Brettski
  • 521
  • 3
  • 8
  • 14

2 Answers2

9

The automatic locking is a defence mechanism against online dictionary attacks: the attacker wants to try potential passwords, repeatedly, until he finds the right one. Blocking after 5 attempts prevents the attack from actually working.

This makes sense only if the password is vulnerable to a dictionary attack, i.e. if the password was generated in the privacy of a human brain. Such biological entities are simply not good at being random. So human-chosen passwords are not strong, and require extra protection.

A service account should not have a weak password, chosen by a human. Such a password is entered only during configuration phases, by administrators, who will not have to remember it. A service account password should be generated with a computer, and be fatly random. With 16 random characters (uppercase and lowercase letters, digits, and a couple punctuation signs), you will have 96 bits of entropy, way more than enough to resist dictionary attacks. This is the kind of password that your service accounts should have. If you use such passwords, then the automatic locking becomes useless, and you can deactivate it, since (as you discovered) it has some inconvenient side-effects.

To generate such a random password, use the following command line on any Linux machine:

(dd if=/dev/urandom bs=12 count=1 2>/dev/null) | openssl base64 -a -e

On Windows, use PowerShell:

$rng = New-Object System.Security.Cryptography.RNGCryptoServiceProvider
$buf = New-Object byte[] 12
$rng.GetBytes($buf)
[System.Convert]::ToBase64String($buf)
Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • 1
    This pretty much coincides with my argument, though the security team will keep their policy as is. Thanks Tom. – Brettski Apr 15 '14 at 21:06
  • This is a perfect answer because it recognizes the limitations of humans, which are by far the biggest issue with security. Keep pressure on your security team. – Tom Harrison Jr Feb 21 '16 at 18:11
0

I think the benefits outweigh the irritation of a user getting locked out. Yes a rogue employee can DoS you, but now you have a problem you can handle. You need to find this rogue employee and give him a good talk. That's a lot better than the rogue employee brute forcing weak passwords. If you are having an issue with being locked out with 5 attempts push it to 10. The number is low enough that it shouldn't benefit brute forcing much.

user36976
  • 3,233
  • 4
  • 14
  • 22
Krtko
  • 121
  • 1
  • That is a good point. Though with proper monitoring on the AD server, couldn't the brute attack be recognized and alerted on? – Brettski Apr 14 '14 at 18:03
  • I guess a lockout number higher than IIS's App Pool logon retry number could work. A lockout of 30 or so is still not a brute attack risk. The passwords are long, random alpha-numeric. – Brettski Apr 14 '14 at 18:06
  • I don't see any benefits for service accounts, you just need to configure them to use a strong password. So IMO the DoS risk outweighs the minimal benefits. – CodesInChaos Apr 14 '14 at 18:12