A few months ago we ditched the second factor and began using a new technology, “passkeys.” Was it a good idea?

A few months ago we began using a new technology, “passkeys.” Here at Vodia, second factor authentication wasn’t working too well for us: as a software manufacturer, we don’t know what second factors end users actually have when our partners run the service. SMS would be great, for example, but it would require our partners to connect to an SMS provider (only a few do). A USB hardware key sounds nice, too, but almost no end users have them. The only “workable” second factor, in reality, was email, so we would send a code to the end user via email for confirmation. But let’s be honest – email confirmation is inconvenient, particularly as we are talking about logging into the phone system. And email isn’t always available. It’s only about logging into your phone system. It’s not Fort Knox.

We heard about FIDO and saw they worked with the big platforms, like Microsoft and Google, to come up with something better than passwords; that they are using public and private keys was a bit of a turn-off because of the rather intense effort required to get it working. That said, we’re quite confident when it comes to cryptographic challenges, so we began playing with it, and the timing actually wasn’t bad: the browsers already supported it, and there was plenty of example code available to get it up and running on the front end and the backend.

We would have loved to drop the support for passwords entirely, but it became clear this couldn’t happen anytime soon. After all, we allow VoIP phones to register while continuing to use good old MD5 checksums on username and password; this is still better than sending passwords in legible text, but not really secure. So we kept passwords for users and a way to authenticate via email, but we added an API for dumb replay attacks – the API avoids basic authentication and instead uses a server-generated random string.

In the first version of the new login screen, we really pushed for passkeys: whenever users logged in, the system would ask them to store a passkey. It turned out this wouldn’t work, however, because the browser always required some kind of user interaction before sending the passkey, which made login clumsy. We still needed a session key, one the server maintains for 14 days, give or take, so the user doesn’t have to initiate the passkey dialog every time (but doesn’t forget how to use it). We released this version, but it still wasn’t sufficiently user-friendly, as some users are unable to use passkeys because of corporate policy at their workplace. These users were forced to constantly click away the passkey dialog, which was, as they say, bad optics.

In the subsequent version we added a checkbox that reminds the front end to request the passkey once and once only; anyone who can’t use the passkey can just check the box and be done with it. We are convinced this will work for most users for a long time to come.

Our timing was good with passkeys. In the beginning we had to explain to everyone this is a cool thing, but since then passkeys have become widely available on numerous platforms. There’s been enough buzz to generate some press coverage (i.e., Hate Passwords? It’s Time to Try Passkeys). It made Vodia look pretty good, at least compared to other companies still bidding on passwords. And it certainly saves us the time we’d have to spend explaining passkeys to everyone.

What’s most important to the team here at Vodia is our passkeys have made the use of our software significantly more secure. Yes, users can continue using passwords – they can continue entering trivial passwords into dialog boxes if they want to, but we’ve made it so easy we’re convinced fewer and fewer users will choose passwords over passkeys – it won’t make sense to continue using passwords. Passkeys reduce the risk of someone hacking into customer systems: this saves them time and money, and they make fewer support calls. When hackers have a choice, they go for lower hanging fruit and leave our users alone.

Lastly, when our users spend less time typing in passwords, requesting factors or finding themselves frustrated after repeated log-in attempts, they tend to be happy users. We want happy users!

Let us know what you think.