Security is a significant consideration for any website that exists on virtually any network (Intranet, Extranet, Internet). Security threat analysis and design is a large topic with a myriad of options, trade-offs and complexities. As with any facet of software, a balance between data sensitivity, pragmatism and scope must be made. One consideration is taking another look at Authentication.
Authentication is typically the initial point of a entry for a secured web-based system. For many systems, this step consists of a user providing a user id and password. Authentication can also follow the Two-factor security process whereby the user provides two forms of identification. This approach is often verbalized as “something you have and something you know”. User id + password would be considered one form of “what you know” identification. What about the “something you have”? (there is also a three-factor authentication concept, where
the third component consisting of biometric data such as fingerprint or voice).
So, what can you have? Some organizations use physical devices to provide information for the second factor. Users enter their pin and receive a user-specific, lifetime-controlled, temporary password to use to gain authentication.
Good stuff, but for your website, this could be another thing for people to lose. Another approach for the second factor is the use of Client Certificates. Client Certificates are issued by a Certificate Authority (a trusted third party or an internal server to your company). While server certificates typically provide encryption services, client certificates are all about user authentication. With a Client Certificate, a client can assert who they are beyond user id and password.
[Assuming IIS] At the most basic level, setting up this scenario involves 2 main steps:
- Install a client certificate. Client certificates can be obtained for free or for a fee, and are installed on a user’s machine into their certificate store. Arguably this is one caveat with this particular approach: machine affinity.
- In IIS, go to “Directory Security” > Secure communications > Edit… and configure the site to use HTTP, and require client certificates:
Once you’ve done this, the web server and the client [browser] will have a little chat to prompt, obtain, verify and ultimately accept or reject a client certificate. Following the handshake, you can see the client certificate flowing in the Http (using Fiddler in this case) as well:
At this point, the communication is established, and the server-based code could map the user to an Active Directory account [impersonate as desired too], or map to some other form of membership store, etc.
Certainly this example could be taken much further but the salient point is that digital certificates and augment the standard username + password authentication to boost security.
Subscribe