Cryptographic Authentication for Websites
One of the biggest problems with Websites today is from hackers obtaining the username/password database that must be present on the Web server to allow authentication. It is also easy to capture the username/password credentials for a specific user as they are typed in on the client computer via a keyboard sniffer.
All versions of SSL and TLS since SSL 3.0 support “Strong Client Authentication” via a client digital certificate. In the first phase of the SSL/TLS handshake, the server sends its server certificate to the client, which is used for server to client authentication, as well as secure symmetric session key exchange.
An optional second phase allows the server to request that the client send a client certificate to the server. This is used for client to server strong authentication. When this is used, no username or password needs to be supplied (although the user can select an appropriate client certificate from a presented list of installed client certs). Hence a keyboard sniffer cannot obtain a user’s credentials. On the server end, no username/password database is needed, so one of the primary targets for hackers can be eliminated. This would end major security breaches.
The server still must be able to determine the validity of presented client certs, as well as their revocation status. We can provide a utility that will easily and securely obtain and install the CA certs (root and intermediate) of the client cert hierarchy and install in the Web server. We can also provide certificate revocation checking via IRP, or if the Web server supports OCSP, we can provide that information via an OCSP server that gets its information from DIR.
The server can extract the user’s name and email address from the presented client certificate (as well as other information in most cases). There is no need for the user to enter their user name. Authentication is done via a cryptographic challenge/response, so no password is required.
Some browsers are not very clever about how they support Strong Client Authentication. For example, once a certificate is selected, it will be used for every connection until the browser is killed. We can provide an add-in for popular browsers that will manage client certs in a better way, including checking validity and revocation status for all certs used. Perhaps we can work with browser vendors to improve their support for Strong Client Authentication.
This scheme works for any SSL/TLS based server that supports Strong Client Authentication. This includes Mail servers (SMTP, IMAP, POP), directory servers (LDAP), etc. Many email clients include support for X.509 client authentication in lieu of username/password authentication.
The Sixscape solution consist of a standard DIR server, an optional OCSP server, an IRP-enabled add-in on the SSL/TLS server (for obtaining the CA certificates of the client certificate hierarchy and doing revocation checking), and also add-in for the browser side.