Add ability to set U2F without smartphone, and use recovery codes to U2F

Issue #13051 open
Uri Blumenthal created an issue
  1. U2F is not a sub-part of smartphone-based 2FA - it's an independent method, and should have the same level as smartphone-based 2FA. I should be able to enable 2FA using only U2F as my second factor (no smartphone-based access), and receive recovery codes via email (and be able to access them via SSH).

  2. There must be a way to use recovery code(s) on a U2F-enabled account regardless of whether a smartphone-based 2FA was or was not enabled.

Let me add an insult - your current design where U2F can only be enabled if smartphone-based 2FA has already been set up is stupid.

Comments (5)

  1. Alastair Wilkes staff
    • changed status to open

    Hi Uri,

    Thanks for the feedback!

    We released it this way at first so that users already using 2FA who wanted to also have their U2F key as a convenient alternative to TOTP. We've received a bunch of positive feedback about this.

    However, longer term, yes, it would be ideal to be able to enable it without requiring smartphone 2FA, but we'd really like to have another factor like SMS (or email, as you mention) as a backup. That's not currently planned, but that could change based on demand. We'll keep this issue open and in the backlog!


  2. Nirantali

    Yeah, just got the same issue. Was forced to set up a cheap Mobile 2FA App first. Sorry, but i have 3 Yubikeys here, i add them all and that's it, the probability that all breaks or i loose them is 0.

    That issue is also even worse, because you know if you offer fallback to lower security on logon, for what do i add security keys? An attacker simply can select 'I don't have access to my Security key' and then use the stolen Mobile Data instead where the Google Authenticator even conveniently shows for which service the code is, very nice isn't it?

    No, if you offer U2F and the users adds security keys then it's U2F and nothing else. A Recovery option in case of lost U2F keys or if they break (very unlikely) has to offer the same security, perhaps a random sequence of 128 length would be ok for that, to be stored in a secure place like a safe or so and used only in that case.

    Offering U2F but then easily offering lower Security fallbacks on login is stupid. It's like if you have an Codepad and IRIS Scanner on your Door, but you can also simply use a normal key should the Codepad/Scanner not work or something. So in the end the Security Level is the one of the weakest link, in that example the normal key, that can be stolen and copied.

    Also mobiles are not good for 2FA anyway, they can be infected and compromised just like any computer, the 2FA app data in them can be stolen without the owner knowing and those apps also all displays for which service the code is for. And the probability that a mobile breaks is also much higher. Also another issue, what does one do if the Mobile was stolen? I didn't see any option to remove the Authy 2FA, so yeah how to remove the compromised Authy 2FA then?

    U2F Security Keys can't be infected or copied. They can be stolen but there are no identifiers anywhere that helps the attacker to know for what that particular one is used for. Also if i know that a U2F Security key was stolen, i remove it from the services and that's it. I anyway recommend anyone using U2F to register more than one, min. two but better three. Then there is absolutely no need for recovery options at all.

    I personally normally register three with one of them NFC capable for using with mobiles, that way i even don't need any backup codes or anything, because all my devices either have USB or NFC.


  3. Aryeh Leib Taurog

    I also would like to see U2F as an independent 2FA option on bitbucket. I do believe that a U2F-only configuration is more secure than mobile-based 2FA + U2F. But I also have another reason for requiring separation of 2FA features: I don’t carry a cell phone. I realize this is an uncommon use case. I might be the only bitbucket user without a cell. Still, the requirement to first configure mobile-based 2FA is, to my thinking, arbitrary and unnecessary, and prevents me from using my new yubikeys with this service. (Authy has a desktop app, but requires SMS for registration, so this doesn’t help me.)

    By the same token, I would add that a U2F-based system should NOT rely on SMS or email as a backup. Recovery codes should be issued when keys are registered, and it’s the user’s responsibility to protect them. I understand that could possibly put greater burden on telephone support, but I’d rather have to prove my identity over the phone and suffer the inconvenience of a 24 hour waiting period in case I lost both my yubikeys and my recovery codes than have the convenience of access in such a case at the expense of account security.

    Thanks for reading. Aryeh Leib

  4. Log in to comment