Information Security
service-account
Updated Sat, 09 Jul 2022 04:29:06 GMT

Should service accounts be set to never lock out


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?




Solution

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)




Comments (2)

  • +1 – This pretty much coincides with my argument, though the security team will keep their policy as is. Thanks Tom. — Apr 15, 2014 at 21:06  
  • +0 – 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. — Feb 21, 2016 at 18:11