protecting authenticationWelcome back to our third instalment on authentication in the Security 101 series. If you haven’t already, you can read part one that introduces authentication and part two which discusses authentication protocols and methods. In part three, we’re going to discuss protecting authentication.

Authentication is critical, as it helps to determine who is and who isn’t a valid user so that authorization can take place. It also helps to identify actions to a specific individual. Even unprivileged users’ authentication is critical because many attacks these days involve privilege escalation. An unprivileged user, guest account or simple test account can act as a foothold to give an attacker a way in. The bottom line is, it’s critical to protect all authentication.

Unique credentials per user

Let’s start with what should seem obvious but is often overlooked. Each and every user should have their own, unique, set of credentials that is known only to them. There should never be a master admin account that is used by several SysAdmins, and every time an admin must unlock or reset an end user’s account, they need to set a temp password that must be changed at next logon. This can be harder to manage, but I recommend not even using the same initial password for new users, as that is something a lot of people are going to know and could be used with a new hire’s account before the day they start.


Ensure that users’ passwords are complex with a mixture of uppercase, lowercase, numbers, letters and with a certain minimum length. However, never set a maximum length or require that a password starts or ends with a particular character type. Forcing complexity and length makes it exponentially more difficult to brute-force. Setting a specific pattern makes it much easier to crack and harder for users to remember.

Frequent changes

Passwords should be changed often.

Unique credentials per system

For domain based systems, using the same credentials for everything on the domain may make sense, but for remote systems, personal email accounts, shopping accounts, credit card and banking sites, social networks, etc. you will need to use a unique set of credentials for every system. You may want to use your email address (or you may not be given a choice!) but use a different password on each site as it’s very common for attackers to break into one system and then use the stolen credentials to gain access to others. This is where a third party password manager will come in useful.

Separate administrative credentials by system/purpose

Don’t use the same admin account that you administer the domain with for remotely troubleshooting workstations. Pass-the-hash attacks count on grabbing admin credentials from a user’s workstation so that they can be used on key systems. If you have a workstation admin account that is different from your server admin account, the worst an attacker could do is exploit other workstations if they successfully execute a PTH attack. That’s bad, sure, but it’s not as bad as if they got a true domain admin account or could get onto core line of business servers.

Encryption in transit

Cleartext? Just say no! Everything that is sensitive enough to require credentials must use encryption and should use the most recent/strongest available. If you admin systems, you should disable weaker encryption protocols and ciphers on your servers and the workstations you manage. SSL 3 and TLS 1.0 should both be considered insecure.

Certificate and validation

Always secure customer-facing sites with certificates issued by a major public CA. Always use 2048 bit certificates and consider purchasing extended validation certificates if your competition does too. Public perception is important! Never use self-signed certificates for anything end users will access, as the very last thing you ever want to train a user to do is click through a certificate warning! Ensure that all clients can perform certificate validation against CRLs and OCSP endpoints.

Multifactor authentication

The best defense against stolen or guessed credentials is to use multi-factor authentication. Whether you use tokens, smartcards, certificates, phone calls, or something else, make sure users must authenticate with something they know, like a PIN, and something they have, like a physical object. This will greatly reduce an attacker’s ability to compromise credentials.

Encryption at rest

Never store credentials in cleartext. Never store credentials in cleartext. Whether you’re using a flat file, a database, a password manager or an LDAP service, never store credentials in cleartext.

Disable stale accounts

Parse your systems at least once a month and disable any accounts that haven’t been logged into at least 30 days. For customer-facing systems, you may want to extend that to a year – but whatever the period is, unused accounts are low-hanging fruit for attackers to use.

Delete dead accounts

If you know a user is no longer employed with the company or a customer has closed their account delete those dead accounts. For stale accounts that you disabled, follow up after another 30 to 60 days after you disabled them and declare them dead, so they are not lying around cluttering up your database.

No legacy protocols

Disable old legacy protocols like LANMAN and NTLM and ensure that all LDAP is encrypted. Legacy protocols can be easily intercepted and decrypted, leaving your systems at risk.

If you follow the above tips, you will greatly reduce the risk to your systems from compromised credentials, and help protect yourself online with all of your personal sites, services and social networking too.