Security: Authenticating Identities
Well, I thought maybe its time to geek this blog up again. Its been a long time since I posted anything truly geeky. And I do mean, really geeky.
Today I thought I’d discuss a security topic. Namely, issues around gaining access to a resource. We’ll discuss the 3 things required before an entity can access this resource and also cover things such as multi-factor authentication as well as best practices.
If you’re not a geek, this will hurt. Even if you are a geek, this might be a bit much. Those most interested in this subject are likely to be people in the IT industry in a server or network admin role, or C-level management wanting to learn a little more about this subject for their own environments.
I’ll keep the language English, but where I do speak geek, I’ll try to find links that will help you figure it out.
Now, the first thing I need to point out is that while this is most definitely relevant to network and server security, this also applies to things like access control in buildings and so on. We’re talking about any entity gaining access to a restricted resource. Whether that resource is a shared directory on a server, or the actual server room itself doesn’t change the issue too much. Both require the same 3 principles before that entity can access them.
I use the term entity because we’re not limiting our scope to just people. Software also must be authorised to access information on our network. An automated robot at an airport must be authorised to access a restricted area. So I use the term entity in an effort to widen the scope and have you thinking not just of logging in to the computer on your desk.
In any situation regarding access control, we need to get 3 things from an entity before we can give that entity access to the resource they want to get to. They are quite simply put as…
- Identity
- This is who or what the entity is. Often this might be your username on to the network that you put in the Windows login screen. Or this might be your swipe card to get you through the front door in the morning.
- Authentication
- This is to verify the identity of the entity trying to gain access. Continuing with our analogy above, this would be the password that goes with your username, or the pin that goes with your swipe card.
- Authorisation
- The most important. Once we have the identity and we have verified that it is authentic, we then need to see if that identity has the authority to access the resource. My swipe card might get me into the building, but that may not give me access to the accountants office with the safe in it. Or I might be able to access the server room, the nerve centre of the buildings network, but the accountant may not be able to do so. The accountant is trusted to handle the money, and thus is authorised to be in the room where the safe is. I am trusted to maintain the servers and network equipment and ensure they continue to function, so I have access to the server room.
Identities are extremely important. An identity defines who we are and is the method by which the security system knows us (or knows the software and robot.) However, anyone might be able to claim they are a certain entity. Thus we need to take great measures to ensure that any single identity is authenticated and legitimate.
Policy plays a huge role in this. Using the swipe card example for getting in to doors. If a pin is not required to authenticate that the card is being used by the person it belongs to, then I could borrow the accountants card, gain access to their office and the company safe. I don’t have permission to, but because a pin is not required, if I manage to get the accounts card, the security system will register that the accountant is trying to enter the office and so let them through.
On the other hand, if a pin is required when using the swipe card to enter a door, it becomes a lot harder ‘borrow’ that card to get into the office. I would then need to know the pin code the accountant uses that matches the card. If I enter too many incorrect pin numbers into the system, a flag would be raised and the card would stop working altogether until the issue is investigated.
This is much the same as the Windows system you log in to at work, for example.
Every server platform out there, regardless of whether it is Microsoft Windows, Unix, Linux or MacOS X, provides the ability to limit the number of times someone can incorrectly enter a password before an account gets locked out for a period of time.
For example, you can set a policy that says that if someone enters an incorrect password any number of times in a row, that account is to be locked out of the system for a given period of time. So you could set it to 3 incorrect passwords locks an account for 60 minutes. If the person trying to access the account is the legitimate user, they can speak with an administrator who can verify that person and then unlock the account sooner.
Unfortunately, many companies turn this feature off, or set it to a ridiculously high number of incorrect passwords. Often, those that do set it properly will find that the admins are not verifying users, they’re just getting the phone call and unlocking the account straight away. And again, this comes back to the company policy and how its enforced.
The importance of identity cannot be over-estimated. But the same is also true of authentication.
As mentioned before, a swipe card without a pin number is purely an identity. The security system will associate that particular card with a single entity. That card, to the security system, defines “you.”
So protecting this card and ensuring that no one else can pretend to be you by using this card is important. The most common way is to associate a pin number with the card. Anyone that has used a bank debit card will be familiar with this scenario.
My debit card allows me to go to any store in New Zealand and buy anything I want or need. I hand my card to the person at the till, they swipe my card and I then enter in my pin number. Merely having the card is not enough. The pin number is required to prove that I am the owner of the card.
If I enter in an incorrect pin too many times, the bank will flag my card and make it impossible for me to use that card. I need to go to the bank and get a new card. This requires that I present legally binding I.D. (such as a drivers license or a passport) as well as proof of my address (such as my last power bill.)
If the debit card were like the door swipe card above, anyone that found my card would be able to spend my money. So having the pin there authenticates me.
However, this is not entirely secure. Staying with the bank debit card meme, it is becoming increasingly common for theives to use technology to clone debit and credit cards. This is done by making a duplicate of the information stored on the magnetic stripe on the card. When this is done, they don’t need my pin anymore because they could easily set a pin of their own now.
So we need to take things a little further. Now we start to hit multi-factor authentication.
There are three types of authentication methods.
- Something you know
- Something you have
- Something you are
Something you know could be best described as a password or a pin number. It is something that is in your head. Your mothers maiden name or your first pets name (or any number of other questions like these) are questions many banks use to authenticate you. Its not likely that anyone outside your family will know that information.
Something you have is that mag swipe card we were talking about before. Or it might be an ID of some kind, such as a passport or even your work badge with your photo on it. It might be a digital key-fob of some kind that is constantly scrolling through one time numbers. It is in your possession.
Something you are is best known as biometric information. It could be your finger prints, your retina or even your DNA. Maybe you need to speak a phrase into a microphone after swiping a card to gain access through a door. Thus your voice print becomes part of your authentication. However, at the moment the most common method is a finger print.
Most authentication systems will only use one of those three. The most common being “Something you know” such as a password or a pin. But more and more we’re seeing organisations start to implement multi-factor authentication.
Multi-factor authentication, put simply, is combining any two or more of the 3 methods to validate and authenticate a single identity. Often, this will be combining a password with a fingerprint to authenticate that a given identity is valid.
For example, in my previous example we associated a pin with the swipe card of the accountant in and effort to stop anyone other than the accountant from using that card. But lets say that someone saw the accountant enter the pin as he entered the room one day. That person could now enter the room if they ever got hold of that card. But if we also a second method of authentication, such as a finger print, then it wouldn’t matter who had the card and knew the pin. The finger print is unique.
However, because it is possible to fake a finger print, we still require the pin and the card. This means that even if someone finds a way of faking the accountants finger print, they still need the pin. Or if they have the pin, they still need the finger print.
This is multi-factor authentication. You could swap the pin for two methods of biometrics if you wanted. So combine the card with a finger print and a retina scan. Or a retina scan and a verbal pass-phrase. The requirement is that we use 2 methods to authenticate a single identity.
Once we’ve authenticated that the identity given does belong to the entity giving it, we can then decide what we will allow that entity to do.
Authorisation basically defines permissions. You can do this, but not that. You can enter the server room, but not the accountants office. You can run this program, but not that one. You may access these databases, but not those ones.
In its most basic form, authorisation is simply a Yes/No gate. “Here are my authenticated credentials, may I have access?” This becomes an issue of policy more than anything else. You don’t want to be too liberal in this regard. We definitely don’t want everyone to be able to access the server room. But at the same time, we don’t want to be too restrictive. We’d like people to still be able to get in the front door in the mornings to start work.
When it comes to computer networking, we start to enter a whole new realm of responsibilities. In our fledgling 21st Century society, information has become one of the most important properties available today. Whether it be intellectual property we do not want our competitors to have, or even just the latest marketing reports. For this reason, it is becoming increasingly common for companies to require Multi-factor authentication to access the network. The most common form being a password plus a finger print.
Authorisation comes down to what you want to allow an entity to do based on a given set of credentials. You can also define the level of permission based on the level of authentication.
For example, if a person gives only a password to authenticate their identity, they might be allowed to login to their network account and browse the internet or check email, but they cannot access company documents on parts of the network until after they have also given their finger print.
When it comes to networking, this form of identification takes on a totally separate meaning. This is especially true of users accessing the resources across the internet.
There is a lot more to discuss on this subject, but these are the initial salient points that need to be cleared up first before we start to tackle more specific scenarios and circumstances. I’m of the mind that the next time I discuss security we will start to cover topics related mostly to network and host/computer security and how the principles we’ve discussed here are applied to them.
If there is anything here that is not quite clear, please feel free to comment and we’ll discuss this further.
| Print article | This entry was posted by Steve on 17 August, 2007 at 11:00 pm, and is filed under Uncategorized. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site. |
-
Steve
-
Steve
-
Ian
-
Ian
-
Mike
-
Mike