authentication
Building user authentication systems for client-server environments.
Abstract:
Authentication of people is used in almost all areas of human activity. Most common authentication mechanisms are human photos on documents, fingerprints and similar physical entities. In computer world there are certain equivalents like username/password or more recent invention like certificates.
Username/password is an easy to understand approach that doesn't require any special software on 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 - username/password pair is easy to steal/intercept or just guess. Also, there is no standard format or specification for contents of username/password and most people use passwords that are easy to find out using either plain text or brute force attack.
X.509 certificates are blocks of information that are usually given to the user by Certificate Authorities (see introduction to X.509 Certificates in "Certificate basics" article). Most often they are used to identify web servers in e-commerce operations. However extensive features of X.509 certificates make it possible to use them for client authentication too.
The certificate contains certain fields that are especially interesting for us. They are:
Subject name. This is the field that contains the name of the person whose identity the certificate confirms;
Valid From and Valid To. These fields define time constraints, i.e. the period during which the certificate is valid;
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, whose member the user is).
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 connection), you can add support to SSL/TLS protocols (see introduction to SSL in "Introduction to SSL" article), and use certificates during 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.
SSL approach
SSL lets you secure data exchange session and allows transparent client identification. When SSL session is established, client and server exchange certificates. On this stage the server can check certificate validity and find 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 scope of functions available to the user can be kept right in 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 it's public key can be stored on client side. This can be unacceptable when the user accesses the server from more than one client system (desktop, PDA etc.) or from public terminal. One of possible solutions is to use some storage like smart card or USB dongle to keep the certificate, but this requires software support from client system.
Typical sequence of actions when validating client certificate is:
(Optional) Server Administrator generates certificates for users (certificate generation is described in a separate article,"Generating X.509 certificates"). This step is not needed when the users already have proper certificates (for example, their valid and authenticated e-mail certificates).
Server Administrator adds a certificate (with public key) to the list of known certificates. The list can contain the certificate in whole or the value of Subject Key Identifier extension or combination of the values of Issuer name and Certificate Serial Number.
When SSL session is established, the server requests client certificate. If the server receives the certificate, the server application must validate it, i.e.
Search the list of known certificates to find out, whether the subject (owner) of the certificate is in the list of people, allowed to access the server;
Validate the certificate itself (see blow).
Once the certificate is validated, the server can create some "session" object that will define that during the connection this client is allowed to do certain things.
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 it's validity time includes 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 certificate and check these constraints when the certificate is presented.
Certificates only
Use of certificates as independent entities (without SSL) is possible with or without usernames and passwords. If you keep certificates on user's computer, username and password are not necessary because the certificate replaces them. The disadvantage of keeping the certificate on client side is the same as in the case of SSL approach - it is necessary to make sure that certificates are secure. The private key is, however, in 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 e-mail).
Typical scenario of this way is:
(Optional) Server Administrator generates certificates for users (certificate generation is described in a separate article,"Generating X.509 certificates". This step is not needed when the users already have proper certificates (for example, their valid and authenticated e-mail certificates).
Server Administrator adds a certificate (with public key) to the list of known certificates. The list can contain the certificate in whole or the value of Subject Key Identifier extension or combination of the values of Issuer name and Certificate Serial Number.
During initial data exchange the client gives the server public part of the certificate (i.e. the certificate without private key).
The server application must validate the certificate, i.e.
Search the list of known certificates to find out, whether the subject (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.
The server creates "session key", encrypts it with public key of the certificate and sends the encrypted information to the client. The client and server later use session key to encrypt the application data that they transfer to each other.
The client uses private key of the certificate to decrypt the information received from the server and extract session key.
The client uses session key to encrypt something (for example, certificate issuer name and serial number) and send it to the server.
The server uses session key to decrypt the information and get certificate issuer name and serial number. The decrypted data is compared with the one contained in the certificate. If it's ok, go ahead.
If the data was properly encrypted and the certificate was validated, the server can create some "session" object that will define that during connection this client is allowed to do certain things.
There are times, when the user must provide the username and password to access some resource, for example the database. Then the above scenario is modified as follows:
Server Administrator generates a list of unique usernames and passwords. This list is stored on the server in the way that each username/password pair corresponds to some certificate(s).
2-8. (as described above)
If the data was properly encrypted and the certificate was validated, the server can create some "session" object. Session object will contain username and password from the list. This pair is used to access the resource.
Although certificates are quite flexible and powerful thing, there are, as mentioned, certain problems associated with them. One of quite serious problems is confusion that certificate scheme can cause among the users. Also, protecting certificates is usually harder then protecting passwords (due to 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 new user record is created, the server generates a certificate and a private key (certificate generation is described in a separate article,"Generating X.509 certificates"). Certificate is then stored in two forms: the certificate in its regular DER form (with public key only) and in encrypted form (in PEM format) together with private key.
The certificate can be saved to regular DER format with call to X509Certificate.SaveToStream() method.
DER format is binary and can be stored in BLOB field of the database.
The certificate can be saved to PEM format as follows:
Save the certificate with it's public key using X509Certificate.SaveToStreamPEM() method.
Save the certificate's private key using X509Certificate.SaveKeyToStreamPEM() method
The generated PEM stream contains text data that can be stored in MEMO field of the database.
The structure of the user database can be
Username: string [as you like]. Unique. Primary key. This is the name of the user who owns the certificate.
ValidFrom: DATE. This is the time when certificate becomes valid. The value corresponds to ValidFrom field of the certificate.
ValidTo: DATE. This is the time when certificate expires. The value corresponds to ValidTo field of the certificate.
CertPublic : BLOB. The certificate in DER format. This field is optional.
CertPEM : MEMO. The certificate in PEM Format.
When the user logs in, the following sequence of operations is performed:
The server searches for the record using Username field.
User's password is checked as follows: the certificate in PEM format is decrypted and checked for consistence (i.e. the certificate must correctly load itself from the stream).
Validity period is checked. If the certificate has expired, the server can generate new certificate and request the user to change the password.
The benefit of this approach is that the certificates can be used not only for access to server, but also for establishing secure SSL session with third-party on behalf of the user.
Example: there is some remote server that requires (or prefers SSL connection). This server utilizes 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 SSL connection. But the user can't pass you a certificate. He can only give you SOCKS username and password. Then your proxy finds user certificate in the database and sends it as a client certificate in SSL conversation.
Another example is a mail server that automatically signs outgoing e-mail based on user's username and password. Usefulness of such approach is to ensure that employee of the organization, and not a fraudulent person, sent the e-mail.
Also, certificates can 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 common repository. One thing to remember is that you must keep 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.
As you see, each of the schemes has it's own uses and benefits. And no matter what scheme you use, SecureBlackbox will be very helpful.