One of the original functions on the YubiKey is a static password for use in the password field of any application. Such an option seems to challenge common misgivings about reusing passwords. And we would agree.
But if you look a little deeper, the static password, which has attracted more users than we thought it might, falls somewhere between pervasive support and strong authentication. It works with any application requiring a password, but it’s not a two-factor solution.
The static password was born from a simple idea — since the YubiKey can function as a USB keyboard that types out characters with the touch of a button, we figured the capability provided other options in addition to one-time passwords.
Our lead engineer, Dain Nilsson, has written a whitepaper that goes into detail on this YubiKey function, but we’ll give you a preview here.
We originally achieved “static” by freezing counter values and using crypto functions to provide the same password over and over, rather than creating a new one with each YubiKey button touch. We then added the capability for a user to create a password of their choosing on the YubiKey using scan code mode. Then we moved on to explore ModHex and its 16-character alphabet, and encoding that introduces a measure of “randomness.” That randomness helps create a password that has a tougher resistance to cracking than you might think.
A 32-character ModHex password would take a hacker around five billion years to even get a 1 in 2,158,056,614 chance of a correct guess (yes, that’s two billion!). Even a 16-character ModHex password would take around half a million years to crack given internet bandwidth issues and basic server security.
The static password is interesting to ponder, and many people use them, but it is a password. We think a second factor provides the kind of strong authentication end-users really need.
That said, you might examine if a static password has value in any of your use cases.