Discussion: Multi-factor and two-factor authentication
I am wanting to start a discussion on the feasibility of different authentication examples within Linux. The reason is to provide a proof of concept in the form of an idea stating how easily some authentication examples can be implemented within modern operation systems, mainly Linux, of course. Windows and Mac users can feel free to jump in too. At the same time we can discuss which methods would be difficult or unable to be implemented at this point in time.
This idea for the discussion came about after I was thinking bout the DoD CAC authentication scheme. I'm amazed that by and far, this is the main form of authentication for the majority of services (to my civilian knowledge). I'm still trying to wrap my head around how such a system is setup.
Near as I can tell you have a Certificate Authority and the Root CA for the DOD. When a CAC users needs to be enrolled a certificate request is generated from the (I'm assuming) fingerprint of the CAC Card, the request is then signed by the ROOT CA or an intermediate CA. Once received, the Signed Certificate is stored on the CAC Card. The same goes for Public Keys.
Then when a service need to be deployed to allow CAC Authentication, the authentication modules are installed, the root key is imported and users are able to sign in with CAC card.
With that in mind, I am wondering what other systems or methods could be used in a broad spectrum of authentication services such as Apache, local system access, VPN, email, etc..
To keep everyone within the same realm of understanding we'll agree to these definitions of single, two-factor, three-factor and multi-factor authentication.
Single Factor Authentication
* Something you know
* Something you know
* Something you have
* Something you know
* Something you have
* Something you are
* See Three-Factor Authentication
Below are some examples I could think of but, which ones would be most feasible, I leave up for discussion here. If there are any that I have missed, and I am sure there are, please feel free to add to the list for discussion.
* Smart card
Example 2 - Two factor method
Example 3 - Two factor Method
As a bonus, what would be the most paranoid, yet feasible, authentication method you can think of.
You've covered the multi factor authentication mechanisms that I can think of, at least the practical ones. It basically comes down to knowing a password, having a key, and a biometric scan. Of course we could go the Gattaca route and test DNA, but I wouldn't be too happy with that.
What really interests me about this discussion and concept is the adoption of multi-factored authentication. At work, we have a VLAN in private address space that is home to our critical control systems. Once someone is inside of the VLAN, the authentication is still based on Active Directory and a password that is common to the entire system. I would greatly prefer a two factor authentication and I have been working with our IT security division on enhancing our position. This is one of the recommendations that they had and I do know that they can make use of it, but it isn't widely deployed.
It is debatable whether this is a separate mechanism, but there are challenge-response systems.
Captchas - used to filter bots from human beings based on the ability to interpret patterns.
Shared secrets - as used by my bank when I add a new biller. This does not proceed unless I answer two questions with answers known to me and previously shared with the bank.
Glad to see there is an interest in this topic! I find authentication systems to be so fascinating and I don't know why.
Noway2, It's interesting how your company achieves it's level of security. I work for a Fortune 500 Company (Classified), and I find their setup quite interesting. My job function is *nix administration and we have standardized our authentication. While we utilize VLAN's as well, it is taken one step further by requiring every device to have it's own device certificate, signed by an Intermediate CA. If the device certificate is invalid it can't join the network. The second level of authentication is the use of Active Directory Single Sign On by utilizing Kerbos, LDAP, or Quest Software. Usernames and Password are derived from Windows Active Directory.
I would be interested in trying to mimic the DoD CAC infrastructure to play around with but my computer isn't powerful enough to run the number of VM's I would need.
Of the methods I mentioned, the most implementable that I can see that allows for wide implementation is smartcard and LDAP or LDAP and certificate setup. This is most likely the reason why the DoD choose it for their infrastructure. Of course the smartcard is certificate based but you make the certificate portable to the user instead of stationary to the device.
In my case, I work for a university chilled water utility. We have some centralized plants with servers in them, that I view as being critical. I would really like to use a multi factor authentication to permit access to these servers. Ideally, you would be able to access them remotely too, as long as you have your 'key'. As I mentioned, there are some individuals in IT who are using a key based technique and they have offered to share with me. It is just a matter of working through the entire project of security enhancements that I am planning.
Currently I am working on the Access Control Lists for the switches. In a way, this is an offshoot of multi factor authentication: where you are located. If you aren't connected to the proper subnet / address space, you are denied access.
Centralized authentication in my opinion can be a security risk, in and of itself. Enabling SSO allows for multiple points of exploitation of a central authentication system. If it were me I would require re-authentication for every service. Convenience breeds complacency. When a person or entity becomes complacent they start to care less about their security or they make mistakes in the level of protection their authentication method provides.
If you have several key systems that don't interact with each other but allow for SSO, especially if you have top secret data stored on the systems in question, you might as well leave the key to the front door under the door mat.
So I was sitting here at work thinking about certificate based authentication when a thought popped into my head.
Let's say that you have an Apache web server serving a website that uses certificate based logins. Now when it comes to the certificates in questions, they are user certificates generated for the user to prove their identity instead of device certificates for a specific device.
In this hypothetical situation you are debating on implementing a certificate only authentication scheme, what is there to prevent a user giving their certificate to another user to given them access to the site. If you didn't have two-factor authentication this could be a major problem, but even with two factor it still may be.
How can you verify that one and only one person with that certificate is logged in. You don't want to allow multiple logins with the same user certificate. The one way I can think of is to establish sessions and then of course the obvious other solution is to enable some form of two factor authentication. My sessions idea though is a bit vague at the moment. I am thinking on how you could prevent multiple logins with the same certificate using sessions but haven't got my mind wrapped around it yet.
This could also be a problem with CAC cards, how do you ensure that certificate hasn't been copied and used by someone else. The smart card or CAC card should have a fingerprint that could be extracted via php and stored in a session, but again still wrapping my head around it and thinking out loud.
Thoughts on this? This post isn't the best, since I'm not at home and unable to think it out. I wanted to post it however before I forgot.
Smartcards, RSA SecurID, and OTP systems (yubikey is one I have experimented with) should not give the same key every time. Some are challange response, (system sends you something, the smartcard decrypts and re-encrypts and sends back), some are real time synced (RSA SecurID), and some are encrypted incrementing counters (OTP), but every time the actual sequence sent back is different, time limited, and unique.
In all these systems the cryptographic certificate on the hardware is designed to be irretrievable and tamper proof. You may be able to replace the certificate for a users device, (though some like RSA SecurID have even that fixed at the factory), but you can not read it.
|All times are GMT -5. The time now is 04:01 AM.|