Smart card logon with EIDAuthenticate — under the hood

The architecture of Windows logon and its extensibility model is described in a highly informative piece by Dan Griffin focusing on custom credential providers. (While that article dates back to 2007 and refers to Vista, the same principles apply to Windows 7 and 8. ) The MSDN article even provides code sample for a credential provider implementing local smart card logon– exactly the functionality of interest discussed in the previous post. A closer look at the implementation turns up one of the unexpected design properties: they leverage built-in authentication schemes which are in turn built on passwords. Regardless of what the user is doing on the outside such as presenting a smart card with PKI capabilities, at the end of the day the operating system is still receiving a static password for verification. EIDAuthenticate follows the same model. The tell-tale sign is a prompt for existing local account password during the association sequence described earlier. FAQ on the implementation says as much:

A workaround is to store the password, encrypted by the public key and decrypted when the logon is done. Password change is handled by a password package which intercepts the new password and encrypts it using the public key stored in the LSA.

In plain terms, the password is encrypted using the public key located in the certificate from the card. The resulting ciphertext is stored on the local drive. As the smart card contains the corresponding private key, it can decrypt that ciphertext to reveal the original password, to be presented to the operating system just as if the user typed it into a text prompt. (The second sentence about intercepting password changes and re-encrypting the new password using the public key of the card is a critical part of the scheme. Otherwise smart card logon would break after a password change because the decrypted password is no longer valid.)

This is decidedly not the same situation as enterprise use of smart cards. Domain logon built into Windows does not use smart cards to recover a glorified password. Instead it uses an extension to Kerberos called PKinit. Standardized by RFC4556, pkinit bootstraps initial authentication to the domain controller using a private key held by the card. Unlike the local equivalents, there is no “password equivalent” that can be used to complete that step in the protocol. While smart cards may coexist with passwords in an enterprise (eg depending on security policy, some “low security” scenarios permit passwords while sensitive operations require smart card logon) these two modes of authentication do not converge to an identical path from the perspective of the domain controller. For example the company can implement a policy that certain users with highly privileged accounts such as domain administrators, must log in with smart cards. It would not be possible to work around such a policy by somehow emulating the protocol with passwords.

It is tempting to label EIDAuthenticate and solutions in the same vein as not being “true” smart card logon because they degenerate into passwords downstream in the process. While that criticism is accurate in a strict sense, the more relevant question is how these solutions stack up compared to using plain passwords typed into the logon screen each time. It’s difficult to render a verdict here, because the risks/benefits depend on the threat model. In particular, for stand alone PCs the security concerns about console logon, eg while sitting in front of the machine, are closely linked to security of the data stored on the machine. The next post in the series will attempt to answer this question.


6 thoughts on “Smart card logon with EIDAuthenticate — under the hood

  1. vletoux says:

    Well, I’m the author of EIDAuthenticate and your remarks are not completely true.
    The authentication is handled by an “authentication package”. So if the password is reset offline, the logon will still work.

    However, some stuff are protected by password derivates like certificates (EFS, Bitlocker to go) or passwords (IE, Windows). The process is named DPAPI as explained here ( If internally no password or a wrong one is submitted, the session will be opened but every passwords will be losts silently. The password synchronization scheme is used to preserve these secrets.

    AD smart card logon does exactly the same think than EIDAuthenticate at one exception : they submit directly the password derivate instead of submitting the password then compute the derivate. Unknown internal mechanisms are used. I though I can put the derivate through SECPKG_PRIMARY_CRED but the flag PRIMARY_CRED_OWF_PASSWORD is not used even by the kerberos SSP. (instead the “password” is stored in clear text and is the PIN).
    And password synchronization mechanisms are done, but inside the domain controller. See SpAcceptCredentials with the flag PRIMARY_CRED_UPDATE.

    EIDAuthenticate is the closest solution to AD smart card logon as :
    – nothing is broken if the password is changed online or offline
    – the password don’t leave the LSA adress space
    – it works even if the “force smart card policy” is active or if the password is expired


    • Hello Vincent.

      Thank you for your comment and also for authoring EIDAuthenticate in the first place.

      First: I plan to write at least one more post about the threat model of local smart card logon, and would be happy to post additional clarifications/corrections there.

      There are several issues here:
      1. The main point is that with domain logon an attacker can learn a user’s password and they will still not be able to log into any machine configured to reqiure smart cards. In other words, the two credentials have different privilege levels. Is it possible to achieve same separation with local logon– eg suppose password is known, can attacker be prevented from logging in?

      2. Agreed that a hash is required for DPAPI but my understanding is for enterprise logon that can be a random value; eg not possible to use a dictionary short-cut against it. See for example Brad Hill’s description at
      “Smart card only users do not have a pass-word, but they still have an OWF. Instead of being based on a password it is simply a ran-domly generated 128 bit value. When a user authenticates using PKINIT, to support NTLM authentication, the user‟s OWF is sent to the client in […]”

      3. In general being able to recover the password directly is undesirable. For many years now it has been possible to avoid storing weak LM hashes, although NTLM hashes are still subject to brute forcing eg via rainbow tables. But having the password stored in *reversible* form (eg can be decrypted by smart card) creates yet another threat against same resource, in addition to the existing brute force attack against hash.


      • vletoux says:

        1. Yes and no. If an attacker has a physical access to the computer, he can overwrite the configuration data to logon without a password (AD and standalone). EIDAuthenticate set a flag indicating that the session has been opened by a smartcard, like kerberos. The policy “smart card logon only” is working with EIDAuthenticate the same way a domain joined computer will : if the policy is set, you’ll get an error everytimes you try to open a session with NTLM. So the risk is the same.

        2 No, it simply states that if a user has a smart card and doesn’t have a password, a random one is generated. Nothing prevents you from doing it manually. So the risk is the same.

        3. Your statement is based on the fact that you can explore the memory of the logon process to recover the password. EIDAuthenticate changes nothing : you can already do it. For example using mimikatz which extracts it from the DPAPI database. And you forgot that the password is also stored in clear text in the network driver … (see the paper from aurélien bordes about that).

        So yes, the smart card logon on local computer has caveats … the same than the active directory ones.
        Moreover, on active directory, you have an attack where the user forges a certificate with the UPN set to the account he wants to hack.

  2. Hi Vincent.

    This discussion may be conflating two independent attacks:
    1. Logical access: impersonate user with interactive or network logon (Even non-domain-joined machine supports remote authentication for RDP access)
    2. Physical access: boot into alternative OS, remove drive from machine to read/write contents, use Firewire etc.

    If we assume the attacker is capable of #2, then any data stored locally and not encrypted on the machine is toast. It does not matter what type of authentication the legitimate user had setup. In an enterprise there are many more resource stored remotely and it’s still important that attacker can not get at those. In this case smartcards vs password makes a difference because we do not want hashes stored locally to be brute-forced and used to access other resoruces. But for local logon, the assumption is only resources to protect are on that machine.

    For encrypted data, story is more complex: DPAPI and EFS use the password for key derivation as you pointed out. Having a completely random is much better in that case. To achieve equivalent security as pure smartcard logon, EIDAuthenticate would have to set the user password to random string unknown to the user.
    Even then the theoretical attack remains: given the stored ciphertext of password and just one call to the smartcard for decryption, all future logins are compromised. Also this attack works offline. Even after machine is powered off, one can scrape the ciphertext. What is the corresponding risk in PKINIT where 1 smartcard operation is enough to compromise the user for all time?

    Regarding Bordes’s papers, which one were you referring to? As far as I can tell, they have not been translated into English:
    I assume by “network driver” you are referring to the network service account?
    Not sure how that relates to the problem of password recovery offline. Recovering the random OWF does not help with accessing remote resources. (But in that model attacker also has the TGT)


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s