Infrastructure security is more than just firewalls and security patches. Most IT environments have some type of remote access. VPN, e-mail, and many other services expose your user accounts to the world. This article will focus on how to deal with user accounts of your current and former employees.
Proper password aging policies will naturally take care of old or unused accounts. The idea behind password aging is that after a certain amount of time, a password expires. A password is less prone to compromise if it is changed frequently. Likewise, if an account is compromised, its usefulness will be limited to the amount of time left before the expiry timer concludes. Aging account passwords can reduce exposure if brute-force, social engineering, or sniffing attempts are successful.
The strength of the password itself is also extremely important. It is imperative that the systems requiring users to change their passwords also enforce some level of strictness with regards to what passwords are accepted. An un-guessable password makes brute-force attacks–the premiere method by which accounts are compromised–mostly futile. Given enough time, an exhaustive brute-force attack will eventually discover all passwords, but the idea is to use a password of sufficient length so that it can’t be guessed in a reasonable amount of attempts. The successful guessing attempts normally find extremely trivial passwords, such as ones that are the same as the username. In next week’s article we’ll explore the password strength issue in more detail, when we dispel many myths about password security. For now, just know that password strength is quite important.
Account aging, the disabling of unused accounts, is just as important as having a decent password policy. Unused accounts are probably the second most commonly compromised. If you don’t have a password aging policy, at least be certain to disable old or unused accounts.
Ideally, though, password aging should be your priority. There are a few different ways to implement password aging. The aging of a password will naturally disable unused accounts. A since a user must login to be given notice that their password has expired, and if they fail to do so within a certain amount of time, the account itself can be disabled. The question is then, “how do we implement this enterprise-wide?”
In practical terms, Windows Active Directory and various Unix-based LDAP servers support the setting of password policies. Unfortunately, simply enabling password expiry will be problematic. Services that use LDAP may not implement the necessary “goo” to talk about expired accounts. They simply get an authentication failure, and the user won’t know why. This also happens with Active Directory, for example a VPN user will not be able to authenticate with an expired password until they first login to an actual Windows machine and set a new password.
There are two viable solutions. Well, one that “works,” and one that is truly viable. It would work to require that all systems that authenticate users implement password aging. Each system would have to keep track of these policies, possibly previously used passwords, and of course they would have to implement the mechanism by which a user can be notified and subsequently change their password. Not likely.
The only viable solution, then, is to use a central authentication system. CAS, a central authentication system for Web-based applications, is the ideal solution. CAS is extremely popular, and it provides an extremely effective and secure method by which users can be centrally authenticated, complete with a method to support changing passwords on expired accounts.
Kerberos-based services like AD in Windows or a Kerberos-enabled LDAP server in Unix provide authentication for workstations and other site-local applications, but with the drawbacks previously mentioned.
Interestingly enough, it should be noted that improving security through account aging requires central authentication, which provides the added benefit of single sign-on. Now, don’t forget that single sign-on can mean two things: having the same password everywhere, or using a “ticket” (or cookie, when talking about Web applications) to only need to sign on to one service, but gain access to many. Synchronizing passwords between services isn’t usually done for security reasons; instead it’s for user convenience. In the rare instances where a password change on one system, not a central system, propagates to all others, it is possible to implement a password aging policy. Generally, these types of setups are organically grown because a diverse set of applications don’t support a coherent set of protocols, and password aging is impossible.
As contrary as it may sound, central authentication is the only way to ensure proper security. Administrators can instantly disable access to all services at the same time with central authentication, and they can also ensure that password policies are enforced. The fact that a user is supplying the same password for all services isn’t as much of a concern as one might think. Indeed, there will always be multiple levels of security requirements. The most critical and secure financial systems, for example, can still be kept separate to alleviate concerns about a password compromise, but only if it also implements appropriate password strictness and aging policies.
Finally, be sure to pay close attention to how your chosen systems will handle passwords set before your change in policy. Some systems may continue to allow old users with weak password to continue using them after you’ve turned on password complexity requirements. Likewise, be sure to verify that new aging policies apply to all existing user accounts, not just new ones.
Properly managed accounts, that is, accounts that are automatically disabled after too much idle time, will shut down the main vehicle of attack used today. Of course, disabling ex-employee accounts is just as important. Leaving an account open so that people can have access to an ex-employee’s e-mail is risky, and should be carefully considered. It’s generally best to make a copy of all existing e-mail, and then configure an e-mail forward to their supervisor. Combine constant user education about social engineering tactics, sysadmin education about security best practices, and vigilance in account policies; now your enterprise can be much more secure and easier to manage.