Live data from Hacker News

Show HN: A virtual Yubikey device for 2FA/WebAuthN

github.com

51–60 of 143 posts

Re: Show HN: A virtual Yubikey device for 2FA/WebAuthN

#51
post #35
post #4

Earlier quoted context omitted.

I think a huge benefit of 2fa, one of the main purposes of it, was for securing accounts with weak passwords. Back in the days before password managers etc. I think these days password managers actually deprecate the need for 2fa

Passwords are an antipattern. Password managers are just a crutch to make it less painful. Password recovery is often done through the phone via SMS (health care/banking) when a 2FA hardware key would be safer. And since you're implementing 2FA, just remove the password, and ask the user to use the 2FA key.

I think my favorite example of using SMS in the least sane way possible is PayPal.

I have a hardware key AND an authenticator app active for the account, but they STILL won't let me send transactions without entering a code sent to my phone number. And actually, not even then, because even though I receive the code fine, they say they can't authenticate me and don't give me a chance to enter it. Yes, it's a VOIP number, but it's been the same VOIP number for the 10 years I've had the account. It's not like it's new.

Re: Show HN: A virtual Yubikey device for 2FA/WebAuthN

#52

I'm guessing this won't work for sites where a real device is mandated. I believe on Vanguard, they were enforcing only permitting real Yubikey devices with real Yubikey certificates.

Vanguard changed their policy when they switched from the u2f javascript api/shim to webauthn. I was able to register non-fido keys with vanguard a few months ago.

Re: Show HN: A virtual Yubikey device for 2FA/WebAuthN

#54
post #2

I can't figure out why I'd want a Yubikey. Every year or so I try to figure out if a 2fa device practically has sufficient support that using it would improve my security. The answer has always been no. No 2fa device has sufficient support that it could increase the security of my 1password account, which I use on Linux and Android. No 2fa device has sufficient support that it could be used to unlock the lockscreen o…

I use 1Password and 2 Yubikey.

Both yubikeys are configured to enter the same impossible to memorize password on a press to unlock 1Password, hid mode is supported by every device with a USB ports.

I also use them as an otp second factor when a site requires it.

Finally, they are configured with a x509 certificate that I use as my ssh keys. I generate one key per devices that way the secret never leaves it and I require a pin to unlock the key. For convenience, I use an ssh agent to cache the pin

I could also use them for pgp signature and encryption but I have no use case for that.

Re: Show HN: A virtual Yubikey device for 2FA/WebAuthN

#55
post #3

Fun demo but who is this really for? Is there a requirement for these devices anywhere aside from corporate security?

This is primarily of use to people who want to disregard hardware authenticator requirements imposed by third parties without their consent.

Jeez. That's almost as bad as requiring a password!

Re: Show HN: A virtual Yubikey device for 2FA/WebAuthN

#56
Anyone know if there is a way to do WebAuthN without loading JavaScript from the website? Perhaps a Web Extension that reimplements the login requests for every website that uses WebAuthN will be needed, since there isn't any standard protocol for WebAuthN login between the browser and website, just whatever the website implements in JavaScript.

Re: Show HN: A virtual Yubikey device for 2FA/WebAuthN

#57
post #42
post #36

This sort of defeats the idea of 2FA, doesn't it? If it's implemented as a software service on the same device, it's (well theoretically at least) hackable at the same time as the device itself. The 2 factors from 2FA are both accessible to an attacker at the same time, so you effectively have just a single factor auth.

It does, but there's actually a way to do this (ie. u2f without having to buy another device) in a safe way, by using the TPM available on most computers: https://github.com/psanford/tpm-fido

Unfortunately without additional hardware support it's hard to tie TPM FIDO to physical user presence, which means compromising the system doesn't give you access to the secrets but does let you sign as many challenges as you want without user involvement.

Re: Show HN: A virtual Yubikey device for 2FA/WebAuthN

#58
post #43

Wouldn't this reduce security considerably, for the scenario where the computer is compromised?

If the computer is compromised you're screwed either way. Even though WebAuthN can't be easily MITM'd like TOTP codes, someone compromising your computer could just use the UI to lie to you. I think the main reduction in security is just that the virtual 2FA device is "cloneable" vs a hardware FIDO2 token where IIRC you can't extract the internal secret. So you're getting TOTP levels of 2FA (which also uses a cloneab…

They could, but it's still limiting - the maximum number of challenges the attacker is able to satisfy is the number of times you touch the token before you realise that something's up.

Re: Show HN: A virtual Yubikey device for 2FA/WebAuthN

#59
post #57
post #42

Earlier quoted context omitted.

It does, but there's actually a way to do this (ie. u2f without having to buy another device) in a safe way, by using the TPM available on most computers: https://github.com/psanford/tpm-fido

Unfortunately without additional hardware support it's hard to tie TPM FIDO to physical user presence, which means compromising the system doesn't give you access to the secrets but does let you sign as many challenges as you want without user involvement.

Realistically speaking if your machine is compromised it's effectively game over. If you're signing into services on a daily basis an attacker wouldn't have to wait long to piggy back off a legitimate request. The chances that you catch the compromise before that happens is slim.

Re: Show HN: A virtual Yubikey device for 2FA/WebAuthN

#60
post #51
post #35

Earlier quoted context omitted.

Passwords are an antipattern. Password managers are just a crutch to make it less painful. Password recovery is often done through the phone via SMS (health care/banking) when a 2FA hardware key would be safer. And since you're implementing 2FA, just remove the password, and ask the user to use the 2FA key.

I think my favorite example of using SMS in the least sane way possible is PayPal. I have a hardware key AND an authenticator app active for the account, but they STILL won't let me send transactions without entering a code sent to my phone number. And actually, not even then, because even though I receive the code fine, they say they can't authenticate me and don't give me a chance to enter it. Yes, it's a VOIP numb…

I needed to recover my user account / password through Voya recently for a corporate 401k.

They needed to send me 3(!) SMS messages in the process. One to get the username (with a valid email address). One more to request to change the password. And one more to actually change the password.

Post reply on HN