Dan Griffin's Blog

Comments on security, PKI, smart cards, cryptography, and entrepreneurship.

When is a credential provider not enough?

March 14, 2008

Wanted to blog about a recent question relating to custom multi-factor authentication solutions on Vista (and subsequent versions, including Server 2008). The question basically boils down to what you can do by implementing a credential provider (credprov), versus implementing both a credprov and a custom SSPI package.

The interface between credprov and winlogon is such that the latter is expecting to receive SSPI authentication information from the former.  In other words, whatever you return has to be digestible by LsaLogonUser (or whatever the latest variant of that function is called).

So in order to add new authentication mechanisms, I’m aware of the following two approaches:

The first is to create a separate credential store consumed by the plug-in credprov. The purpose of the store is to map the proprietary credential into a username/password (and maybe domain name). Thus the user enters a custom cred into the credprov, the credprov verifies it, maps it to a standard Windows password (which, on the plus side, can be long/complex), and returns the password info to winlogon.

The second is to extend SSPI to handle a new credential type. This is the most work, but also the most powerful, since it allows you to actually manage accounts directly from a custom repository (e.g. other than Active Directory or the local SAM).

For example, the biometric solutions currently on the market integrate with AD. They also typically include some sort of provisioning console. So when you enroll a new user via that console, it not only creates the account in the fingerprint database, but also the account in AD with a big random password.  Thus, once enrolled in the system, a user can logon to any machine joined to that domain. But they don’t require a custom SSP package (there are exceptions).

If you choose the more complex route, note that the association between the user credential, the credprov, and the SSP package starts with whichever credential tile the user chooses. If they chose one labeled “Dan’s Custom Provider,” the data gets routed to my credprov. My credprov knows the credential format recognized by my SSP. The rest is handled by the Negotiate provider in SSP; it queries the other providers until it finds one that recognizes that cred blob.

Smart card logon in Vista is a “partial” example of the above, since there is a smart card credential provider plug-in that ships with Vista. However, smart card logon requests are handled by the Kerberos SSP.

Search:

Archives

Recent Posts

• Microsoft SDL Threat Modeling Tool
• Need PR help?
• Importing a physical SBS machine to Hyper-V
• MD5 (was already) considered harmful
• Importing physical machines to Hyper-V

RSS Feed

Blogroll

Security Focus: