Comment by amingilani | Hacker News Reader

Comment by amingilani | Hacker News Reader

I applaud your creativity Ken! However, this concept has been explored before, and in fact, you could think of U2F tokens as devices with private keys.

We've already gone through a number of solutions, and regardless of the tech you built, this is just another example of an app-approval flow. Twitter & Facebook allow you to approve logins from already approved apps, and while their underlying tech is different from yours — your server can still change the tech maliciously.

For a brilliant app idea, see Kryptonite[1]. It lets you install a browser add-on that pretends to be a U2F key, but the private keys are stored in your phone's secure key storage (Keystore for Android & Secure Enclave for iOS). The experience is similar to what I assume your approval from a phone would be, but it works on all website that support U2F.

For your own site, I'd recommend using U2F tokens and TOTP + OTP keys, they're considered really good solutions, and while SMS is considered bad — it's still better than no 2FA. Please see the post by Troy Hunt[0] on 2FA from late last year. It covers more than I possibly could.

Sorry for the negative critique, but I'm sure you'll build something great next time ;) Instagram was first launched as a Foursquare clone[3]

[0]: https://www.troyhunt.com/beyond-passwords-2fa-u2f-and-google...

[1]: https://krypt.co/

[3]: https://www.theatlantic.com/technology/archive/2014/07/insta...

I'd like to point out that U2F has been superseded by WebAuthn[0]. It's backwards compatible with U2F keys and doesn't require a bunch of JS since support is built into browsers[1]. Some hard/software combinations allow you to the platform native authenticators instead of an external key, such Chrome/Android biometrics, Chrome/Macbook Touch ID and Edge/Windows Hello biometrics. Besides 2FA it can also be used to build a passwordless login experience[2].

[0]: https://www.w3.org/TR/webauthn/

[1]: https://caniuse.com/#feat=webauthn

[2]: https://www.yubico.com/2018/08/10-things-youve-been-wonderin...

Thank you for sharing the WebAuthn update. I haven't been reading up on my 2FA scene for a bit.

Thankfully Krypton supports the new protocol too :)

You could think of FIDO Security Keys as having private keys, and in a sense they do, but you're more likely to mislead yourself if you think of them this way. Keys are tied up with identity, and one thing FIDO tokens deliberately aren't designed to do is have an identity.

The trick WebAuthn/U2F do is equivalent to if somehow, magically, the device could have an effectively infinite number of private keys, not just one, or one per site, but one for every enrollment on a site. If Alice and Bob share the same FIDO key for, say, Facebook, the only way even Facebook itself could discover this is to ask Alice's key to authenticate as Bob which will work. Every attempt at such a guess requires a human interaction (button press) and risks discovery. So probably no one will ever try.

> The trick WebAuthn/U2F do is equivalent to if somehow, magically, the device could have an effectively infinite number of private keys, not just one, or one per site, but one for every enrollment on a site.

Ledger Nano S (a hw crypto wallet) has a virtually infinite number of public/private key pairs. In fact, all hardware wallets that implement "hierarchical deterministic wallets" have them. All the wallet needs to determine a private key for one of its public keys is the "derivation path" of that pair. Even more interesting, if one site knows one of your public keys, it can't determine the rest of them without knowing your "master public key".

Along with U2F, see also Authy and Keybase. Each asks for an account ID, then uses a prior authenticated device to assert that the new device is OK to authenticate. Keybase definitely uses a genuine PKI to make this happen. Authy might not -- it's hard to tell from the app's outward behavior.

Upside is the convenience of not needing the original account passphrase to add new devices. Depending on your threat model, demanding a passphrase to add a new device might not add anything to the security.

Downside (I imagine) is that people can misplace their passphrases for a long time, thereby allowing the account to grow in value, but not realize it until they've lost or destroyed their last authenticated device. Then they're screwed because they no longer have any way to get back in.

SMS is worse than nothing.

SMS does still help to mitigate a common attack...folks trying out password dumps on other sites. But, I don’t disagree we need to move on when we have more options to choose from. Right now the best looking option is webauthn with platform authenticators.

If password reuse is a problem, one should be solving that problem instead of it's symptoms. "Have I Been Pwned" comes to mind.

https://haveibeenpwned.com/API/v2#PwnedPasswords

This is grossly untrue. SMS prevents scalable password reuse attacks.

SMS as a second factor is not a net reduction in security. The ability to hijack a phone via number porting or similar could give access to SMS messages, but by definition a second factor should never reduce your security.

What does reduces security is the use of SMS as a password reset mechanism, or any similar method that uses SMS as the only factor for authentication. Don't do that.

It gives users a false sense of security and providers an excuse not to implement something better. Most (all?) of those who only support SMS 2FA also get the part about no resets wrong.

Reply on news.ycombinator.com