Tuesday, September 4, 2018

Single Sign On & Kerberos


Imagine Susie wants to log on to a company database, her own system, a web server, her webmail and other multitudes of applications. Since she needs to access so many resources, it is extremely important to have a set of credentials for accessing each of this resource. This means Susie must remember an approximate dozen passwords in order to access these resources. Susie finds a solution to this problem. She writes down every single username and password to access them.

Clearly, Susie is not alone in doing so. You may also be doing the same. Clearly, from an information security point of view, this is not a great solution. It may sound that different ids and passwords would provide more security, it ultimately ends up in more work for the administrator since there are more requests of password reset or greater chances of a breach if that notebook gets in the wrong hands.

So what needs to be done? Well, as usual, the intelligent minds gathered together and found a solution to this problem. They called it the Single Sign-On. You can call this a double-edged sword too. Why? We’ll learn about it a minute. 

Single Sign-On allows a user to enter credentials one time and be able to access all resources in primary and secondary network domains. This reduces the amount of time users spend authenticating to resources and enables the administrator to streamline user accounts and better control access rights. It improves security by reducing the probability that users will write down passwords and also reduces the administrator’s time spent on adding and removing user accounts and modifying access permissions. If an administrator needs to disable or suspend a specific account, he can do it uniformly instead of having to alter configurations on each and every platform.

This sounds really great as it solves all of our problems. Just one username and password and the world is yours, (Now that’s a lot), the resources are yours. 

Wish, life could be so simple. Single Sign-On (SSO) operates on an assumption that all platforms support the credentials in the same manner and will talk to each other, which is extremely rare, given the multitude of platforms and technologies which companies employ. Remember, the double edge sword mentioned earlier. It is simply that if you leak that one super powerful username and password to Thanos, you will see your resources vanishing like the Avengers.

So simply speaking, SSO technology allows you to access multiple resources through a single username and password. You enter the credentials and voila, you have everything you are authorized to access. It does help Susie as she doesn’t need to remember multiple passwords. She can keep one complex passphrase which is easy to remember, yet is extremely complex. 

One of the most commonly used SSO technology is Kerberos. 

If you have seen Harry Potter, you may remember the three-headed dog that was guarding the philosopher’s stone. The photo below may refresh your memory. Confused, as to why a three-headed dog related to SSO here? Kerberos is the name of a three-headed dog that guards the entrance to the underworld in Greek mythology. This is a great name for a security technology that provides authentication functionality, with the purpose of protecting a company’s assets.



So let’s understand everything about Kerberos but in a very simple manner. 

Kerberos is an example of a single sign-on system for distributed environments and is a de facto standard for heterogeneous networks.  Kerberos is like a family in which there are multiple family members and each has a role to play. Let’s hear the names of all these members with their introduction.

Key Distribution Centre – He is just like the father who is having all the money. The Key Distribution Center (KDC) is the most important component within a Kerberos environment. The KDC holds all users’ and services’ secret keys. It provides an authentication service, as well as key distribution functionality. The clients and services trust the integrity of the KDC, and this trust is the foundation of Kerberos security.

The father has a helping hand known as the TGS – ticket-granting service (the mother) which generates the ticket.

Principal – They are the users or the applications which ask for services from the KDC. You can think of them as the kids in the family. They have new requests every day for the father. (KDC). Let’s say, Cathy is one of the kids and requests for a chocolate from the father. So here, Cathy is the principal and the father will act like the KDC.

Hopefully, you understood the analogy. 

Now let’s take up a real situation to help out things into perspective.  This is how the Kerberos process would take place.

1. Cathy comes to Evil Corp to complete her assignment. She logs into her system by providing her credentials.

2. Her request goes to the Kerberos software in her system.

3. This software sends her request to the KDC (remember, KDC is the one which has all the secret keys).

4. KDC sends back Cathy a ticket (not to Europe for holiday !!), which is encrypted with her password.

5. If Cathy entered the right password, then the ticket would be decrypted. Understand it in this manner, if Cathy entered the right password in the beginning, her ticket which is received from the KDC would be valid, if not, then it would be an invalid ticket.

6. Now Evil Corp is in the business of selling user’s information on the black market. 

7. Cathy wants to access this database where all such illegal information is stored. 

8. In order to access this information, Cathy sends a request to access to this database server.

9. Cathy’s system sends a request to this database server, her system sends the TGT to the ticket-granting service (TGS), which runs on the KDC, and a request to access the database server.

10. Why is everyone sending each other tickets? I know. This is because of the trust factor. KDC is one whom everyone trusts. So everyone sends his/her requests to the KDC so that KDC can confirm to everyone whether this is an authorized entity requesting access or not.

11. The TGS creates and sends a second ticket to Cathy, which she will use to authenticate to the database server.

12. What does the second ticket contain? This second ticket contains two instances of the same session key, one encrypted with Cathy’s secret key and the other encrypted with the database server’s secret key.

13. Cathy’s system sends this second ticket to the database server for authentication. 

14. When the database server receives this second ticket, it verifies this by decrypting it. 

15. If it successfully decrypts it, this means it is a valid request. Post this validation, Cathy will get this access to the database server.

This is an extremely simplistic overview of what is going on in any Kerberos exchange, but it gives you an idea of the dance taking place behind the scenes whenever you interact with any network service in an environment that uses Kerberos.

What are your thoughts on this? Share your thoughts in the comments section below.

No comments: