#cryokey

In my previous post, you learned how to set up a MySQL server to recognize CryoKey credentials. You also learned how to set up the MySQL command line tools to automatically present the CryoKey credentials when establishing database connections.

In practice, most people don't use command line tools to access databases. Therefore, I wanted to demonstrate how you would use CryoKey credentials to access MySQL in more typical database usage scenarios:

MySQL Workbench, a popular MySQL database management tool

Perl DBI with MySQL DBD

PHP with the MySQL Improved ('mysqli') API

PHP with ADODB

--- MySQL Workbench

MySQL Workbench is a powerful visual interface for the MySQL database system. You can use it to set up the MySQL SSL configuration to support CryoKey. However, as of right now (Workbench v5.2.37), you can't actually set up certificate-based database user accounts from the user interface. Therefore, you'll still need to use the 'GRANT' command with the 'REQUIRE SUBJECT' directive to manage access.

Either create or open a server instance. You will see the server dashboard:

To manage SSL configuration, go to the Security tab under Configuration->Options File:

To check the configuration (or availability) of SSL, look for the 'have_ssl' value of a server's System Variables tab under Management->Status and System Variables:

After you set up the server, you need to set up certificate-based accounts. Look at my previous post for details on how to get a user's CryoKey subject string and associate it with the account. To recap, first acquire CryoKey credentials. Then get the user's CryoKey subject string:

# openssl pkcs12 -in cryokey.pfx -clcerts -nokeys -out my.crt # chmod 0444 my.crt # openssl pkcs12 -in cryokey.pfx -nocerts -nodes | openssl rsa -out my.key # chmod 0400 my.key # openssl x509 -in my.crt -noout -subject | sed 's/^subject=\s*//'

Then, connect to the database as an administrator and link the user's CryoKey subject string in a 'GRANT':

mysql> GRANT ALL PRIVILIGES ON [database].* TO '[name]'@'[host]' REQUIRE SUBJECT '[CryoKey subject string]';

When creating or editing connections to databases in MySQL Workbench, you can specify the user's CryoKey credentials from the Advanced tab in the connection settings:

Note that shell variable expansion is not available. Therefore, use absolute paths for the certificate and key files, because the working directory may vary (under a typical Kubuntu 12.10 installation, the working directory would be 'Documents' in your home directory). If you connect using 'TCP/IP over SSH', the certificate and key files are relative to the user's account on the SSH server.

Click 'Test Connection' to see if you set up the connection properly. If the test succeeds, click 'OK' to apply the changes.

--- Perl DBI

Using CryoKey credentials to access MySQL databases is fairly simple under Perl DBI. Perl's MySQL DBD allows you to specify your CryoKey certificate and key files in the data source name. Just remember that the paths are relative to the current working directory.

This sample script opens a connection to a database called 'testdb' on a local MySQL server. The user, 'dbuser', will try to connect using the certificate from 'my.crt' and the key from 'my.key' located in the current working directory.

#!/usr/bin/perl use DBI; use strict; use warnings; my $dbname = "testdb"; my $hostname = "localhost"; my $username = "dbuser"; my $key = "my.key"; my $certificate = "my.crt"; my $dsn = "DBI:mysql:database=${dbname};host=${hostname};mysql_ssl=1;mysql_ssl_client_key=${key};mysql_ssl_client_cert=${certificate}"; my $db = DBI->connect($dsn, $username) or die "Can't connect: $DBI::errstr\n"; my $results = $db->selectall_arrayref("SHOW STATUS LIKE 'ssl_cipher'"); foreach my $i (@$results) { foreach my $j (@$i) { print "[$j] "; } print "\n"; } $db->disconnect();

Running it should output something like:

[Ssl_cipher] [DHE-RSA-AES256-SHA]

If the value is '[]' (empty), then something went wrong; make sure the certificate and key files are valid, and make sure the MySQL server has been set up for SSL.

--- PHP MySQL Improved (mysqli_*)

Direct certificate support is available to the 'mysqli' API, but not the older 'mysql' API. To specify a certificate, you use mysqli_init() to create a connection object, ssl_set() to specify the certificate and key, then real_connect() to open the connection. Afterwards, use the connection normally.

<html> <head> <title>CryoKey MySQL</title> </head> <body> <?php $dbname = 'testdb'; $hostname = 'localhost'; $username = 'dbuser'; $db = mysqli_init(); $db->ssl_set('my.key', 'my.crt', NULL, NULL, NULL); $db->real_connect($hostname, $username, NULL, $dbname); $result = $db->query("SHOW STATUS LIKE 'ssl_cipher'"); echo "<table border='1'>"; while ($row = $result->fetch_row()) { echo "<tr>"; foreach ($row as $cell) { echo "<td>{$cell}</td>"; } echo "</tr>"; } echo "</table>"; $db->close(); ?> </body> </html>

Running the script should output something like:

If the 'Ssl_cipher' field is empty, then something went wrong; make sure the certificate and key files are valid, and make sure the MySQL server has been set up for SSL.

--- PHP ADODB

The current version of ADODB doesn't let users specify SSL connection parameters. However, you can work around this limitation by specifying a certificate and key in the system options file (normally '/etc/mysql/my.cnf' as of MySQL v5.1.15). Simply add the SSL connection parameters to the '[client]' section:

... [client] ... ssl-cert=/etc/ssl/certs/mysql.pem ssl-key=/etc/ssl/private/mysql.key ...

Remember that, if you don't provide absolute paths, the files will be relative to the script's working directory. Make sure to set the certificate and key file permissions properly, or else everyone will have access to the credentials! In our example (and typical Linux distributions), system keys go in '/etc/ssl/private' with mode 0440 and group 'ssl-cert'. We also put system certificates in '/etc/ssl/certs' with mode 0444. Any users that need access to the system keys should be in the 'ssl-cert' group.

Then, use ADODB to connect using the 'mysqli' driver. You will need to set the 'MYSQL_CLIENT_SSL' client flag:

<html> <head> <title>CryoKey MySQL</title> </head> <body> <?php include_once("adodb5/adodb.inc.php"); $dbname = 'testdb'; $hostname = 'localhost'; $username = 'dbuser'; $db =& ADONewConnection("mysqli"); $db->clientFlags = MYSQL_CLIENT_SSL; $db->Connect($hostname, $username, NULL, $dbname); $db->SetFetchMode(ADODB_FETCH_ASSOC); $results = $db->Execute("SHOW STATUS LIKE 'ssl_cipher'"); if ($db->ErrorNo() == 0) { while (!$results->EOF) { $row = $results->FetchRow(); print_r($row); $results->MoveNext(); } $results->Close(); } ?> </body> </html>

If successful, you'll see a line that looks like:

Array ( [Variable_name] => Ssl_cipher [Value] => DHE-RSA-AES256-SHA )

If the value is empty, then something went wrong; make sure the certificate and key files are valid, and make sure the MySQL server has been set up for SSL.

This workaround has its limits. The files are usually relative to the current working directory. Therefore, the certificate and key must be in the same directory as the running PHP script, which leaves the key vulnerable. You can always use absolute paths to put the files somewhere less accessible. Or wait for ADODB to add more thorough MySQL SSL connection support.

MySQL's certificate support is very basic right now. While it certainly has room for improvement, most users generally don't use SSL connections, preferring to stick with username/password/host access controls. Right now, SSL connections are mainly used for the secure communications, especially during replication. Therefore, development on such support isn't a high priority, but the support should improve if more people start using MySQL's SSL capabilities.

Still, CryoKey credentials can work with MySQL despite the current state of support. They're especially useful for scripted database access. You may be asking, "Why bother?" Well, some people may want the added assurance of certificate based authentication, especially when combined with normal passwords. Besides, you may want to connect using an encrypted connection, and authenticating with CryoKey credentials isn't such a big leap if you're already connecting over SSL anyway.

If you do use CryoKey for database authentication, consider using a system identity (as opposed to a personal identity). For instance, you could generate credentials for [email protected] if you can get mail for that account (maybe through a forwarding mechanism).

If your favorite sites don't recognize CryoKey just yet, don't fret! CryoKey still has other useful applications.

CryoKey's manual-install credentials are well suited for any software that makes secure connections over SSL. The popular MySQL database system is one great example. Starting from version 4.0, MySQL has been capable of authenticating and encrypting SSL connections, but the support is very primitive and rarely used. So today, I'd like to talk about using CryoKey for MySQL user identification.

Normally, to use client certificate authentication in MySQL, an administrator needs to set up a private certificate authority and manage certificates, keys, and configurations. CryoKey eliminates the hassle by handling all of the certificate authority duties for you. You can simply treat the CryoKey authority as a certificate dispenser.

This example was based on a Linux (Kubuntu 12.10) installation, but should be equivalent for any other distribution.

--- SETTING UP THE MYSQL SERVER

If you haven't done so yet, install MySQL v4.0 or later compiled with SSL support.

# sudo apt-get install mysql-server

The typical MySQL packages found in most distributions will have SSL support. To see if SSL is available in your MySQL server installation, just try to start the server with an SSL option such as 'mysqld --ssl --help'. If you get an error like '[ERROR] mysqld: unknown option '--ssl'', then your MySQL was not compiled with SSL.

Download the CryoKey Certificate Authority (CA) Certificate. You can always get the latest CA certificate bundle using:

# wget https://www.cryokey.com/ca.pem

Get a certificate and key for the server. MySQL requires the server to have a certificate and key, even though they're not that useful to MySQL. If you have a SSL certificate/key for your web server on the same machine, you can theoretically use the same certificate/key. You can also ask CryoKey to generate self-signed test credentials at https://www.cryokey.com/public/selfsign.php. Then, extract the certificate and key:

# wget https://www.cryokey.com/public/selfsign.php -O cryokey.pfx # openssl pkcs12 -in cryokey.pfx -passin pass: -clcerts -nokeys -out certificate.pem # openssl pkcs12 -in cryokey.pfx -passin pass: -nocerts -nodes | openssl rsa -out key.pem

Once you extract the certificate and key, you can delete the 'cryokey.pfx' file.

You should now have three files: 'ca.pem', 'certificate.pem', and 'key.pem'. Recent Linux distributions confine the MySQL server with AppArmor. The default MySQL server AppArmor profile normally allows the server to read files with a '.pem' suffix from the MySQL configuration directory. Therefore, you should put these files with the rest of the MySQL configuration files in '/etc/mysql' (or just /etc prior to MySQL v5.1.15).

# sudo install -m 0644 ca.pem /etc/mysql # sudo install -m 0444 certificate.pem /etc/mysql # sudo install -m 0400 key.pem /etc/mysql

Note that the key file should only be readable by the owner (root).

mysqld can take command line parameters to enable SSL, but we'll be making modifications to the options file instead. The MySQL server normally starts at system startup, so changing the options file is more practical than modifying startup scripts or upstart configurations.

Add the following lines to the '/etc/mysql/my.cnf' file under the '[mysqld]' section:

... [mysqld] ... ssl-ca=/etc/mysql/ca.pem ssl-cert=/etc/mysql/certificate.pem ssl-key=/etc/mysql/key.pem ...

Now just restart the server:

# sudo service mysql restart

To see if everything is working, run this MySQL query:

> SHOW VARIABLES LIKE 'have_ssl';

If the 'have_ssl' variable has a value 'YES', then your server is ready for SSL!

--- SETTING UP THE USER

Each user will need his own certificate and key. The user should complete the CryoKey verification process and download the manual install file (usually 'cryokey.pfx'). After downloading the credentials, extract the certificate and key (using the given PIN code):

# openssl pkcs12 -in cryokey.pfx -clcerts -nokeys -out user.crt # chmod 0444 user.crt # openssl pkcs12 -in cryokey.pfx -nocerts -nodes | openssl rsa -out user.key # chmod 0400 user.key

Once you extract the certificate and key, you can delete the 'cryokey.pfx' file. Note that the key is not password protected, so it's vulnerable to theft. You will have to protect it more carefully. Also, be aware that certificates do expire; currently, the manual install certificates are only valid for 30 days. (We're likely going to increase the duration as time goes on.)

The 'mysql' command line client can take arguments to specify your credentials. However, to simplify command lines (and make the credentials available to other applications), you should instead update your user-specific '$HOME/.my.cnf' under the '[client]' section:

... [client] ... ssl-cert=user.crt ssl-key=user.key ...

With the options file properly set up, you will automatically attempt to authenticate with your CryoKey credentials when you connect to any MySQL server (without needing additional command line arguments). Note that the files are relative to the current working directory. You can use absolute paths if you like, but shell expansion is not available in the options file (so you can't use '~/user.crt' or '$HOME/user.key' in the options file).

You're not done yet! You will need to know the certificate subject string to associate a database user account with your credentials. To get the subject string:

# openssl x509 -in user.crt -noout -subject | sed 's/^subject=\s*//'

You'll see something that resembles '/C=us/O=*/OU=1/[email protected]'.

--- MYSQL USER ACCOUNT MANAGEMENT

Now you need to bind user accounts to CryoKey credentials using the MySQL 'GRANT' request. Specify 'REQUIRE SUBJECT' with the user's certificate subject as an argument. You can also (optionally) specify 'REQUIRE ISSUER' with CryoKey's CA certificate subject, which should always be '/C=us/O=CryoKey/OU=Authority/CN=www.cryokey.com'. If you specify both the subject and issuer, you can just use 'AND' to link the directives:

> GRANT ALL PRIVILEGES ON [database].* TO '[name]'%'[host]' REQUIRE SUBJECT '[user certificate subject]' AND ISSUER '/C=us/O=CryoKey/OU=Authority/CN=www.cryokey.com';

Only one subject string can be associated with a database user. You can always change the associated credentials by running the 'GRANT' request again for a user/host with a new subject string.

If the user has set up the options file correctly, he can now authenticate with MySQL using the CryoKey credentials over SSL:

# mysql -u [name] [database]

If the account requires SSL, then opening a non-SSL connection will fail (with a 'SSL connection error' or some variant). When you successfully connect with the appropriate credentials, you can use the MySQL '\s' command to examine the connection. The 'SSL' line should show the cipher in use. (If it says 'Not in use', then you didn't authenticate with SSL; in fact, you are not even on an SSL link!)

--- NEXT STEPS

Following these steps will allow you to authenticate and encrypt your connections with SSL. Note that all communication will be encrypted in this connection. You do pay a price in performance, especially when establishing a connection. Therefore, we highly encourage persistent connections if you use SSL with MySQL.

Every day, people have to "log in" to various sites and services in order to access their personal content. But have you ever wondered about what actually goes on when you "log in"?

If you can understand what happens during a "log in" flow, then you may start to see why integrating external authorities into existing systems has historically been so difficult. In the past, the security industry spent a lot of time trying to improve security while sacrificing usability. Today, the industry puts more emphasis on usability, but the improvements are usually user facing. Integration with existing systems can still be very difficult, and remains a major hurdle in acceptance of new authentication schemes.

The concept of "logging in" is actually rather ambiguous, but generally refers to a process that eventually grants a user privileges to protected resources. We can divide the act of "logging in" into four parts:

Identification: Who are you?

Authentication: Prove that you are who you claim you are.

Session Management: Establish a working relationship based on the credentials.

Access Control: Under the current session, what can you do?

The main purpose of identification is to distinguish yourself from the other users. Your identity can be any kind of distinguishing feature. It can be your real name, an alias, or even conceivably just a picture. An identity can contain additional information such as a photograph or other personal details (like the information found on a driver's license). Online, your identity is basically your username.

Once you declare your identity, you must now prove that the identity does, in fact, belong to you. The authentication process usually involves a challenge of some sort. The most common challenge is a password, and other factors (such as biometrics and physical tokens) can come into play as well.

If you pass the challenge, you can establish a relationship with the service. Now, HTTP is connectionless and stateless, so web services will often symbolize the relationship in a reusable session token, sort of like a ticket stub that grants re-entry. (Otherwise, you'd have to go through a challenge for every request.) The context of a session - who generates and manages them, where it's valid, when it expires - will vary. When you "log out", you are explicitly breaking the relationship so that the service will no longer recognize you.

Now, a session doesn't actually imply any privileges. Services grant privileges based on access control rules which apply to the session user. Access control behavior is extremely service-dependent, and generally involves more granular permissions. But the rules do play a role in what a user perceives as "logged in". For example, the rules may refuse access at certain times of day, or require periodic re-authentication, even with a valid session.

Some examples of different "log in" flows:

SSH: Identify yourself with a username, then authenticate with a cryptographic challenge. SSH works on top of a stateful, persistent TCP connection, which effectively manages the session. Access control comes from standard operating system user permissions.

This flow is just one example of a basic connected service. SSH is very flexible, and other authentication schemes are possible, such as passwords or even digital certificates. However, most SSH authentication uses anonymous RSA or DSA keys. Therefore, even though you may not need a password to authenticate, you still need a way to specify an identity.

Standalone Services (such as MediaWiki and WordPress): Identify yourself with a user name, then authenticate with a password. HTTP connections are stateless/connectionless, so to avoid logging in for every request, they store session IDs in local storage (cookies), and store session context in a database. Access control is based on user privileges stored in a particular instance's database.

The "log in" flows of these popular wiki and blog implementations are typical of most online web services. They do allow external authentication, though they tightly couple the four components. As a result, incorporating an external authentication scheme is like hammering a square peg into a round hole; it's possible, but it's not easy, and the result is far from pretty.

Services using OpenID: Identify yourself with a username and authenticate with a password against an OpenID provider. The service usually has to link your OpenID username with a locally recognized identity. Generally, the service you're trying to access manages its own session and access controls.

In effect, you identify and authenticate against an OpenID provider, and the service manages its own session and access controls. The chosen OpenID provider, however, has its own session and access controls, which may affect the "log in" experience in unexpected ways.

Services using Facebook Login: Identify yourself with your Facebook username (E-Mail address), authenticate with your Facebook password. The service will establish its own session with the user, and apply its own access controls.

Facebook Login is complicated, but for typical web site authentication, you generally "link" an account on the service to your Facebook account (following more or less the OAUTH specification). You first "log in" to Facebook to receive a token. You pass this token to the service, which then uses it to establish a session with Facebook and retrieve the user identity.

As you can see, services typically want to manage their own sessions and access controls. They are, however, more easily able to delegate the identification and authentication tasks. Unfortunately, once you involve external authorities in the "log in" flow, the behaviors of the external authorities start to creep into the "log in" experience. For example, OpenID and Facebook Login have their own sessions and access controls that play a role in the overall "log in" flow. Overlapping functionality adds confusion over who is responsible for what.

In addition, some authorities like Facebook Login have their own agenda. Facebook Login caters to the interests of the main Facebook service, and the specification evolves to meet their own needs. As some StackOverflow users observe, Facebook Login has changed a lot in the not-too-distant past, and as it changes, Facebook just drags the developer community with them whether they like it or not.

Ideally, an external authority is a dedicated third party that doesn't carry the baggage of additional capabilities or requirements. External authorities should focus only on identification and/or authentication, which are the two parts that are easiest to delegate. All external authorities must be able to satisfy some basic integration concerns:

How do I get the identity of the user?

Who should verify the identity?

How much do I trust the authorities that verify the identity? (Is their authentication scheme appropriate?)

What happens if the authority is compromised or not otherwise accessible?

If the external authority includes session and access control capabilities, some additional questions may apply:

Who initiates and terminates a session? (Can it be done by the external authority?)

Who is responsible for the privileges? (What privileges should I associate with the session?)

What happens when a session/privilege on the authority changes?

Organizations that have balked at the monumental engineering task of integrating an external authority in the past should take another look at today's new authorities. The recent crop of dedicated authorities all have a much smaller integration footprint. In fact, some authorities such as YubiKey and CryoKey don't involve any sort of session or access control at all. Even if you are a one-man shop with little time, you should be able to make use of one of the modern external authorities, given the options available.

Multi-factor authentication has been pretty effective to date for protecting accounts. Probably the most recognizable second factor (to the general population) has been one-time passwords (OTPs) or those short term PINs found in RSA tokens. Various groups such as E-Trade and even Blizzard have deployed a form of these tokens, where authentication relies on your actual username/password combined with the current code on the token's display. Other organizations such as Google have come up with their own second-factor OTP solution based on SMS.

With multiple authentication factors, if an attacker should defeat one scheme, then the other scheme(s) would still be able to protect the user. For example, when hackers stole RSA's master secrets back in 2011, they didn't automatically gain access to the accounts of every RSA token user. Security may have weakened, but access still depended on other factors (typically the original passwords of individual users).

The RSA breach also demonstrates that compromising an authority is basically equivalent to compromising the authentication factors that it represents. The factors in use wouldn't matter, since hackers could theoretically have the power to steal passwords, generate new tokens, or reassign biometric signatures, among other mischief.

Sadly, no authority is invincible, and anyone who says otherwise is just trying to sell you something. Authentication services are obviously juicy targets because of the potential scale of the payoff (for the hacker). They are also arguably easier to break than any well-studied authentication scheme. A typical authentication service presents a larger "attack surface" because it involves more people and complicated internal machinery. Therefore, every authority must have a procedure to respond to their own worst-case scenario. (If they don't, then you should be alarmed, if not wary!)

Multiple authorities can save the day when credentials become unsafe, whether due to a compromised authority or due to direct theft from a user. Instead of one organization taking on the awesome responsibility of securing every user's identity, multiple strong identity authorities would share the burden. That way, hackers would need to attack on multiple simultaneous fronts, and authorities would be able to catch each other when one should stumble. In a true multi-authority scenario, nobody is the weakest link, because we are all in this together, as part of one powerful, pro-active, self-repairing link.

Independent sites/services are better off sharing the authentication burden for more practical reasons as well. An end-user service shouldn't need to invest the engineering and support to manage their own authentication schemes. They may depend on secure identification, but unless they specialize in security, they have their own products/services to deal with! Furthermore, if each organization had its own token, your pockets would eventually be overflowing with blinking, battery-powered dongles next to a fistful of traditional keys.

We're not just talking about giving users a choice of authorities. We're talking about requiring verification from multiple sources to log in (at the very least, one other source). Obviously, passwords will be a nuisance for multiple-authority verification. Fortunately, this current generation of authentication schemes (like LastPass, YubiKey, Persona, OneID, and CryoKey) make authentication so simple, checking against multiple authorities should have minimal impact on the user authentication experience.

In short, multi-factor authentication by itself isn't a magic bullet. Truly strong identification will make use of multi-authority authentication. Metaphorically speaking, each factor may represent a strong weapon, and an authority may represent a warrior. But if your village needs protection, one samurai may not be enough, no matter how many weapons he possesses; however, seven might make all the difference.

As a follow-up, I wanted to summarize the key points between the authentication schemes described in my last post. Comparisons are difficult because each scheme is so unique, and small details have major implications. But we can identify some of the more recognizable differences in this brief comparison matrix:

table { border: 1px solid black; } table tr td { border: 1px solid black; text-align: center; vertical-align: middle; } table tr td.heading { width: 15%; } table tr td.label { text-align: left; }

LastPass YubiKey Mozilla Persona OneID CryoKey Technology Password Hardware Certificate Certificate Certificate (Optional Hardware) Identity Any Any E-Mail E-Mail? E-Mail Authority Local Local/Central Central Central Central Feasible as Second Factor No Yes Yes Yes Yes External (Non-Browser) Functionality No Capable No No Capable Personal Data Form Fill None None Form Fill None Setup and Management Local Token Identity Provider Account OneID Account Existing E-Mail Account Internet Access Optional Important Required Required Optional Cost Structure Optional Subscription Per-Token Free Free (Optional Paid Services) Free (Optional Paid Services) Client Integration Dedicated Software Hardware Driver Browser Capability Browser Capability OS and Browser Capabilities Service Integration Pre-Existing Web API Web API Web API SSL Client Certificate (Web API Available)

Notes:

CryoKey works with the operating system certificate repository and the SSL protocol. Operating system certificate repositories such as MS Cert Store or Apple Keychain are very secure, and available to other local applications. SSL authentication flows are also very secure, having been thoroughly vetted over the years. Servers use SSL authentication extensively (seen by the padlock icon in the address bar for HTTPS sites). On the other hand, client certificates, to date, have been used only in government, military, and academia because of their relative complexity.

In contrast, LastPass, YubiKey, Persona, and OneID all work on a higher level. They manage their own credentials and verify security after the lower level protocols complete the connection. Therefore, CryoKey can actually augment these schemes, because CryoKey can authenticate the very communication protocols that the other schemes build upon.

Some people may say, "why is Persona listed as a centralized authority when it's actually distributed/federated?" We consider it centralized because you can't really distribute authentication. For example, you can't use Google servers to verify your Yahoo identity. Like OpenID, Persona acts more as a conduit for users to access the centralized authority of their choice. To the end user, the act of logging in using Persona certainly feels centralized.

LastPass and YubiKey (and also CryoKey) have the ability to work offline. Local authentication is useful in environments with limited network connectivity (due to security or other constraints). For ideal authentication, YubiKey needs access to the YubiCo servers. But YubiKey can work independently as a strong random password generator as well as other yet-to-be-developed functionality. LastPass only needs network access to update or retrieve from the centralized repository (to synchronize the passwords for multiple devices). Theoretically, it should work on local web applications even without a network.

Again, keep in mind that all authentication schemes are relevant. Multiple schemes are best because using multiple schemes allows one method to make up for any limitations of another. But if you have to pick only one, you should base it on your own values (or the preferences of your typical users).

Over the past year, the password burden has been attracting increasing industry attention. When we started developing CryoKey a while back, the only alternative authentication scheme was OpenID, which is primarily a password-based framework with a fair level of acceptance. In the end, our frustration with passwords and authentication drove us to come up with our own solution. But now, many great minds are rising to the challenge of finding a successor (or at least a companion) to password authentication. I'm very excited by the thought that I will soon be free of password creation, maintenance, recovery, and all of these malicious users trying to steal passwords and account databases.

We're now starting to see a lot of development on the necessary authentication technologies that may someday liberate users from the burden of excessive password use. Several promising services are now available at various stages of polish, each with their own vision of user identification and authentication. In addition, the FIDO alliance aims to bring different authentication schemes together by providing a set of standards that simplify their adoption and use in web authentication. But with all these options comes confusion, since each technology works in a different way, and each solution has its own specializations.

Here is a brief rundown of a few of the more promising models that stand out (in my opinion):

Centralized Password Database: LastPass

LastPass is one of the most popular password database applications around. They allow you to easily store account information and fill in account forms, and provide a simple way to quickly generate a strong random password as well.

Highlights: Since it simply adds another layer on top of passwords, LastPass can work with existing sites. Instead of individual site passwords, users only need to know one master password, and the data can synchronize to different devices.

Limitations: LastPass works only on web forms. It merely masks the password burden without actually solving the major problems with passwords. For instance, your individual sites still maintain user credentials, and the databases are still vulnerable to theft. You need LastPass software to access your credentials (especially if you let LastPass generate the passwords), or else password recall will be difficult on shared/public machines.

Physical ID Token: YubiKey

YubiKey is one of the better-known consumer hardware tokens around. It acts as a OTP (one-time password) generator that also automatically enters the password for you. YubiKey has partnered with other organizations (such as Google and even LastPass) for greater acceptance.

Highlights: Authentication relies on the presence of a physical object, so it's very secure. It's also very simple, and works well as a second authentication factor.

Limitations: A separate device is more secure, but also requires users to carry around another device, which some people may not like. You can lose/forget/break the key. It may not be compatible with all machines/devices. It also costs money.

Federated Cryptographic Single Sign-On: Mozilla Persona

The open-source community will obviously come up with their own solution as well. Mozilla Persona is basically a process/protocol that identifies users using an E-Mail address and authenticates them using public key cryptography. You log in to Persona to automatically generate a temporary key pair (valid for no more than a day), which the browser caches. Then, during a browser session, you can use the temporary credentials at participating sites to gain access. As a result, you only need one password to log into the Persona Identity Provider and generate short-term credentials, which are used to answer cryptographic challenges to prove your identity.

Highlights: As a Mozilla project, Persona is quite proud to be free and not-for-profit. Persona uses short term credentials with public key cryptography to enhance security. One Persona account (E-Mail address and password combination) will give access to all participating sites. Persona only needs to know your E-Mail address, so it's more private than other solutions.

Limitations: Not all sites recognize Persona, and not all domains will work as your identity (domains require an Identity Provider server). To generate credentials, you will need access to a Mozilla Persona provider. Authentication also relies on a third-party identity provider's availability and security practices. Identities can only be E-Mail addresses. Authentication requires a browser with local storage (HTML5) and cookies enabled.

Cloud-Based Device Certificate Authentication: OneID

OneID uses public key cryptography with digital certificates to identify users. Actually, OneID identifies devices (or rather, device-browser combinations), but these days, users generally don't share devices. After creating a OneID account, users can "activate" other devices, granting them the ability to authenticate as a user. When logging in, the OneID servers work with the locally stored certificate to prove your identity to a destination site.

Highlights: OneID is secure because identification relies on a private key that is generated locally and never leaves the device. Authentication is as simple as logging in with a button click. You can also store personal information with OneID for easy form-filling.

Limitations: OneID generates and stores keys in local storage, so it requires a capable web browser (HTML5) to function properly. OneID seem to lack the ability to identify multiple accounts, since it ties a single account to a single device/browser combination. Browser "private sessions" may disrupt usage (since local data may go away at the end of the session or when cleaning browser data).

Client-Side User Certificate Authentication: CryoKey

Last but not least is CryoKey, currently in a technology demonstration/shakeout state. Generate credentials with a simple E-Mail verification, and use credentials by merely selecting your identity with a click when accessing a participating site. Like OneID, CryoKey uses certificates and a cryptographic challenge to identify users. Like Persona, your E-Mail address identifies you, and we don't keep any other information. However, CryoKey works at a lower level by tightly integrating with existing browser/operating system services, technologies, and protocols to the fullest.

Highlights: CryoKey is simple, secure and free. CryoKey can provide limited identification even without network access. A single device/browser can host multiple identities. Users only need access to an E-Mail account when generating credentials, and don't create a separate account with CryoKey. Credentials are available through operating system services, allowing external (non-browser) applications to use the identity for general purpose cryptographic functionality. Credentials can also integrate with hardware tokens (in fact, we briefly had a demo token during development). As a result, credentials are available for a wide range of external uses from mail signing to data encryption or even scripted authentication (such as automatically authenticating a server application to a MySQL database in a Perl script).

Limitations: Not all sites recognize CryoKey. Actual user experience depends on browser and operating system interfaces and security models. Since basic credential generation depends on access to the E-Mail account, CryoKey is not suitable for authentication of E-Mail accounts.

This analysis is based on a cursory review of a few existing services. Actual technical details require a lot of digging because most of the more advanced solutions simplify their descriptions to avoid drowning users in the frustratingly complicated world of computer security. (If you want to see what I'm talking about, take a look at Persona's technical details, which contain terminology and concepts that require a strong understanding of security considerations.) I tried to simplify the analysis by keeping it at a high level, so if I made some serious misrepresentations or omissions, let me know.

Before people start a holy war about "which solution is best", I want to stress that, despite any limitations, each service provides a worthy solution to today's password burden. Besides, as development continues, I expect most of these limitations to disappear. In any case, different schemes can and should co-exist because each person/organization has its own use cases and values. Furthermore, identity services should be working together to stand up against the growing capabilities of malicious users. No solution is perfect, but one scheme may cover for the limitations of another scheme, and different solutions working together would establish even greater identity assurance. I can imagine a future where a secure site like a bank would require at least three independent identification sources to log in; that would be truly distributed authentication!

Apparently, computer security is an incredibly boring subject. Just the mere mention of security topics causes eyes to glaze over. Therefore, a friend challenged me to describe CryoKey without using any trade terminology.

Describing CryoKey without terms such as "certificate" or "key" is like writing a love song without using the word "love", or playing Scrabble without the letter "R", or even describing the Last Airbender movie without expletives. I tried to draw a diagram, but threw it away because it started to look like the Tokyo subway map. At that point, I gave up and headed to a bar (where all great ideas are born). At some point during that evening, I was talking about Yuko Oshima when inspiration struck.

Imagine that a friend of mine is pining for his favorite super idol, Yoko Kojima. He may know her, but she doesn't know him. However, both of them know and trust me. So, being the noble wing-man that I am, I offer to help my lovesick friend arrange a romantic rendezvous. Then:

Over a tear-splashed beer, my friend tells me that his life is simply not worth living unless I can set him up with Yoko Kojima, and gives me his phone number.

I record his phone number, then choose a time and place for the two to meet.

At the specified time and place, he meets Yoko and hands her his phone.

Yoko calls me using my friend's phone, and I check the Caller ID to see if it matches what I am expecting.

If the phone number, time, and place all line up, I confirm his identity to Yoko.

He then proceeds to have a hot date with Yoko Kojima. Sparks fly, and everyone is happy (except maybe Yoko Kojima's other #1 fans). Who knows where this budding romance will go? And it's all thanks to CryoKey!

This hypothetical blind date roughly illustrates CryoKey's Lightweight Authentication model, which is used by our WordPress plugin and MediaWiki extension. So if you want to experience what it's like to be set up on a blind date with your favorite idol, then visit a WordPress or MediaWiki site that uses CryoKey. Just keep your expectations in check; in practice, it's not that exciting, and everything happens so quickly, it'll be over before you know it. Oh, and, Yoko Kojima is not actually involved. Sorry to disappoint.