back to article Passwords begone: GitHub will ban them next year for authenticating Git operations

Microsoft's GitHub plans to stop accepting account passwords as a way to authenticate Git operations, starting August 13, 2021, following a test period without passwords two-weeks earlier. The planned change does not affect the ability to login to a GitHub account in a web browser with a username, password, and perhaps a …

  1. Blergh

    Isn't a token still just a password? It just isn't a user defined password.

    1. DavCrav

      Most problems with passwords fall into three categories:

      1) Reuse of passwords.

      2) Short and easy-to-guess passwords like yourefired or MAGA2020!

      3) Lack of encryption/salt on the server side.

      Tokens eliminate 1) and 2) at least, and if the token is exposed due to 3), it can easily be replaced. So it is an improvement.

      1. LDS Silver badge

        So, why don't use client certificates for the connection?

        They have all the advantages of tokens but it's far more complex to hardcode them into API calls...

        1. Richard 12 Silver badge

          Re: So, why don't use client certificates for the connection?

          Presumably because they're very difficult to create and use with Windows.

          1. LDS Silver badge

            Re: So, why don't use client certificates for the connection?


            It's far easier to use certificate with Windows than Linux. First, they are stored in a single place easily accessible and manageable instead of being scattered everywhere in the file system, to be managed manually. The only problem is when using idiotic languages and libraries which can't access the certificate store (or applications like Firefox who believe using only their own one is "clever").

            Generating certificates with a Windows CA is very simple, especially if you use templates, and enrolling can be even automated (or you can request them through a web interface).

            That said GitHub would just need to deliver client certificates to users, and could use whatever it likes to generate them, for example the "simple" and "user friendly" OpenSSL command line interface.... then uses will be free to store and use them as they prefer.

            1. LovesTha

              Re: So, why don't use client certificates for the connection?

              I'm wondering if Richard was confusing certificates with ssh id keys. Which are super easy in Linux and a huge pain in Windows, with essentially the same issue as you detail, just reversed in the systems.

              1. Cliffwilliams44 Bronze badge

                Re: So, why don't use client certificates for the connection?

                Not any longer. Windows now includes OpenSSH client which is functionally equivalent to the Linux version. No more messing around with Putty and Puttygen.

      2. Adelio

        So how does it work if you have multiple devices using a connection.

        i.e. My email is on my phone and my home PC and i am sure there are a lot of other applications where people have the same issue withh multiple devices

        1. Tomato42

          you register multiple tokens: one token per device

          github allowed to register multiple keys per account since "forever" (quite literally, I remember using them 8 years ago)

        2. bombastic bob Silver badge

          So how does it work if you have multiple devices using a connection.

          I can think of when this could really cause a problem, for me at least.

          a) Company has a paid-for github site to store source on, allowing 'work from anywhere'

          b) each embedded device I'm using for development has one or more copies of a github repo [sometimes different branches pre-checked out for comparison, let's say] and I'm constantly doing git pull/push from these various repos in various places to sync up with the online repo

          c) I can type in my password, which is complex and long, fairly easily. and I don't store it anyplace. My fingers do the motions accurately at least 90% of the time. It's over 10 characters long, has numbers and symbols in it, etc..

          So, what must I do *NOW* - copy/pasta a token from "someplace" every time I use git? STORE THE TOKEN(S) ON EACH DEVICE??? (*NO*!!!) This could end up creating a very unpleasant experience, effectively *PUNISHING* those of us who use proper passwords, because a *FEW* do *NOT*. it also may force updating the git software, WHICH! YOU! MIGHT! NOT! WANT! TO! DO! FOR! EMBEDDED! SYSTEM! DEVELOPMENT!!! You know, STABLE KERNEL and NOT having to deploy KERNEL/USERLAND UPDATES for air-gapped equipment because "some package" was updated on a dev system and NOW the compiled executables won't run... or a behavior changed... or something like that. yeah even Linux has package-dependency-hell to deal with, and when package 'a' drags in 'b' 'c' 'd' etc. and/or forces updates, it COULD (potentially) end up being a mess. And I really did NOT want to include 'selected .deb files' on the USB drives to update firmware, and have to test ALL of the NEW OTHERWISE-UNNECESSARY 3RD PARTY edge cases to avoid midnight phone calls. yeah I like to TEST before deploying,.

          1. LovesTha

            The logic goes that if you can't store the token on the device you shouldn't be accessing the repository from that device.

          2. Anonymous Coward
            Anonymous Coward

            I don't use GitHub but I have difficulty believing that the standard way is not to use SSH keys, just like with every other non-local Git repository out there.

            Of course you are still free to choose whichever passphrase you want for your SSH key, or even a hardware device if that's your preference.

          3. Ken Moorhouse Silver badge

            Re: copy/pasta

            GitHub is not the place for spaghetti code.

            (Sorry Bob, I'm sure you don't).

    2. Notas Badoff


      It isn't a user selected password, which is good. And it is 160 bits of _random_ goodness. But reading to end of linked document, yes, it looks like it simply replaces your dream password with the password dreamed up by Github.

    3. steelpillow Silver badge

      Better to think of a password as a user-defined, and hence badly-managed, kind of token.

      1. Anonymous Coward
        Anonymous Coward

        If you dont trust them to pick sane passwords why would you trust any code they've put on github?

        1. LovesTha

          Cause you can test their code.

          1. Anonymous Coward
            Anonymous Coward

            Oh right. So you're a cyber security expert who can soak test some code to make sure there are no holes whatsoever are you?

  2. This post has been deleted by its author

  3. Elledan

    SSH is the way to go

    I have always found SSH keys the most convenient to use with Git operations, whether on GitHub or anywhere else. First of all it's easy to setup, only requires the SSH password to remember instead of username/password combo, and it integrates well with automated services (e.g. CI/CD), which can use an SSH daemon to securely use the stored password for the SSH key.

    I had to look at the token-based approach in some depth while writing about this topic a while ago for Hackaday, and I'm not convinced that I would ever use it. Especially the part where you have to lug this (hardware) token around and remember the PIN for it seems like a bother. Plus I'm not really seeing how it'd make integrating with services any easier.

    1. bombastic bob Silver badge

      Re: SSH is the way to go

      I have always found SSH keys the most convenient to use with Git operations, whether on GitHub or anywhere else

      This may be true until you are working with multiple embedded devices, and workstations, and have to either AUTHENTICATE EVERY SSH KEY for EVERY DEVICE [and then make sure you erase them when that device gets turned into a test platform (where you still need github access to update it) and THEN suddenly ends up at a customer site for evaluation before you can say "OH CRAP NO!". So even if you erased the source repos in time, you still would need to deal with those ssh keys in ~/.ssh/ ...

      and... where can I safely store this alphabet-soup token such that it can be *EASILY* copy/pasta'd onto ANY device... ? yeah, thought so. And don't say 'USB stick' - some of the embedded devices will have all of the ports occupied already, for devices they control, at least for the stuff _I_ am working with.

      And access to YOUR login from "any machine" (remote workstations and embedded devices included) is a necessary feature sometimes. This way, anyone (or any device or workstation) needing a 'git clone' could get a quicky copy of the online repo without jumping through unnecessary hoops. Cheapo paid-for version of github limits the number of collaborators, after all...

      So many potential problems with devs like me, and yet independent devs or devs with individual logins ONLY dedicated to a particular company's stuff [and it's never "accidentally deployed"] won't have problems with this sort of thing.

      the only thing WORSE than this would be 2FA requiring a phone or e-mail to your home e-mail address [when you're on site and not having access to it and you don't want *THEM* having your cell phone number] in addition to user/pass and/or tokens.

      1. Anonymous Coward
        Anonymous Coward

        Re: SSH is the way to go



        > and then make sure you erase them when that device gets turned into a test platform

        And then remove the corresponding public part from the server when you're done with it. You can leave the private key in your devices; it is now useless.

        I feel that I shouldn't need to be mentioning this. Perhaps a short course on information security wouldn't go amiss, if I may suggest.

        1. bombastic bob Silver badge

          Re: SSH is the way to go


          using the same private/public key pair on multiple devices is a bad practice. That much SHOULD be obvious.

          1. Anonymous Coward
            Anonymous Coward

            Re: SSH is the way to go

            Maybe I misunderstand? What possible benefit would you gain from using multiple key pairs when the end goal is to authorise access to your code repository? I would only consider that if I needed to (weakly) authenticate or if there was a concern about compromise of one single device (where you only need to disallow that one key pair).

            Neither is the case in the scenario you described. If you were intending to use this in production then it would be a different matter but that doesn't appear to be the situation.

            So it is far from OBVIOUS to me, having had proper academic schooling and some hands-on experience in information security.

  4. karlkarl Silver badge

    After the deadline will we still be able to create new projects / accounts using SSH keys rather than this weird web-like authentication token nonsense?

    I only saw mention of "existing" things keeping with SSH keys.

    1. Soruk

      My reading of that is SSH keys will continue to work including for new setups and are not being deprecated.

    2. Anonymous Coward
      Anonymous Coward

      This is a good question that I think can be best answered as... for a while. I think you're seeing the end game pretty clearly.

      You store stuff in your home, does your realtor keep and cut your only keys? Of course what you put on GitHub isn't yours alone anyways, so why should the keys be yours? What amazes me is how easy it is to run your own Git server in the year 2020, and it has to be if it's Git, yet people just keep hoping on commercial alternatives. The whole thing is turning into "Get the next great Microsoft Office 20xx today!", which boils down to you didn't know you needed it, until you were told you did.

      GitHub/GitLab/etc. == Open Source Party Lines (just hope no one cuts your line)

      1. karlkarl Silver badge

        Hmm, this is what I was worried about. Luckily I only really use GitHub as yet another remote mirror (along with Bitbucket and GitLab) via "git cvsimport" but it is frustrating to see Microsoft demonstrate their same old crap over and over again. Actively avoiding corporations is getting boring.

      2. NullNix

        I'd bet that SSH keys will stick around, simply because they are ubiquitous in git usage and definitely not insecure -- but I suspect they'll start encouraging "sk"-format keys stored on U2F hardware tokens sooner or later, to prevent attackers stealing keys off client disks or out of client memory. (SK keys are new in OpenSSH 8.2+: it's the only hardware token mechanism I've ever found to be in any way usable. As long as both client and server are new enough -- a requirement, since this is a new key type -- I've found it as reliable as ordinary on-disk keys, something I could never have said of the old CCID-backed PIV or GPG-based nightmares.)

  5. Mike 137 Silver badge

    A self-defeating approach?

    Constantly trying to make it "safer" to be stupid by implementing point fixes to recognised poor practice after the fact doesn't prevent folks being stupid when using the fix. If the approach is used for long enough, there'll be no more point fixes possible and quite likely the things protected will be so surrounded by controls that they'll be unusable. And the folks who act stupidly will continue to do so.

    Just as an example of the kind of point fix I mean, our commercial telephone banking now disallows transactions over a randomly varying amount unless we accept a text message on a mobile phone for confirmation. Pointing out that a text message is entirely insecure and can be spoofed cut no ice at all with even a moderately senior manager. Pointing out that the assumption that everyone has a smart phone to hand is also bo**ocks cut no ice either. They're also trying to enforce voice recognition for authentication, despite quite a lot of authoritative research over the last few years proving it's fragile and breachable.

    1. iron Silver badge

      Re: A self-defeating approach?

      My bank requires me to use SMS TFA every time I log in to their website and again if I make a payment from their website. They also log me out after 90s of inactivity. Not to mention randomly when I'm using my card on other websites, even ones I use on a regular basis. It is a total pain in the arse, especially having to re-authorise every payment once I'm already on their website.

      I have pointed out to them that SMS is not secure, there are numerous groups who could intercept it and if I was mugging somone I'd steal their phone with their wallet making it moot. All they do is repeat the security lie, but louder. It's like dealing with my geriatric parents.

      1. karlkarl Silver badge

        Re: A self-defeating approach?

        I had the same issue. I contacted them to inform them I lost my phone. When they asked for a replacement number I told them I don't have one and that I no longer use phones. They looked at me strangely but it is not like they can leave the "stolen" number in their database. XD

        Their TFA then defaulted to email (again, not exactly secure) but at least I can avoid the creepyness of phones (and emails can be scripted).

    2. MOH

      Re: A self-defeating approach?

      I tried to set up a business bank account a few years ago. They required I set up two separate passwords, both subject to a string of restrictions - and both exactly 8 characters long. I used a different bank with a least a basic grasp of security.

      1. Missing Semicolon Silver badge

        Re: A self-defeating approach?

        8? Please tell us the bank, so we can pre-emptively avoid them!

        1. NullNix

          Re: A self-defeating approach?

          It's commonplace. Most banks have *ancient* systems, and this is just one of many ways that shows.

          If you want ridiculous, until last year the Coventry had a scheme where you had an eight-char password, uppercase alphanumerics only, changeable on request -- they posted you a form with eight boxes in it which you filled out and posted back, and then a few days later the password was changed. This was obviously grossly insecure so they pasted other security challenges over the top of it over time (and lately have replaced it entirely).

          I bet this is because the password in question was an actual mainframe account password of some sort, changeable only from an operator console. It had that smell. (This year, they changed to allowing really long passwords, and better yet passwords with no stupid restrictions on what characters must be present, so I can just use the result of a yubikey's HMAC-SHA1 challenge-response as the password. Finally.)

    3. bofkentucky

      Re: A self-defeating approach?

      At least in the US, only a few of the biggest banks maintain their own online banking, most buy an online solution from a turnkey vendor and skin it to their liking. Unless you get the ear of the C suite and think they can hire and retain enough talent to handle online banking, your complaints fall on deaf ears.

  6. Will Godfrey Silver badge
    Thumb Down

    You can't fix stupid

    This only makes things more complicated for folks who just want to get on with stuff, while the numpties will still find ways to screw everything up.

    1. DoctorNine

      Re: You can't fix stupid

      80%-20% rule. 80% of the population are of significantly limited cognitive function, and not to be trusted with sharp objects or life and death decisions. The remaining 20% struggle to keep everyone alive and functioning, whilst constantly under assault by those very semi-undead zombies surrounding them, who mistakenly believe that they understand what they are about, and try to 'help improve security' by random acts of self-defeating frippery.

      It has ever and always been this way.

      Although despair isn't a universal reaction to this fact, it is a common one.

      1. bombastic bob Silver badge

        Re: You can't fix stupid

        An 80%-20% rule sound ELITIST to me, _ESPECIALLY_ if it's used to justify some level of CONTROL over the 80%.

  7. Lucy in the Sky (with Diamonds)

    Squirrel Noises is the way to go

    As my Pointy-haired Boss decreed in a meeting back on the 9th of September 2005, "and starting today, all passwords must contain letters, numbers, doodles, sign language and squirrel noises." So, this is not a new thing, but Squirrel Noises is definately the way to go.

  8. paddy carroll 1

    Sick of Passwords

    I'm at an age where remembering a million passwords really doesn't work, Lastpass is freaking out at me for repeating and reusing and those twat companies that believe they can create some "not invented here" dumbass rule - thats you and just google "worst password rules"

    Give me a token anyday, please no arsing about with eminently knickable certs...

    rant over

    1. bombastic bob Silver badge

      Re: Sick of Passwords

      I've been using KeepassXC (the non-mono one) lately. works pretty well, and is still being maintained last I checked. I have a nice long true 'pass phrase' that I make mistakes typing in a lot, but fortunately there's an eyeball button so I can see what I just typed... and then correct it.

  9. david 12 Silver badge

    ...mission of replacing password authentication... odyssey that began in 1995 with the introduction of "Microsoft Passport.", marked also by the "Internet Tidal Wave" memorandum from B Gates.

    Passport got massive pushback at the time, because of reluctance to hand authentication to a company like (now) Google or Facebook ....

    #2:27 18-12-20#

  10. Anonymous Coward
    Anonymous Coward

    Not news

    Tokens have been around for ages, although they definitely got more popular since about five years ago.

    1. Anonymous Coward
      Anonymous Coward

      Re: Not news

      In the systems that I design, unless there is a compelling reason not to, users can have however many passwords they want, each username / password combination with its own set of permissions.

      This approach makes it trivial to incorporate tokens (just generate a random password for the user), and it also:

      * Lets the user “modulate” their permissions (sort of like using “su” when you need to rather than being logged in as root all the time)

      * Makes it trivial to implement panic passwords (if your requirements contemplate the possibility of users acting under duress)

      * Is practical for users who move between different keyboard layouts. E.g., they can have one password with a £ + @ and a similar one with # + " instead.

      * They can use a longer, more complex password when there is a risk of shoulder surfing and a simpler one when in a safe environment.

      * Etc.

  11. Anonymous Coward
    Anonymous Coward

    Isn't this

    what GitLab have been doing all along?

    I don't use GitHub so no idea how it works, but on GitLab you would normally use tokens and/or certificates for API access and pretty much everything else apart from the web interface itself.

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

Other stories you might like