back to article GitHub upgrades two-factor authentication with WebAuthn support

GitHub has announced support for the Web Authentication (WebAuthn) security standard. GitHub already supports two-factor authentication (2FA) via SMS texts (the least secure option, given that phone numbers can be hijacked and SMS messages intercepted), one-time password authentication apps, or U2F (Universal Second Factor) …

  1. Anonymous Coward
    Anonymous Coward

    Meanwhile, back in the 1990s

    UK banks are going to force the worst forms of 2FA on us having totally missed how well (gulp) Google, Apple, Amazon, Microsoft and Facebook do it.

    1. ThatOne Silver badge

      Re: Meanwhile, back in the 1990s

      If it's any consolation, it's not only in the UK.

      I even know of a bank (my mother's) which initially used hardware authentication fobs, but recently decided that a SMS was good enough. It obviously costs less than handing out hardware...

  2. Will Godfrey Silver badge
    Thumb Down

    Oh dear

    Well I suppose it's nice that we have a choice as to which engine pulls the train as it comes off the rails.

  3. Glen Turner 666

    Git servers don't support 2FA on updates from Git clients

    GitHub's 2FA works on the web interface only (the same is true for GitLab). Once U2F or WebAuthn 2FA is enabled you need to generate a SSH key or a HTTPS token (aka password) to push a commit from a laptop's command line. These methods do not request 2FA. So the use of a keylogger or theft of a developer's laptop still exposes the repository to unauthorised modification.

    The GIt command line client could be updated to support U2F or WebAuthn upon a "git push" but this has not happened yet.

    Lacking that support at the moment your choice is to secure a GitHub SSH keypair or a HTTPS token using an proprietary authentication key (eg, Yubikey). This is usually a multistep process -- use the hardware key to secure a password database, then that database releases the access token after validation of the hardware key.

    You can also securely sign commits by using a proprietary authentication key which implements GPG-signing and set the repository to require GPG-signed commits.

    Unfortunately neither SSH, HTTPS or GPG expose the security of the key storage. So the Git server can't tell if the key exchange with with a secured keystore or with something as terrible as a passwordless SSH or GPG keystore. This is the problem U2F and WebAuthn exist to solve.

    1. bombastic bob Silver badge

      Re: Git servers don't support 2FA on updates from Git clients

      this is potentially where things get screwed up...

      a) if I use github for my own stuff, I probably have 4 of 5 machines from which I do git push/pull

      b) if i do this stuff for a client, who (let's say) has a PRIVATE REPO, I might be using MANY devices plus a workstation plus my home machine(s) to do development.

      2FA is a PAIN IN THE ASS. I don't want it. Instead, I practice SAFE SURFING and use https and a complex password that I F-up typing a lot. And yeah, I have to type it in a LOT.

      with the number of times I type in "git pull" or "git push" in a single day, they *BETTER* not make this MANDATORY, or they lose ME recommending their services *FOREVAR*

      And I *NEVER* use the web interface except for really high level adminny things (where it's actually a bit easier, like create a new repo, or delete unwanted branches, or issues management)

      1. Glen Turner 666

        Re: Git servers don't support 2FA on updates from Git clients

        The point of WebAuthn is to replace typing that password with a button press, verifiable end-to-end, with no opportunities for keylogging or other MITM. So you'd end up with a better user experience with WebAuthn as well as it being more secure aginst the common issues.

        The point of signing commits is a little more subtle. That protects your code from unauthorised modification to the repository and means that you can verify the commits as unchanged, so if GitHub is hacked you can check that your code has no unauthorised changes -- no need to rely upon other parties, such as assurances from GitHub. If all the developers use hardware devices for the GPG-signing (which is a pain to set up but just a keypress to use) then that's pretty unhackable -- essentially there's a unalterable path of trust from that keypress to code later cloned from the GitHub repo.

        Typing a password a lot isn't great security -- it multiplies the opportunities for keyloggers, it puts false positives in the logs when people mistype them, effective passwords (>10 random characters) are simply too hard. You'd get more security using a password database which is then secured using a cyrptographic device.

        There has been two real advances in security in the past decade: cheap authentication keys (of which Yubikey is the best known) and replacement of firewalls and VPNs with end-to-end encrypted and authenticated sessions (eg, Google BeyondCorp).

  4. Anonymous Coward
    Anonymous Coward

    how to really keep source code secure

    don't use github

  5. Terafirma-NZ

    More or less secure

    What I don't get is they intend to shift from a password that may be easy or hard to guess but should at-least be in your head to a device that falls out of your pocket multiple times a day and is left on the table countless times.

    Yes that device will allow the use of codes far too hard to computationally guess but this makes the old stealing a physical key a thing again and one far easier that stealing car keys. But this time it happens to hold the keys to that persons life and now also they company they work for.

    1. A random security guy Bronze badge

      Re: More or less secure

      Hopefully there is a pin to protect the hardware and the hardware is built to protect keys and passwords and to destroy them after X number of tries.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2022