SecureBlackbox 16: Building user authentication systems for client-server environments

Contents

• Abstract
• The SSL Approach
• Certificates Only

Abstract

Authentication is used in almost all areas of human activity. The most common authentication mechanisms are human photos on documents, fingerprints, and similar physical entities. In the computer world there are certain equivalents like username/password or more recent inventions like certificates.

Username/password is an easy to understand approach that doesn't require any special software on the client side and can be managed by anybody. You can remember this information quite easily or write it down somewhere. However, this is also a disadvantage - the username/password pair is easy to steal, intercept, or just guess. Also, there is no standard format or specification for the contents of the username/password and most people use passwords that are easy to find out using a plaintext or brute force attack.

X.509 certificates are blocks of information that are usually given to the user by Certificate Authorities (see the introduction to X.509 Certificates in Certificate Basics). Most often they are used to identify web servers in e-commerce operations. However, the extensive features of X.509 certificates make it possible to use them for client authentication too.

Important Certificate Fields

The certificate contains certain fields that are especially interesting for us. They are the following:

1. Subject name: This is the field that contains the name of the person whose identity the certificate confirms.
2. Valid From and Valid To fields: These fields define time constraints, i.e., the period during which the certificate is valid.
3. Extensions: Each certificate can contain one or more extensions, which you can use to (a) determine the scope of use of the certificate and (b) store your custom data (for example, the list of groups the user is a member of).
4. Subject Key Identifier extension: It uniquely identifies the certificate.

There are two ways of employing X.509 certificates for use as an authentication solution:

• If your distributed application uses connections that you control (this can be TCP or named pipe connections), you can add support for the SSL/TLS protocols (see Introduction to SSL) and use certificates during the SSL session.

• If you use some information exchange system that is beyond your control (for example, some middleware library that doesn't support SSL or supports it partially), you can use certificates anyway. Both ways have their advantages and drawbacks.

The SSL Approach

SSL enables you to secure the data exchange session and allows transparent client identification. When the SSL session is established, the client and server exchange certificates. At this stage, the server can check the certificate's validity and find out if the user who presents the certificate is allowed to access the server. If the certificate is issued by the server (and it is possible to store custom data in the certificate), information about the scope of functions available to the user can be kept right in the certificate extensions. If the client uses certificates issued by well-known Certificate Authorities (such as Thawte or VeriSign), such information can be stored on the server, separately for each user.

The main disadvantage of this approach is that the certificate together with its public key can be stored on the client side. This can be unacceptable when the user accesses the server from more than one client system (desktop, PDA, etc.) or from a public terminal. One of the possible solutions is to keep the certificate on some storage like a smart card or USB dongle, but this requires software support from the client system.

Validating Client Certificates

The typical sequence of actions when validating a client certificate is the following:

1. (Optional) The server administrator generates certificates for users (certificate generation is beyond the scope of this article). This step is not needed when the users already have proper certificates (for example, their valid and authenticated email certificates).


2. The server administrator adds the certificate (with the public key) to the list of known certificates. The list can contain the certificate in whole or the value of the Subject Key Identifier extension or a combination of the values of the Issuer name and Certificate Serial Number.


3. When the SSL session is established, the server requests the client certificate. If the server receives the certificate, the server application must follow the steps below to validate it:
1. Search the list of known certificates to find out whether the subject (the owner) of the certificate is in the list of people allowed to access the server.
2. Validate the certificate itself (see below).


4. If the data was properly encrypted and the certificate was validated, the server can create some "session" object that will define that during the connection this client is allowed to perform certain actions.

In SecureBlackbox, both client and server components have OnCertificateValidate (ElSecureClient.OnCertificateValidate and ElSecureServer.OnCertificateValidate) events. Your application can validate the certificate using ElCustomCertStorage's Validate method. This method checks the certificate to find out if it is properly signed and its time of validity includes the current time. You can also do additional checks according to your internal rules. For example, you can include time constraints (e.g., 9 am to 6 pm) to the certificate and check these constraints when the certificate is presented.

Certificates without SSL

The use of certificates as independent entities (without SSL) is possible with or without usernames and passwords. If you keep the certificates on the user's computer, the username and password are not necessary because the certificate replaces them. The disadvantage of keeping the certificate on the client side is the same as in the case of the SSL approach - it is necessary to make sure that certificates are secure. The private key is, however, in the user's hands, and the server never accesses it. This is a benefit if the certificate is used for purposes other than communicating with this server (e.g., for signing email).

A Scenario with Certificates Only

A typical scenario is the following:

1. (Optional) The server administrator generates certificates for users. This step is not needed when the users already have proper certificates (for example, their valid and authenticated email certificates).
2. The server administrator adds a certificate (with the public key) to the list of known certificates. The list can contain the certificate in whole or the value of the Subject Key Identifier extension or a combination of the values of the Issuer name and Certificate Serial Number.
3. During the initial data exchange the client gives the server the public part of the certificate (i.e., the certificate without the private key).
4. The server application must perform the following steps to validate the certificate:
• Search the list of known certificates to find out whether the subject (the owner) of the certificate is in the list of people allowed to access the server.
• Validate the certificate itself (see above).
• If the certificate is not valid, close the session.
5. The server creates a "session key", encrypts it with the public key of the certificate, and sends the encrypted information to the client. The client and server later use the session key to encrypt the application data that they transfer to each other.
6. The client uses the private key of the certificate to decrypt the information received from the server and extract the session key.
7. The client uses the session key to encrypt something (for example, the certificate issuer name and serial number) and send it to the server.
8. The server uses the session key to decrypt the information and get the certificate issuer name and serial number. The decrypted data is compared with the one contained in the certificate -- if it's OK, go ahead.
9. If the data was properly encrypted and the certificate was validated, the server can create some "session" object that will define that during the connection this client is allowed to perform certain actions.

A Scenario with a Certificate Plus the Username and Password

There are times when the user must provide the username and password to access some resource, for example, a database.

1. The server administrator generates a list of unique usernames and passwords. This list is stored on the server in such a way that each username/password pair corresponds to some certificate(s).
2. Steps 2-8 are as described above.
3. If the data was properly encrypted and the certificate was validated, the server can create some "session" object. The session object will contain the username and password from the list. This pair is used to access the resource.

Although certificates are quite flexible and powerful, there are, as mentioned, certain problems associated with them. One quite serious problem is the confusion that the certificate scheme can cause among the users. Also, protecting certificates is usually harder than protecting passwords (due to the certificate's private key size).

In this case it is possible to employ the username/password scheme while maintaining the certificates on the server. When a new user record is created, the server generates a certificate and a private key. The certificate is then stored in two forms: the certificate in its regular DER form (with the public key only) and in encrypted form (in PEM format) together with the private key.

Saving the Certificate

The certificate can be saved to the regular DER format with a call to the X509Certificate.SaveToStream() method.

DER format is binary and can be stored in a BLOB field of the database.

The certificate can be saved to PEM format as follows:

1. Save the certificate with its public key using the X509Certificate.SaveToStreamPEM() method.
2. Save the certificate's private key using the X509Certificate.SaveKeyToStreamPEM() method.

The generated PEM stream contains text data that can be stored in a MEMO field of the database.

The following example shows how the user database could be structured:

1. Username: String (as you like). Unique. Primary key. This is the name of the user who owns the certificate.
2. ValidFrom: DATE. This is the time when the certificate becomes valid. The value corresponds to the ValidFrom field of the certificate.
3. ValidTo: DATE. This is the time when the certificate expires. The value corresponds to the ValidTo field of the certificate.
4. CertPublic : BLOB. The certificate in DER format. This field is optional.
5. CertPEM : MEMO. The certificate in PEM format.

Logging In

When the user logs in, the following sequence of operations is performed:

1. The server searches for the record using the Username field.
2. The user's password is checked as follows: the certificate in PEM format is decrypted and checked for consistency (the certificate must correctly load itself from the stream).
3. The validity period is checked. If the certificate has expired, the server can generate a new certificate and request that the user change the password.

The benefit of this approach is that the certificates can be used not only for access to the server, but also for establishing a secure SSL session with a third party on behalf of the user.

Examples

• A remote server requires (or prefers) SSL connections. This server utilizes a custom protocol. The client software that your users have doesn't work with SSL but it works with SOCKS proxies. What you can do is write a simple SOCKS proxy that becomes a client in the SSL connection. But, the user can't pass you a certificate. He can only give you the SOCKS username and password. Then your proxy finds the user certificate in the database and sends it as a client certificate in the SSL conversation.

• A mail server automatically signs outgoing email based on a user's username and password. The usefulness of such an approach is to ensure that the employee of the organization, and not a fraudulent person, sent the email.

• Certificates can also be used to sign or encrypt the data stored by the server. This allows users to safely store their private documents on the server or sign the files they submit to a common repository. One thing to remember is that you must keep the revoked certificates (the certificates that are inactive due to expiration or because their private key became well-known, etc.) in the database so that older signed or encrypted documents can be accessed.

Each of the schemes has its own uses and benefits; SecureBlackbox components like ElSimpleSSLClient and ElSimpleSSLServer provide the straightforward functionality and enterprise-class security features you need to build user authentication systems using any of these schemes.