YubiKey Usability - Let’s Discuss

By Drew Rothstein, Head of Engineering

Introduction

The YubiKey is a fantastic device solving a set of problems in the 2FA (2 Factor Authentication) and key management space. The publicly available Titan Security Key (not to be confused with Google’s in-house developed Titan chip) is also an option but is more narrowly used.

YubiKeys support a lot of features (source).

While these devices are solving several large problems and moving us to a safer authenticated environment, unfortunately they are not the most user-friendly interface nor do they provide easily adaptable interfaces for many prominent developer platforms.

Many organizations have started to move their SSH / GPG keys to these devices, implement required touch-triggered OTP, and go fairly deep into U2F but the sacrifice in usability at this time is fairly large. A microscopic blinking LED somewhere on your keyboard, desk, or computer isn’t exactly usable.

Most of this sacrifice isn’t really on Yubico (YubiKey) or Google (Titan) or the various communities such as the FIDO Alliance to solve. If anything, these companies have done much more positive than negative in the space by making these devices as usable as they are. Yubico in this vein have published several libraries to work with their devices (Python, Java, C) furthering the ability to integrate and adopt (whereas the Titan is more tied to the Google Suite and less interoperable).

The problem lies in the platform many Engineers use and do not have much of an option to change. If your company issues you a Model $foo laptop, that is what you generally need to use due to company policies and procedures. This is completely logical as they have obligation to meet certain security requirements, standards, and regular audits. As someone usually responsible for parts or all of those items I generally appreciate having a single platform that needs to be appropriately managed.

Many software companies have settled on the Apple platform. I am not sure the complete origin of this decision and process as to how we got here but due to the hold it has on these companies an entire ecosystem of support has been built around this encampment. There seem to be more MDM and Rootkit options for OS X to meet the needs of various security and compliance requirements than pretty much any other platform. They are generally more usable and out-of-the-box configured than the products that are focused more on Windows or Linux.

There is a strange dichotomy here that likely warrants a set of conference talks where somehow software companies have landed on a nice looking machine, less repairable than any other option, and built an ecosystem around it all while Apple itself does not make managing company devices easy or sane (ref: not recommended).

Until that conference exists, we move away from the Apple platform for software development, and as we continue to implement the YubiKey deeper into our day-to-day lives as Engineers – I have put together the below user story and where I believe we need to go next.

Onboarding

It is exciting, a new team member that you interviewed a couple months ago has joined the team. Everyone sends accolades and welcome messages with more reacji than makes you comfortable but you click a few anyway. Maybe they are even wearing some team swag that you sent them.

You are their onboarding buddy and they have reached the phase of onboarding where they are setting up their 4 different YubiKeys. The company sent them two and they purchased two – they are being reasonably paranoid about a targeted attack on your mail given their recent scuffle with the delivery person.

You send them over a link to the onboarding guide and they open it. It takes a few seconds to load because it has 50+ code snippets, workarounds and if they were to print this out it would be well over 30 pages of Arch E1.

Big Gulp (Reference, CC BY 2.0)

As you recommend, they go and make a Big Gulp of coffee before embarking on this journey.

You were the last one to update the guide and you remember it well. You kindly updated the section on the latest gpg-agent bug that required linking a different version of gpg-suite and the bootstrap script that you still can’t seem to get right.

Your guide is a shortened and more specific version of the amazing guide here. It goes step-by-step to enable new to the team members and new to YubiKey members to have a very “simple” guide to follow. As a team you are proud of the guide but also know it is a day long adventure for every new hire.

What is strange is that every person that onboards needs to update the guide. It never seems to remain perfect and constant. This is similar to your environment where occasional issues seem to crop-up when you have seemingly changed nothing. Team members regularly share update scripts and reset scripts to solve various issues that the time tradeoff of investing going deeper isn’t super reasonable.

The new hire makes it through and the final steps of cross-signing keys over video, checking them into a few repositories, and bumping submodules is now in-flight.

Problems

The new hire updates the guide as they proceeded and you and them chat about some of the various new problems (and old ones) that they ran into to try and improve onboarding for the next person.

They ask about why gpg-suite vs. gpgtools? You explain that they are the same but the one bundled with OS X doesn’t really work the same and it is an older version. The MacGPG2 package is a bit older (2.2.27) and there was some bug you spent a few hours researching and then moved on last month.

They ask about why you require installing / changing the default shell over to the latest version of bash with some of the GPG utilities your team has written? Similar story, you explain that the one that ships with OS X is from ~9yrs ago (3.2.57) and is missing several features that you rely on today (mostly associative arrays introduced in v4).

They ask you about the differences between the subkeys and fingerprints and how we use them. You explain a couple of the differences in how you use the signing key and encryption key. You point them to a couple references from the amazing guide linked above.

You have them clone their first repository and it just hangs at the git clone step. You ask if they tapped the YubiKey when it was blinking. A pause takes place as this comment is processed, questioned internally, and then released, “Ah, no, let me retry.” They tap the YubiKey and are now fully indoctrinated.

This last piece of the problem space is probably the most interesting and important usability improvement that needs several real solutions that don’t exist widely today between these hardware keys and OS X.

Usability Improvements

Providing user feedback that they need to perform an action to complete a task that was triggered is a fairly important feature of any system that a human interacts with on a regular basis.

Gas Pump Octane Selection (Reference, CC BY-SA 2.0)

A gas pump is a fairly good corollary to this problem space. You take the pump and put it into your vehicle and the light on the octane sits there waiting for you to select what you would like. You of course select non-ethanol 91 because you had corn last night with dinner but you glance back at the screen and just before you select the octane you notice in big letters it says, “SELECT YOUR OCTANE.” You ponder for a moment why your YubiKey cannot do the same.

Some folks have tried to solve this already it seems with varying success. One of the public repositories that has a nice utility for this for Linux is available here. There is a great discussion on the closed issue here about OS X support.

This will lead one down a path that goes pretty deep. Of course you can start by checking out the widely used notify library. You may then head down the path of looking at fsevents, go-fsevents, and fswatch. You will quickly and likely circle back to the original issue thread and realize the library isn’t really what needs to change or be modified but what is really needed is to implement / use the Endpoint Security Framework (article, reference).

Now, can you do this in Golang if you want to use the utility above? Well, of course and someone already wrapped the above code nicely (ref).

At this point you pause and take a step back wondering how you would package and roll this out to the team. You will have to overcome some SIP protection and likely create a developer certificate to sign this package. You will probably want to implement it as a menu bar icon or even better something like terminal-notifier to provide the very clear visual usability improvement you are seeking. Perhaps you even wrap it in a utility that abstracts some of the more difficult portions of the initial YubiKey setup (ref). This will require packaging or instructing folks to also install / have that available. You chat with folks on the security team and they don’t love the idea of a watch on several sockets & paths running on developer systems understandably.

You think about where you have gotten to development wise- you made it all the way to where you wanted to be-

You got a prompt, you sought out and conquered getting a usability improvement to the YubiKey interface. You think about how it would be nice to add details from the event itself to the prompt, maybe something about the application that requested it but you don’t immediately see these details in the event.

So, you sign off for the evening (it is quite late) and plan to take a drive the next morning. You get some rest and continue to think about how you can simplify this problem space and still achieve what you are seeking to improve.

It’s 4am, the sun is not yet up with a little dew on the ground - perfect driving weather. You pull over to fill up and of course stare at the gas pump prompting you to select your octane. You wonder the complexity of engineering that went into having those words on the display, what arcane process went into it, what corners were cut.

When you get home you look into this for a few minutes. You really want to know. You find a few products that control gas pumps and most of them have screenshots of Windows XP interfaces (ref).

Conclusion

Security of development and operational processes in software is not keeping up with usability. Much of the frustration of implementation of security primitives and requirements comes down to lack of usability.

Onboarding is a one-time cost and arguably can stay as challenging as it is today. Ongoing usability of hardware tokens and lack of feedback to end users is not acceptable. There will be continued push back and annoyance that will force security conscious organizations and teams to suffer under this weight.

If we continue to insist on platforms that don’t have easy interfaces to interoperate with the devices we can / want / should use daily, this will not end well.

Maybe we need to reconsider the current choice of the Apple platform? Maybe we need to focus more dollars on Engineers and external products to wrap all of these utilities together as a package?

None of these usability issues described are the business problem that most software companies are aiming to solve. It is hard to invest in fixing them. It may sound like just another complaint by Engineers.

What do you think we should do? How does your organization address these types of challenges? What is an example of a usability challenge with a security requirement at your organization?