Providing Vendors and 3rd parties with two-factor authentication

Posted by:

admin 10 years, 9 months ago

Krebs on Security is pointing a finger to a third-party vendor with remote access as the entry point for the Target hackers.   PCI requirement  8.3 states that you must incorporate two-factor authentication for remote network access by all personnel and all "third parties, (including vendor access for support or maintenance)."

So, how does a company manage these users?  There are two options:  internally or externally.

Internally, there are two options.  First, put them in your directory.  Their RADIUS authentication requests from the remote access system  are authorized by the directory and then proxied to the two-factor authentication server.  Removing them from the directory or the auth server removes their access.  We recommend this as the best way to implement two-factor authentication in general in our (registration-free!) eGuide.  Alternatively, you can have them only in your two-factor server.  Your network access point would then authenticate directly without any authorization.  This setup means that your vendor management process would not go through your directory.  It might mean that your 2FA server admin has to manage the vendor's users, depending on the capabilities of the server. (More on this later.)

Third party users can also be managed externally.  (Now, I'm moving to WiKID-specific capabilities.)  With the WiKID API, you can create a very simple application that allows 3rd parties to manage users on the WiKID server. The application is specific to the network client for that vendor, meaning that they can only manage their users.  The WiKID server admin still has ultimate control over the users.   Their application requires an p12 client certificate from the WiKID server for encryption.  If you terminate the relationship with the vendor, you can delete their users and their certificate.  This capability was developed to proved multi-tenancy in the WiKID server, pushing control of the users where it should be.  It is also very useful if you have a trusted vendor with a large number of users or high-turnover.

You can also use this capability for internal use.  You can create a simple application and allow internal vendor managers to add and delete the the vendor's users without giving them admin rights on the WiKID server or putting the users into your directory.

User management, enrollment and disablement in particular are big cost drivers for two-factor authentication.  A simple API provides an easy way to keep these costs in check.  That's why our API is LGPL-licensed, works with both the Enterprise version and the open-source Community version and is easily downloaded by anyone.

• ← New server update
• Consortiums and Standards in Authentication →