In this module, we'll cover the three A's of security, which are authentication, authorization, and accounting. We'll cover exactly what they are, how they relate to each other, and their common implementations and protocols. Let's kick things off with authentication, and by extension identification. You should be familiar with authentication in the form of username and password problems when accessing things like your email. So let's take that as an example to show the differences between identification and authentication. Identification is the idea of describing an entity uniquely. For example, your email address is your identity when logging into your email. But how do you go about proving you are who you claim to be? That's the process we call authentication. When accessing your email, you're claiming to be your email address, and you'd supply a password associated with the identity to prove it's you, or at least you know the password associated with the e-mail account. Pretty straightforward, right? This is distinctly different from authorization, which pertains to the resources and identity has access to. These two concepts are usually distinguished from each other in the security world, with the terms authn for authentication and authz for authorization. In our e-mail account login example, by authenticating using your email address and password, your identity is authorized to access your email inbox, but you're not authorized to access anyone else's inbox. We really don't want anyone else getting access to our inbox, right? So what can we do to ensure that only we are able to identify and authenticate as our e-mail account? We could start by ensuring that we're using a strong password. But what exactly constitutes a strong password? Well, what do you think of the password ponies? Would you categorize that as a strong password? I hope not. That password is super short, and only six characters, and all of those characters are lowercase letters. This is a short and simple password, but that could be easily broken through brute force or dictionary based attacks. Ponies would almost definitely be in a dictionary file, and six characters doesn't provide a large pool of possibilities for an attacker to try. We can ensure a password is strong by making it longer and more complex, adding numbers, uppercase letters, and special characters like punctuation. What do you think of the strength of this password? That seems way more secure, doesn't it? It adds complexity, which increases the pool of possible passwords, and is longer at 10 characters. But which of these two passwords do you think you would be able to remember tomorrow? Probably not the strong one, right? This highlights a super important concept in security. There's often a trade-off between security and usability. With our password example, the more usable password that's easy to memorize is less secure, while the more secure password is much more challenging to remember. This concept applies to many other security subjects, not just passwords. You can think of security as risk mitigation, and when it comes to risk mitigation, it's impossible to completely eliminate the risk. The best you can do is understand the risks your systems face, take measures to reduce those risks, and monitor them. Think about it like this, the most secure computer system is one that's disconnected from everything, including networking, and even power and is locked in a concrete bunker hundreds of feet underground that no one has access to. While this is incredibly secure machine, almost impossible to compromise, it's basically useless since it's powered off and no one can access it. This is an extreme example of the security versus usability trade-off, but you get the point. Coming back to our password example, we obviously need to find some sort of happy medium, but where we have a reasonably secure password that's also somewhat easy to memorize. How about something like this. We start with a short phrase, Ilikeponies, then replace some letters with numbers that resemble the letters to help with memorization. We also swapped the S with the Z since they're similar sounding and tacked on some numbers as a suffix. At first glance, this seems like a very complex password and will be hard to memorize, but it's easier than a random password example. Problem solved, right? Well, you should actually be wary of this number substitution process, since it's well-known by attackers and password cracking tools. As an I.T. support specialist, ensuring that your organization uses strong passwords and practices, good password hygiene are super important. They're literally the keys to the kingdom. So what should we do? Incorporating good password policies into an organization is key to ensuring that employees are securing their accounts with strong passwords. A good password policy system would enforce length requirements, character complexity, and check for the presence of dictionary words, which would undermine the strength of passwords. Passwords should never be written down or recorded in plain text, reused across accounts or be shared with anyone. Password reuse is a risk because in the event the password for one account is compromised, other accounts using the same password would also be at risk. Sharing passwords should also be a no go, since this undermines the identity of an account because someone else now has the ability to log in as that user. Along with requiring the use of strong passwords, a password rotation policy is also recommended, since it safeguards against potential undetected compromised passwords. But it's important that a password rotation period isn't too short. Why? The inconvenience of having to change passwords so often may actually encourage poor security behavior by users. So let's say you required your organization to create highly complex passwords and to change them every three months. It's very likely that a significant percentage of users would write down their passwords on post-it notes or on their phones. A big no no. Despite the policy being designed to increase security, it actually has the opposite effect because of the inconvenience it causes your users.
