Example scenario:

  • ActiveSync

Authentication method:

  • certificate-based authentication AND Active Directory domain username-password

Encrypted on device:

  • public & private key
  • AD username & password


If a certificate is used for authentication for a reverse proxy and a username & password is used for Outlook Web Access, is this considered two-factor authentication? Is it useful at all if the certificate public key is part of the Active Directory user account? What are the arguments for or against this implementation?


  • Isn't this design more insecure (since the AD domain username & password is stored on the device unnecessarily)?
  • I can't find any papers out there, but I'm sure there is a general acceptance that storing AD domain username & passwords on devices has more potential threats that just a certificate public/private key pair.
  • Isn't there an option w/Exchange where the certificate issued for ActiveSync can be forced to be only used for Exchange access? (the certificate couldn't be used for HTTPS authentication to an application, for example?)

5 Answers 5


The question is a bit hard for me to decipher, but I am going to assume you are considering authenticating users by having the user present a username and password, and also having the user authenticate with a private key (client cert) that is stored on the user's device.

Short answer: yes, this is generally beneficial. If the user authenticates by both a client cert and a username/password pair, then yes, I would consider this two-factor authentication.

Even more important than whether it "counts as" two-factor authentication is whether it adds security, and whether it meets your security needs. Generally speaking, I would say that yes, this approach is useful and does add security, compared to just using username and password. You haven't provided enough information to assess whether it is adequate to your business needs, but I can share some thoughts on the strengths and weaknesses of this approach.

Security analysis. Generally speaking, requiring the user to authenticate using both a client cert and a username/password pair should be more secure than either one alone. I'll assume the client's private key is stored only on their device, and the user's password is not stored on the device. Here are some benefits:

  • Benefit: Security against social engineering. One weakness of passwords is that, since users know their own password, users can often be tricked into revealing their passwords, for instance by phishing, by spoofed email, by someone pretending to be from the IT help desk, or other forms of social engineering. Client certs address this risk: the benefit of the client cert is that the private key is a secret that the user does not know, so the user cannot be fooled into revealing it. An attacker may still be able to use social engineering to steal the user's password, but they won't find it easy to steal the user's private key, so they won't be able to get access to the user's account.

  • Benefit: Security against password guessing attacks. Another weakness of passwords is that users often choose poor passwords (which can be guessed through dictionary attacks). Also, users often reuse passwords on multiple sites, which means that a compromise of one site can negatively affect the security of the others. Client certs eliminate this problem: the private key is chosen randomly by a computer, and thus does not have problems with low entropy. Consequently, even if an attacker can guess the user's password, the attacker cannot gain access to the user's account.

  • Benefit: Security against lost devices. One shortcoming of client certs is that the private key is stored on the user's device. Thus, if the user's device is lost or stolen, the private key is compromised and the new possessor of the device may be able to access the user's account. Using a password in addition to a client cert addresses this threat. If the user's device is lost or stolen, the recipient of the device probably won't be able to access the user's account, because the recipient won't know the user's password (assuming the user did not choose a password that was totally terrible).

However, there are also some limitations and pitfalls with this approach which are worth being aware of.

  • Limitation: Does not defend against client-side malware. This form of two-factor authentication does not defend against malware or spyware on the user's device. Such malware can record the user's password and also grab a copy of the user's private key, thus capturing all credentials needed to access the user's account. So, if you are concerned about client-side malware, you will need to use some other approach to mitigate that threat.

  • Pitfall: Don't store the password. There is a pitfall with this approach. If you store the user's password on the user's device, then the password just becomes one more secret on the device; the security is then no better than just using a client cert. In particular, at that point, if the user's device is lost or stolen, all the information needed to access the user's account is present on the user's phone, so the user's account must be considered compromised. Therefore, if you are writing a custom client app, it is important that you avoid storing the user's password on the user's device. Similarly, if this is intended to be accessible over the web, you must ensure that the user's password is not stored in their browser password manager.

Caveat. One word of caution about my analysis. I am addressing the general concept of authenticating users with a combination of username/password plus client cert. I cannot speak to implementation details about Outlook, Active Directory, Exchange, ActiveSync, reverse proxies, or other aspects specific to the Windows environment, as I'm not familiar with those details. I can only analyze the general approach. If I'm missing relevant implementation details, then my conclusions may not apply to your situation.

  • Great answer! The password is stored on the device. This is why I question the "two-factor" definition because both secrets, the password and the private key, are stored on the device. Commented May 18, 2012 at 5:21
  • @GeorgeTsiokos: if both password and cert is stored in the same device, then it is ineffective as two factor authentication. A proper two factor authentication is one that requires two piece of secret: one piece is something the users know (password) and the other piece is something that the users have (device with a cert). If the device has both pieces, then it is no longer two piece. If you store both pieces on the same device, you might as well just use certificate only, the password is superfluous in that scenario.
    – Lie Ryan
    Commented Jun 11, 2015 at 1:35

Your certificate is stored on the computer, probably encrypted with the user's password. So to access the OWA account, one must have

  1. The username (probably pre-filled at logon or easy to find)
  2. The password
  3. The computer where the certificate is stored.

The problem (+1 to @D.W. who mentionned it already) is that the computer keystore is hardly tamper proof. The security is really something you know, the username and password.

At a client who had the same setup, we settled this problem saying that it could be considere as 1.x factor, as it provides better security, but not two factor. If you already have a PKI in place, putting a certificate on the smart card, with the proper process would make your scheme a real two factor.

  • To confirm, you do not recommend ever storing the password on the device, correct? Commented May 21, 2012 at 17:36
  • 1
    Right. Never store the password on the device. And to be considered two factor, a certificate must be store in a tamper proof device. But my interpretation is as good as the next. It depends on your threat model and tolerance to risk.
    – ixe013
    Commented May 22, 2012 at 13:58

I don't consider static credentials/keys to be good two-factor authentication. As previously answered a device can be stolen along with the stored private key.

The best two factor authentications uses a device (or a software) which calculates some data that can be used as a password, like SecurID tokens or soft-tokens, the client can be even set up on smartphones (Android/iPhone).

And for your setup I think a VPN might be better solution. If you set up a VPN with such security device at the user then you don't need tighter security:

  • authentication will be of two-factor
  • communication will be secured (usually L2TP/IPSEC)

The computer usually doesn't get stolen with such a key (which either fits your keyring or it is on your phone).


The following factors are possible for an authentication:

  1. Something you know.
  2. Something you own.
  3. Something you are.

Something you know can be a password or a pin. Something you own can be a token like a Smart Card or a soft PSE like a PKCS12 file containing a private key and a certificate. Something you are is a biometric attribute like a finger print or a vein pattern.

An authentication is a two- or three-factor authentication, if two or three factors are used for the same authentication.

You example is not a two-factor authentication, because you have two one-factor authentications.

  • I agree with Ceving. True two-factor authentication requires a separate authenticator like a smart card or token to be what you "have", or fingerprint reader and your fingerprint for something you "are." Risk-Based authentication can be the something you "know". Commented Aug 17, 2012 at 16:24

using a certificate and a password for authentication is NOT considered as a 2FA, since both are utilizing "what you know".

  • 1
    This is not correct. A password is "something you know" and a certificate is "something you have."
    – Xander
    Commented Jun 11, 2015 at 0:32
  • Yea, I don't know why I wrote this. 1000% wrong.
    – POSH Geek
    Commented Jun 20, 2018 at 23:26
  • But the other answer seem to say it is a correct statement ixe013 specifically says it " And to be considered two factor, a certificate must be store in a tamper proof device" - a certificate which can be read by you is still "something you know" - but a device which stores the certificate so you can not read it is something you have - The statement "it could be considere as 1.x factor" again by ixe013 indicates the difficulty of knowing a certificate - but certificates you can read can be copied to a another device also demonstrating its not something you have
    – Ross
    Commented Sep 11, 2019 at 4:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .