Yubico Forum

For larger deployments and serious use, establishing processes around lost YubiKeys is an important and challenging aspect. Over the years, I have worked with customers to establish processes. Here I'll try to summarize the basic philosophy that I recommend, to help you think about how to deal with lost YubiKeys.

There are (at least) two view-points of losing a key:

1) If you are a system integrator or operate a cloud service with support for the YubiKey, or

2) If you as a consumer lose your personal YubiKey that is used against third-party services.

The rest of this post will be about the first aspect since that is usually the challenging part. Regarding the second aspect, briefly, the situation is similar to when you lose a password or forget a username: you use the recovery process at the third-party services to regain access and setup another YubiKey to protect your account.

If you manage a system that supports YubiKeys validated through the YubiCloud, the standard pattern is to authenticate the username and password in your own server, and then call out to the YubiCloud to verify they YubiKey OTP. These systems need an administrative interface to manage users, which can be of varying level of sophistication users. For example, the could be a Wordpress blog with the YubiKey plugin, or Unix (typically Mac or GNU/Linux) login using the PAM module. The wordpress system has its user management interface, and Unix has its own user management and configuration interface. When a YubiKey is lost, to regain access to the system, the administrator has to provide a mechanism for users to associate a new YubiKey, or at least temporarily disable two-factor authentication.

How to implement recovery processes depends on how advanced you want to make the system. Most systems can be divided into roughly the following categories, and the recommendations for each are separate.

1) The user contacts the administrator directly and the admin performs manual operations to modify the account. This is usually used for small organizations, with say 10-50 people. My recommendation in this situation is simple: after a user notify the admin, the admin make sure the user is the right person, and manually makes the changes. This can include editing text files with usernames and YubiKey prefixes, running SQL statements modifying a SQL database, or similar.

2) You have an administrative interface to simplify the interaction to the system, so that non-engineers may perform the administrative tasks. This is usually used for medium size organizations, with a couple of hundred or thousand users. The admin system often implemented as a web service to an internal system that is responsible for modifying some SQL database. My recommendation in this sitution is a bit more complex: The process is similar as in case 1) but you need to spend time securing the administrator login to the internal system, so that nobody can access improperly. Further, you need to train the people performing the operations to not fall victim of social engineering attacks, so they won't restore the wrong user's account.

3) You have a self-service system where the user is responsible for logging in to perform the administrative operations herself. This is used for larger organizations with tens of thousands of users up to several millions. Setting up and running a system like this require a significant investment in processes and security, and is normally only economically viable of you have a large user base. My recommendations are to invest heavily in multiple authentication mechanisms for the user, because ultimately you have nothing other than what the user has historically provided to you to judge whether he is the right user or not. Getting the phone number and sending a SMS is a simple first recovery process step. Having a set of challenge questions is another, but experience with how well that works in practice are mixed, and there are privacy concerns with this approach. Data mining whatever data the user has stored with you is another option, but it equally have privacy implications.


Cheers,
Simon