The Microsoft Exchange Team Blog this week featured two very interesting posts: one on an executive-level reorganization (more on that next week), and one on the mechanics of setting up client certificate authentication. Seeing the detailed explanation of how to set up client certificate authentication reminded me that not everyone knows what it is, when it’s useful, or what you have to do to use it. (I’ll leave aside the how-to aspects of the setup, which are well covered in the original blog post). Client certificate authentication helps solve one of the basic problems of user-level computer security: Passwords aren’t very secure. That’s because human-chosen passwords generally have a low degree of randomness, or entropy. By some measurements, even a 20- or 30-character passphrase might have only about 40 bits worth of entropy, meaning that its effective strength is closer to that of a 5-character password. The bigger problem is that most people don’t use 20- or 30-character passphrases; they choose short, simple strings because they’re easier to remember.
There are many other problems associated with passwords. For example, if you set the password complexity rules for your domain too high, many users will write their passwords down. Users also have the unfortunate habit of using the same passwords for their corporate and personal accounts, meaning that an attacker who cracks a user’s Yahoo! password, for example, could get the bonus of free access to your corporate resources. As a final insult, passwords act as a single authentication factor; anyone who knows the password can impersonate the user.
Client certificates address all of these weaknesses. When you use them for authentication, the basic workflow looks like this:
- Your certificate authority (CA) issues a certificate to the user. The conditions under which this happens are up to you. Windows supports auto-enrollment so that certificates are automatically given to new users or computers when they join a domain. You can also choose to issue certificates manually so that you can check users’ identification, require them to sign a security policy, and so on.
- The issued certificate can be loaded onto the client computer where it will be used. It can also be stored on a smartcard or other external token, which helps secure it against accidental loss or purposeful compromise. (I particularly like smartcards because they add an extra authentication factor—“something you have”—to the password’s inherent “something you know” factor.)
- When the client computer attempts to make a secure connection to a server using any protocol that supports client certificate authentication, the client and server present certificates to each other. Each side validates the other’s certificate; if the validation checks succeed, the two sides can negotiate a secure connection using whatever set of algorithms they have in common.
- After the secure channel is established, when the server requests authentication from the client, it sends a challenge which the client must decrypt using the certificate. If the client successfully returns the correct value for the challenge, it is treated as authenticated.
Step 3 already happens on your computer hundreds of times a day; every time you visit an SSL-secured website, your computer requests, receives, and validates a server SSL certificate. The difference in this case is that the client is also presenting a certificate of its own that the server can check. For this reason, OWA is a natural place to apply certificate authentication. However, Microsoft supports client certificates for a number of other uses, including smartcard-based logon and the Encrypting File System (EFS).
Does the increased security of certificate authentication make up for the increased cost and overhead of issuing and managing certificates for your users? That’s a hard question to answer—and one that has been debated for at least the 15 or so years that client certificates have been widely available. You’ll have to survey your own environment to see what makes the most sense for it, keeping in mind the many other uses for certificates in a Windows environment.
End of Article
Register
