We use many different technologies during the authentication process. In this video, you’ll learn about directory services, federation, attestation, and more.
<< Previous Video: Automation and Scripting Next: Biometrics >>
Many operating systems will use a feature known as directory services. This is a central database that stores usernames, passwords, computers, printers, and other devices that might be connected to the network. This database is distributed across multiple devices, and those databases will communicate to each other, and send replication data so that every database is always up to date with the latest information.
This means that when a user needs to access the network, they simply use their single username and password, and those credentials are checked against this directory services’ database. The users only need to remember this single authentication method, and that single method generally gives you access to all of the resources you need on that network.
One of the most common directory services in use is Microsoft’s Active Directory. We commonly use the Kerberos protocol or LDAP to be able to access that database from an external device. Instead of maintaining your own database of usernames and passwords, you can use authentication information that’s already contained at a different site. This is called Federation. And it’s a way that you can allow someone to authenticate to your network, using credentials that are stored with a third party.
To enable this Federation, you would need to coordinate the authentication and authorization process between your organization, and the third party that’s providing these credentials. But once that process is complete, someone can log in with that third-party username and password. So you can present a login page that will allow someone to log in with their Twitter account, their Facebook account, their LinkedIn account, or others.
Once that trust relationship is in place with the third party, your users can simply choose the authentication type that works best for them, and use those credentials to gain access to your network.
These days users can be located anywhere in the world, and they’re often using a VPN or some other type of connectivity to gain access to our local network. As security professionals, we want to be sure that our users are connecting to our network, using the hardware that we provided to them.
We don’t want them to use a piece of third-party hardware and software, to be able to gain access to our internal network. To be able to prove that the hardware that they’re connecting with is really the hardware we’re expecting, we need to provide a functionality called attestation. With attestation, you’re having this system a test, that the hardware that is connecting into your network, is the hardware that you originally set up as something trustworthy, that is allowed access to your internal systems.
If we’re managing a single device, it’s relatively easy to determine if that device should be connecting to our internal network. But when we have thousands of devices that we’ve deployed to all of the users in our organization, we need some automated process to be able to confirm, that the hardware that’s connecting into our network, is hardware that’s trusted.
With remote attestation, we have checks that occur on that remote device, and that device will provide a report to a verification server, that will then allow that device access to the network or prevent access to the network. This attestation report is usually encrypted and digitally signed using keys that are located on the Trusted Platform Module of that remote device.
This report might also include a unique identifier for that hardware such as an International Mobile Equipment Identity number or IMEI. By going through this attestation process, we can be assured that the device that’s on the other end of this communications path, is one that is trusted and is allowed access to our network.
Another type of authentication can be found with an SMS. This is a Short Message Service or we commonly refer to as a text message. You’ve probably used this process when authenticating with a third-party website. You would provide your username and password, and a message is then sent to your phone over a text message or SMS.
There’s usually a code contained within that text message, and you would put that code into the login form to confirm that you are the person who has that phone in your possession, and you can now approve that you’ve received that text message.
The use of SMS message, is generally considered to be less secure than other methods. It’s relatively easy for someone to reassign a phone number so that the SMS message is redirected into another person’s phone.
SMS messages can sometimes also be intercepted by a third party, giving them access to a code that normally only you would have available. These types of security issues are relatively rare, but if someone wants a higher security method for authentication, they might want to consider using something other than SMS.
Instead of relying on a text message, we may rely on our mobile device having a particular application installed. This is a push notification, where the server is pushing down the authentication information to your mobile device. It uses this mobile device app to be able to receive the pushed message and display the authentication information.
There are also some security concerns associated with push notifications. It could be that the application receiving the push notification might have vulnerabilities that would allow a third party to view that information.
Or it could be that the app is not using encryption, and that push notification is being sent to the phone, in the clear rather than using some type of protected mechanism. With the right app, however, this is a relatively safe process, and probably more secure than something like SMS.
Another type of authentication uses a pseudo-random token generator to create what would seem to be a random set of numbers that are used during the login process. This might take the form of a physical device, like this token generator that would fit on a keyring. Or it may be an app on your mobile phone that’s effectively providing the same coding information that you would get from a physical token generator.
Many of these token generators use a functionality called TOTP, that stands for Time-based-One-Time Password algorithm. This means the pseudo-random number will be available as a login credential for a certain amount of time, usually about 30 seconds, and after that 30 second period is over, a new number is generated.
When this TOTP device is first rolled out, there is a synchronization process using a secret key and the time of day. Once that process is in place, the Authentication Server, and the token generator, or token generator app, will know exactly what the next number is in sequence based on what the time of day is.
It’s common to use these by putting in your username, your password, and then opening up your app, finding the number, and adding that number into a field on the login page. If you’ve used multifactor authentication from Google, Microsoft, Facebook, and others, you’ve probably used an app like this that uses TOTP.
There’s another authentication type that’s very similar to TOTP, but instead of having a number that changes every 30 seconds, you have a number that you would use one time during the authentication process, and then you would throw away that number and never use it again.
This is called HOTP or HMAC-based One-Time Password algorithm. Usually, you would provide somebody with a sheet of numbers that they’re able to use during the login process, and then they use each one of those numbers each time they authenticate to the system. Once they’ve used the number they can cross it off their list, and they will never use that number again.
This is a similar authentication process to TOTP. You would log in with your username, your password, and then provide your HOTP passcode. This is also a code that might be stored inside of an app so that you don’t have to carry around additional papers or worry about what that next number is going to be.
The app will tell you what the next number is on your list. You can find both hardware and software-based token generators for HOTP, and these will integrate with whatever server you’re using for the authentication process.
Since many of these authentication methods are based on something you have, which would be your mobile phone, we could also use a phone call to perform the same type of function. Instead of having an app, you would use to provide that pseudo-random number, you would have an automated process call you, and tell you the pseudo-random number.
So you pick up the phone, and the automated message would say, your code is 1-6-2-5-1-7 and you would type that in along with your username and password, to complete the authentication process. The disadvantages of receiving phone calls for authentication are very similar to the disadvantages of receiving an SMS or text message.
Someone can modify the phone configurations, or configure forwarding, on your phone number so that they receive the phone call rather than you. These phone numbers can sometimes be also added to other phones so that when the phone rings, it rings across multiple devices simultaneously, and someone can intercept that call before you have a chance to hear it.
There are some authentication factors that never change. These are values that you’ve remembered, and you have to remember what that particular value is to complete the authentication process. A good example of this is a Personal Identification Number or a PIN. These are numbers that we use when authenticating with an automatic teller machine, for example.
We might also have a code that is alphanumeric, so we’re using a set of numbers and letters, to be able to provide the static code that we would use for authentication. A password or passphrase is a good example of an alphanumeric static code.
And if you carry around a smart card, you may find you also use that smart card for authentication. This might be something that requires contact, so you would slide the smart card into a laptop, or this may be contactless, where you have to get it near the reader for it to be able to read the information on that card.
This type of smart card functionality is very common on credit cards, but we can also use this for access control cards that we would use to gain access to laptops, computers, and other devices. The key with this authentication factor is it’s something you have. It contains a certificate on that card, and no one else has a copy of that card and that certificate. So if you’re sliding that smart card into a laptop to gain access, we’re assuming that you would be the only one who would have access to that card.
Obviously, someone could accidentally lose this card or misplace it, and someone else could gain access to that card. So very often smart cards are used with other authentication factors such as username, passwords, Personal Identification Numbers, or fingerprints.