First off, certificates don't provide security, encryption does. The certificates are used in the encryption/decryption process and are shared between systems so that those systems have the same key.
That said, there are actually a couple ways to send usernames and passwords securely. Over the network you can use good old SSL. In this case, the network encapsulates packets bound for another system through an encrypted tunnel. The SSL certificate is shared between the initiating system and the end point.
On the identity management level, you can use encryption technologies like federation and Kerberos to pass session-based authentication tokens instead of usernames and passwords. But keep in mind that the source and destination must support these alternative authentication methods or have the ability to have these services added to them.
At the application level, it's possible to encrypt the entire packet using the destination's public PKI certificate, but you must have the ability to decrypt the packet with the destination's private PKI certificate before you can present it to the application. Whether you use network-, identity management- or application-specific encryption technologies, access to the certificate used in the encryption process must be managed and protected if you want to ensure the security of the content.
While public keys should be stored on an openly available repository, private keys or symmetric keys should be issued using a key management software tool according to a process that ensures they are securely distributed (out of band, secure email, pull technologies to a Web service, etc.). This may seem like it trades the process of protecting one data element (username/password) for another, but managing a set of keys is much less cumbersome than managing many credentials.
For more information:
- Learn more about PKI and digital certificates in this authorization guide.
- What is most misunderstood about EV SSL certificates? Read more.
This was first published in November 2009