36

I'm no security expert, so please just ask in a comment if I haven't made my question clear enough for an answer.

The Scenario

We have a server running WCF services, and a number of clients connecting. These clients are actually Linux PCs which we build. We need to establish secure communications between our server, and our clients (again we build them, and deploy them to customer sites).

Client trusting the server

We will implement this by allowing the client to establish a trusted connection with the server via implementing SSL communications.

Server trusting the client

We now have the task of authenticating the client. Obviously this is done by keeping some sort of credentials on the client. Once the client is connected, it can send the credentials to the server and the server can validate them.

One option for these credentials is to store some sort of Guid or other id/password which is generated by the WCF based application. Upon receiving the credentials, the WCF service does a lookup in the database and verifies they are correct.

Another option is to use Certificate Services to create client certificates which are copied to the client pc before it is sent out. After establishing the secure connection, the client sends the certificate to the server which authenticates the certificate with Certificate Services.

The Questions

What advantages does using a certificate to authenticate the client have over a username/guid? What disadvantages does it have?

Please consider:

  • Security
  • Complexity of implementation
  • Complexity of programming Integration with the application. This includes the workflow of creating the authentication token, associating appropriate (authorization / association) metadata, managing authentication such as disabling access etc.
Shaun Rowan
  • 463
  • 1
  • 5
  • 6
  • http://stackoverflow.com/questions/2164397/why-should-i-authenticate-a-client-using-a-certificate – schroeder May 03 '12 at 21:57
  • Thanks. I read that as well as this: http://security.stackexchange.com/questions/3605/certificate-based-authentication-vs-username-and-password-authentication – Shaun Rowan May 03 '12 at 21:58
  • 1
    I think our scenario is different, since we have explicit and full control over both the client and the server. My question is whether that is significant enough to tilt the optimal solution one way or the other. – Shaun Rowan May 03 '12 at 21:59
  • I think I understand. The question might come down to how important it is to be sure that the uname/guid has not been copied. Certs mean that the web server does the authentication; custom auth db means your app does the work. My belief is that certificate management on the server-side is low effort, so I'm not sure if there would be a savings either way (depending on how you program your custom auth db). – schroeder May 03 '12 at 22:13

2 Answers2

21

Deploying client certs could fit here. The advantages of using a cert over username is somewhat simple. Anyone can type in a username from any client device. If you're using a combination of username with guid, then the "security" or assurance that the client is connecting from a known/authorized client device is dependent on the strength and uniqueness of the guid. If there's a way to clone or spoof the guid (mac addresses can be spoofed fairly easily), then the assurance level would decrease.

Client certificates can be deployed to clients, with or without validity checking (aside from validity date, cn, ski/aki, fingerprint, etc). On-demand validity checking mechanisms such as ocsp would require the server application check with an ocsp server each time client connects/attempts to auth. But from the description, I didn't read that validity checking is as important as being able to tie cert to client device.

One important detail with clients certs (certs in general) is that is can be exported and most implementations do not lock down portability of the cert. Regardless of whether or how the client certs are going to be stored, without proper measures, the cert can be easily copied from device to device. Some implementations store the cert on the filesystem (files that end with .cer, .der, .key, .crt usually are indications that certs are stored in the filesystem). Stronger implementations (application dependent) may store the certs and keys in a keystore (i.e. java key store). The key store can add additional protection like ensuring the private key is not exportable. However, the assurance that the key hasn't been exported is only as strong as the key store itself. Hardware key stores (i.e. smart cards, usb hsm, ironkey, etc) offer a much stronger assurance that private key is not exportable than software key stores.

BTW, the above point also affects server keys. Most implementations store the private key in a software key store and is usually marked exportable. Further, the private key is usually not password protected so anyone with access to the server can walk away with the private key. If a cert can be copied, then it doesn't offer non-repudation.

To answer your question, if there's a good way of leveraging a hardware id of sorts (guid, serial number, cert stored in HSM, etc), that'll likely provide more assurance than using a software-based id (client certs included). Using client certs with password protection enabled for private key access provides a bit stronger validation because not only does a client need to have access to the private key but also the password to use it.

If you do decide to use client certs, then you'll have to build or use an existing PKI infrastructure. Vendors like Codomo, Entrust, Symantec (formerly vrsn, thawte, and geotrust), Godaddy, and a bunch of others offer both public and private infrastructure for use. However the cost of implementing a software-based client cert will likely be higher than using a software based hardware id or perhaps even a hardware-based unique id.

If anything, determine the level of assurance you want to have and decide whether software, software + password, or hardware is sufficient.

bangdang
  • 1,834
  • 11
  • 9
  • Thanks, lots of great comments. In our case, the 'client' is just a device - it has no 'customer' or 'user' interaction. Essentially it's a piece of hardware that's recording data and sending it up to the server. Does this change your answer at all in terms of 'appropriateness' of the competing solutions? – Shaun Rowan May 03 '12 at 22:45
  • 2
    yep - if it's something like an appliance, then the level of assurance really depends on how easy it is for someone to gain meaningful access to the device. Let me take a few steps back and suggest reviewing the risk profile of the device and value of data/connection to an adversary. If the risk is minimal, then a unique identifier approach (software or hardware, although hardware still provides more assurance) is likely the simplest and effective. Client certs can work but you'll still need to manage the certs (validity dates for cert and CA, etc). – bangdang May 03 '12 at 22:49
  • Thanks. The cost of leaking the data is low, and the benefit/motivation for tampering with it is even lower. My argument here is that introducing client certificates implies a high implementation and maintenance cost with very little added security. Would you tend to agree, or disagree with that? – Shaun Rowan May 03 '12 at 23:02
  • 1
    @ShaunRowan I agree with your comment. I've worked with products that, apparently, needlessly implemented client certs for whatever reason and caused more headaches than not because someone forgot to document what happens when certs expire. Client certs introduce additional operational considerations that should be accounted for. – bangdang May 03 '12 at 23:29
20

With client-certificate authentication, the secret (the private key) never leaves the client and doesn't go to the server. Whether you trust the server or not (you should check that first anyway, though), your private key will not be leaked. This is an advantage over traditional form-based or HTTP Basic authentication.

You can even use some hardware cryptographic tokens/smartcards designed in such a way that the private key never leaves the token (the signatures involved in the TLS handshake happen on-board).

If you use client-certificates within the context of a Public Key Infrastructure (most likely), you can also enjoy the benefits offered by the PKI. This is mostly useful for large structures, but you can:

  • Recognise the identity of users you had never registered before.

    This is what Certification Authorities are for. If you trust the CA, you trust the certificate it issues. If unknown users logs on without a pre-existing account onto your system, and if they present certificates that you trust, you will be able to recognise their identities, as vouched for by the CA. You may or may not want to get further details from the user, but the main identity will have been asserted with the CA and will have left an administrative trail there.

  • The same identity asserted by the certificate may be used across multiple independent websites (provided they trust the same CA), possibly used as a form of Single-Sign On.

  • A compromised certificate may be revoked by the CA directly.

  • Via the CA, you decouple the problem of proving the identity of the user from the provision of the service itself. Other methods like OpenID also achieve this goal, but hardly provide the same level of assurance as what CAs can do (provided CAs do their job correctly). The level of assurance will vary depending on the quality of the CA.

    An advantage with this is that you can re-issue a new certificate to the same user with different keys (if the previous certificate has expired or if the private key was compromised) and keep the same identifier (Subject) across all systems that trust this CA.

(You can also use client-certificates outside the context of a PKI, but you have to define your own trust rules, which can be quite tedious.)

Client certificates can also be used independently of the protocol running on top of SSL/TLS. You may even use them for S/MIME for example, if applicable.

Another advantage is that, because the authentication doesn't happen at the HTTP level, it's effectively stateless, if things like the REST architectural style matter to you.

Some web services may also use this for message-level security, thereby potentially leaving an audit-trail for non-repudiation of certain messages if necessary.

The main downside is that you'll need to educate your users to the basic concepts of public key cryptography. This is particularly important if you're not using hardware tokens (but just keeping the certificates and private key within the user's software).

  • Unlike passwords, users won't remember the private key/cert. They'll need to use a machine where the certificate has been installed (or where there is a suitable card reader for hardware solutions). To cut corners, some may be tempted not to take care of their private keys as carefully as they should (they are normally password-protected themselves).

  • When explaining, the notion of "certificate" can be confusing. Even experts shorten sentences sometimes. If you say "use your certificate to log on", what you actually mean is "use the private key and your certificate to log on": the private key is implied in this expression. In contrast, if someone tells you "send me your certificate", you shouldn't use your private key then. If you look around for documentation, you'll find a number of references to PKCS#12 files (.p12 or .pfx) and PEM certificate files (.pem or .crt, typically). Typically, the former contains the private key whereas the second doesn't (although it may also do). All these notions will confuse users unless they know what they're doing.

  • Browser's user interfaces for client-certificates are generally quite poor. It's quite difficult from a UI perspective to log out of a web-site where you've authenticated with a client-certificate for example (like HTTP Basic). (It makes CSRF protection even more important.) If your clients are "machines" and not users via a browser, this is not so much of a problem.

In terms of infrastructure, if you're not willing to use the services of a commercial CA for your client certificates, you will have to deploy your own CA. Note that the CA used for authenticating the clients can be independent of the CA used for authenticating the server. You can run a website with a certificate issued by a well-known CA but have it trust client-certificates from your own CA. There exist various tools for CA management, including open source ones. Some can even do in-browser key generation, so that the private key is ready in the browser (the downside with that is that the user must re-use the same browser to import the certificate once it's issued).

Configuration of the servers require a certain understanding of what the certificates (CA certificates, server certificate), but it's not actually that complicated. Most servers support this one way or another.

Client-certificates only provide you with authentication. You may still need to get further attributes (e.g. from LDAP or a database against the certificates' subjects). You will certainly need to have an authorisation logic on top of this, as it would be for any other authentication system. It's typical to map a Subject DN to a local identifier in your system.

(There are more advanced usages where you can delegate authentication using proxy certificates, or pass authorisation tokens via attribute certificates, but these are more unusual and are not accepted by all software stacks.)

Community
  • 1
Bruno
  • 10,875
  • 1
  • 39
  • 61
  • Question: Are client certs still secure if you're not running over SSL? I'm assuming that someone could sniff out the public key the same way someone could sniff out credentials across the wire? – Remi Despres-Smyth Nov 27 '14 at 15:18
  • 1
    @RemiDespres-Smyth By definition SSL/TLS client-certificate authentication can only be used with SSL/TLS. Sniffing the public key/certificate isn't necessarily a problem since it won't make the cert usable (at worse, an eavesdropper seeing the cert will know the identity of the user). The cert is actually visible in clear if it is exchanged during the initial SSL/TLS handshake, but it can be hidden when using a renegotiated handshake. – Bruno Nov 27 '14 at 16:40