Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Example scenario:

  • ActiveSync

Authentication method:

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

Encrypted on device:

  • public & private key
  • AD username & password

Question:

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?

Notes:

  • 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?)
share|improve this question

4 Answers 4

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.

share|improve this answer
    
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. –  George Tsiokos May 18 '12 at 5:21

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.

share|improve this answer
    
To confirm, you do not recommend ever storing the password on the device, correct? –  George Tsiokos May 21 '12 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 May 22 '12 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).

share|improve this answer

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.

share|improve this answer
    
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". –  Lynn Kinsey Aug 17 '12 at 16:24

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.