Dennis

Thanks

Paul @ Yubico

We thought about implementing that one about a year or so ago, but still think, that it’s a bad idea that every provider comes with a seperate OTP device.

OTOH, Encrypting the yubikey DB is a hard one

“The server stores the encryption keys and passwords for all users, and is thus a single point of failure. A successful attack on the server, e.g., a physical server attack or cracker attack, will compromise the entire system. The attacker will be able to masquerade as any user. The recovery procedure from
this attack includes replacing all user devices (or possibly do a software upgrade of them).”

Not so nice. So, the key database needs to be seriously protected. Higher stake in case of a server attack with the keys in clear text in the database. Reduces the attractiveness of running such a service on your own.

Man-in-the-Middle and key logger attacks stay dangerous with yubikey as well. Still, nice method of circumventing some social engineering attacks with a low-cost token. I’m eager to see if yubikey will spread.

I have 1 question on the way you check wether the login is a Yubikey or not looking at the length of the password.

Did you think about checking the username entered within the application and see what authentication mechanism is related.

In the end the RP’s still need to link their application uid to the authentication ID. In general this mechanism could help the RP’s to have just one login screen asking for the username. (In stead of having a login for all different authentication mechanisms.)