Authentication answers the question Who are you? When Alice logs in to a machine, the machine challenges her to prove her identity by asking for a password (or something else, like a smartcard). This is one example of authentication. Another is when Alice is already logged in to a machine and requests a file from another machine via a file share. Even though she's already logged in to the local machine, that doesn't help the remote machine at all. The remote machine wants proof that this is really a request from Alice as opposed to some attacker on the network just pretending to be her. Kerberos (WhatIsKerberos) is an example of a network authentication protocol that protects most Windows systems.

It sometimes helps to break down the question Who are you? into three, more specific questions.

• What do you have?
• What do you know?
• What are you made of?

Asking one or more of these questions can help you infer the identity of a user. For example, a password is something that only that user should know, whereas a smartcard raises two questions: What do you have (the card) and What do you know (the PIN code on the card). This is referred to as multifactor authentication and can lead to considerably more secure systems. The last question queries biometric data such as hand geometry, retinal patterns, thumbprints, and so on. (Schneier 2000) talks a bit about the pros and cons of biometrics, pointing out that they often aren't all they are cracked up to be. For example, thumbprint readers have been shown to be incredibly easy to fool (Smith 2002).

Network authentication can happen in one of three ways. The server can ask the client to prove her identity (the default mode in Kerberos). The client can ask the server to prove his identity (the default mode in SSL), or we can have mutual authentication, where both client and server are assured of each other's identities (both Kerberos and SSL support this as an optional mode). Usually you should prefer mutual authentication wherever possible, unless anonymity is an important feature of the service you happen to be providing. I find it interesting that, in many cases where it seems as though you're getting mutual authentication, you really aren't. For example, when you log in to a Web server over SSL by typing a user name and password into a form, logically you think you've established mutual authentication. You've proven your identity with a user name and password, and the server has proven its identity with a certificate and its private key. But did you double-click the lock to actually look at that certificate? Did you look closely at the URL in the browser address bar? Probably not. For all you know, the server is being spoofed by a bad guy who has simply duplicated the look and feel of the real server. The same problem exists in some of the built-in security mechanisms in Windows. For example, COM has always claimed to use mutual authentication. But the dirty little secret is that, unless you set up a server principal name (WhatIsAServicePrincipalName) and specify it in the client code, you're not really authenticating the server; you're just trusting the server to tell you whom it’s supposed to be running as. But nobody does this, just as nobody checks the certificates of sites they visit. One of the goals of this book is to make you aware of how these security mechanisms work so that you know what you're really getting!

PortedBy WillyDenoyette