Security101AuthenticationP1_SQWelcome back to our Beginning Security series. In this post, we’re going to look at the first of the three As: Authentication. The three As collectively are authentication, authorization and accounting, and we will look at the next two in order, but before we can let someone do something, or log what they are doing, we need to know who they are, and that is what authentication is all about. Wikipedia defines authentication as “the act of confirming the truth of an attribute of a single piece of data (datum) or entity. In contrast with identification which refers to the act of stating or otherwise indicating a claim purportedly attesting to a person or thing’s identity, authentication is the process of actually confirming that identity.” We’re just going to focus on authentication as confirming a user.

What is authentication?

One of the fundamental tenants of authentication is that every single user has their own unique user account, and that the full details of that account, including what is needed to use that account, are known only to the users. In other words, no one should share accounts, and everyone should keep their password secret. Whether to the local machine or a network resource, the act of authentication is intended to ensure that a user is who they purport to be, and that you can easily determine who did what because actions are logged to the individual. If you and I share an account, then there is no way to determine which one of us did something. If I know your password, I could log on as you, do bad things, and then the logs would implicate you. Sharing accounts is a bad thing.

What makes for good authentication?

In all systems, users have accounts that must be populated with some minimum amount of information so that an admin can associate the account with an individual The username can refer to any number of attributes, but should uniquely identify the person using the account, or the service/process when it’s a service account. In Windows networks, the username is a catchall, because users can use their sAMAccountName (SAM) or UserPrincipalName (UPN,) and in some cases, even their distinguished name (DN) to start the authentication process. In Linux, an account typically has a username, but can also be referenced by a user ID (UID.) Some admins like to use usernames that are easy/intuitive for users, and often may align with their email address. It’s common practice in Windows networks to make the UPN and the email address match, since that makes it very easy for users to remember it. Of course, that also makes it very easy for attackers to discover it, so other admins may assign different values, or even random numbers.

What should you use for usernames?

Whatever you use for a username, it’s important that users can remember it, and that the scheme you choose accommodates users with the same or similar names. If you like firstinitiallastname, then John Smith and Jane Smith will need something to distinguish between them.

What about passwords?

The second part of authentication is some shared secret known/accessible only to the user and the authentication system. This is most commonly a password, but can be one of many other things. Passwords should be longer, use a variety of characters like UPPERCASE, lowercase, numbers, and punctuation, and be changed often. They should never be written down or shared, and if you must reset a user’s password, you should set the flag to force them to change it at next logon so you will not have knowledge of their password going forward. Random strings may be mathematically strong, but are difficult for users to remember and will lead to them being written down. Teach your users how to use passphrases or other tricks to create a password that is both complex, and easy for them to remember.

For UPNs, match your email address. Yes, that means outsiders will know what your users’ usernames are, but with strong passwords and/or 2FA, this is less concerning, it makes things much easier for users, and it will provide maximum compatibility with hosted services and federated authentication. There are also some companies that have internal UPNs ending in .local or other internal-only name space, and while they are heavily resistant to changing this, they all tend to do so once they want to use apps provided by external providers while still keeping authentication internal.

What are factors?

When we discuss authentication, we talk about factors, but don’t count the username. Single factor authentication is typically a password. Two-factor Authentication (2FA) uses something other than just a password, and usually incorporates something physical that a user possesses, like a smart card, certificate, physical token, app on a mobile device, a one-time password (OTP) texted to your cellphone, or biometrics. It can also be referred to as multi-factor authentication (MFA.) When we refer to factors, we often use this nomenclature.

  • Something you know=password
  • Something you have=physical second form of authentication, like a smartcard or physical token, which is usually used in combination with a personal identification number (PIN.)
  • Something you are=biometric factors, like a fingerprint, palm reader, retina scanner, voice recognition, etc.

Most companies still use single factor (password) because of costs and legacy incompatibilities with 2FA, but we will see this shift as more legacy apps are either deprecated or published through application presentation methods that can support 2FA methods. Given the prevalence of smartcards within governments, military organizations, and larger enterprises, smart cards are a proven technology. Lots of vendors make them, and they are so widely deployed anyone who wants to work with governments is going to have to support them.

What is SSO?

One thing that many admins want is single sign-on (SSO.) With SSO the general idea is that once you log onto the workstation, you should not be prompted for authentication to any other system. In a Windows network, integrated authentication makes this possible when apps and resources belong to your domain, but this is much harder to achieve when a company outsources applications, services, or infrastructure to an outside provider. Same sign-on is the process of using the same credentials to access these apps as you use to log onto the workstation, but is a poor substitute for true SSO. Here, a decision must be made between the conveniences of SSO for users, versus the costs/capacities/capabilities provided by the external provider. Users may grumble, but the business will usually opt for the extra logon.

Whatever scheme you use for usernames and what factors you use for the shared secret, users must authenticate to systems before authorization decisions can be made. In our next post, we will look at how authentication actually takes place and the various schemes used. See you next time.