The first problem in security is to know with whom you are dealing. The client’s concerns about the site’s identity (“Am I sending my money to the real MegaBank or a crew of clowns in Bogota?”) should be settled by a server certificate as described earlier.
You, as the webmaster, may well want to be sure that the person who logs on as one of your valued clients really is that person and not a cunning clown.
Without any extra effort, SSL encrypts both your data and your Basic Authentication passwords (see Chapter 5) as they travel over the Web. This is a big step forward in security. Bad Guys trying to snoop on our traffic should be somewhat discouraged. But we rely on a password to prove that it isn’t a Bad Guy at the client end. We can improve on that with Client Certificates.
Although the technology exists to verify that the correct human body is at the console — by reading fingerprints or retina patterns, etc. — none of this kit is cheap enough (or, one suspects, reliable enough) to be in large-scale use. Besides, biometrics have two major flaws: they can’t be revoked, and they encourage Bad Guys to remove parts of your body.[11] They are also not that reliable. You can use Jell-O to grab fingerprints from biosensors, offer them up again, and then eat the evidence as you stroll through the door. Or iris scanners might be fooled by holding up a laptop displaying a movie of the authorized eye.
What can be done is to make sure that the client’s machine has on it (either in software or, preferably, in some sort of hardware gizmo) the proper client certificate and that the person at the keyboard knows the appropriate passphrase.
To demonstrate how this works, we need to go through the following steps.