9 ms·
Deprecating password authentication in GitHub API
- ccmcarey 7y agoMight want to update the title to indicate that this is for the API.
- deno 7y agoAgree. The omission makes the title sound more sensational than it is. Token-only API authentication is not uncommon.
- ivoras 7y agoAh, progress! These days it comes in the form of replacing plaintext username+password with just plaintext passwords.
- ithkuil 7y agoThat's multiple plain text passwords, one for each use, with the ability to see when they have been last used and individually revoke them.
- oefrha 7y agoAnd more importantly, scopes, so that one token for posting gists can’t delete all your repos.
- Latty 7y agoUnfortunately not, GitHub tokens are (outside of GitHub actions generated tokens) scoped for your entire account, which sucks. It should be an advantage though.
- deleted 7y ago[deleted]
- oefrha 7y agoWhat are you talking about? Personal access tokens are scoped.
- ithkuil 7y agoI had the same reaction then I re-read the comment and realized it was correct. The granularity of Personal access tokens scopes is focused on what kind of actions you can perform on which kind of objects, but you cannot limit it to one single repository or to one single organization you belong.
- vbezhenar 7y agoHTTPS can use client certificates. While browser UI is not very nice for ordinary users, it seems like the best solution for API. I don't understand why isn't it used everywhere.
- dtech 7y agoBecause it is very complicated in both terms of UI and mechanics, and provides little to less additional security if you don't understand. Just think of all the online sites that offer to verify or do something else that openssl can do if you paste your cert and private key. Most devs by now know not to do that with a password or API key, but it's the first thing people will do with private keys.
- u801e 7y ago> Because it is very complicated in both terms of UI and mechanics Yet every Github user is expected to generate a ssh keypair and copy/paste the public key when setting up the account. > Most devs by now know not to do that with a password or API key, but it's the first thing people will do with private keys. But they can handle submitting the ssh public key without any issue. Also, they most likely are not using online tools to generate their ssh key pair. I don't see why they would do that with openssl.
- ccmcarey 7y agoThe added security comes through how the new "plaintext password" is randomly generated (so you don't have to worry about users picking bad passwords). ~~Although it seems PATs are ~42 bits, which seems a little low~~
- recursive 7y agoI didn't even know access tokens were a thing until just right now. In my reading about them, I found this, which has a screenshot, which suggests the token has ~40 hex digits. Assuming they're independent and random, that yields ~160 bits. Where are you seeing 42? https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line https://help.github.com/en/github/authenticating-to-github/c...
- ccmcarey 7y agoWow, I completely messed up characters and bits.
- dtech 7y agoAs username is public, it provides no security. So 1 account password with likely low entropy has been replaced with application-specific high-entropy passwords. This is an improvement.
- Nextgrid 7y agoWouldn’t the low-entropy password still work on the web interface, and if so why is it an improvement? Any brute force attempts can very well be done on the web interface, and if there are countermeasures why can’t they be used on the API endpoints?
- nullandvoid 7y agoIsn't the idea you would have 2 factor auth on your account preventing any web brute force. Then generate API keys on a per project reducing the attack surface in the case of breach?
- Nextgrid 7y agoYes that’s correct, but if you choose to not use 2FA for whatever reason I don’t see why password auth shouldn’t be supported on the API instead of making you waste time generating an API key that won’t actually improve security in any way (since attackers can brute force the account anyway).
- maxerickson 7y agoEasily revoked strong passwords that are less problematic to store on shared systems.
- noncoml 7y agoFeature request: allow association of the same ssh key with multiple accounts. In essence stop using git username globally and start supporting user names.
- sleepychu 7y agoWhy would you want this though? Your multiple git accounts are not the same identity.
- noncoml 7y agoSSH treats the key as password, you can have the same authorized key associated with multiple accounts. Not sure why you choose to look at the key as identity.
- sleepychu 7y agoSSH treats your key as evidence of your identity. You can choose to give the public half of your key to multiple entities to allow them to verify your possesion of the private half of the key but that does not translate into multiple identities.
- oefrha 7y agoI was once told explicitly by GitHub Support (just as a reminder) that one person having multiple accounts is against their TOS, so there’s that. (This was years ago, not sure if TOS has changed in this aspect.)
- cap10morgan 7y ago> During a brownout, password authentication will temporarily fail to alert users who haven't migrated their authentication calls. This took me a second to correctly parse. Would have been better written as: “During a brownout, password authentication will temporarily fail. This is to alert users who haven't migrated their authentication calls.”
- jonahx 7y agoThis confused me too. It also confused me that they only occur for 3 hour periods on 2 specific days. You wouldn't be "alerted" unless you happened to attempt login during those windows. Can anyone provide more context for this deprecation strategy?
- sv9 7y agoThey're going to make the service fail during a known period so people will know they haven't migrated.
- zikzak 7y agoThey might have determined that the bulk of the accounts that were going to authenticate (active accounts) would do so during these periods so they'd reach the vast majority of accounts without breaking the systems using those accounts severely. This might be better than refusing we queries at random, I think.
- tialaramex 7y agoBest to compare Brownout to other strategies that get to the same end result. The goal is that this feature (password authentication) goes away. A common default is a flag day. There's an announcement (maybe now) and on a set date that feature just goes away. For users who pay attention (say, us) and prioritise accordingly these strategies are the same, they know the feature it going away and can plan for that. But for users who weren't paying attention or who didn't correctly prioritise, adding a Brownout offers some final warning that helps push more people to start preparing before the final flag day happens. It doesn't need to get everyone, if 80% of users whose business processes still depend upon password authenticated GitHub notice something went wrong, and during diagnosis discover that what went wrong is they're relying on a deprecated feature, that's a big improvement over 100% of those processes dropping dead on flag day. Brownout is a desirable choice where you're sure that some large population will not heed the advance notice. I bet that a lot of corporate GitHub setups have all contact mail from GitHub either going to /dev/null or to some business person who hasn't the first clue what "password authentication on the GitHub API" is. Maybe they'll email the right dev person, maybe they forward to an employee who left six months ago, either way it's far from certain anybody who needs to take action will learn from an email. With UX feature deprecation you can tell the live users of the service. But in APIs even if you notionally have a way to feed stuff back (like a "warnings" field in the results) it's probably blackholed by lazy programmers or lands in a debug log nobody reads. So "It stopped working" is the best way to get attention, but without a Brownout that's permanent. The user learns what's wrong too late to do much about it which sucks. Brownout is something ISRG's Let's Encrypt has used, because of course Let's Encrypt is largely an API too, they publish feature changes but a huge fraction of all their subscribers aren't paying attention so the Brownout is the first they'll know anything is happening that matters to them.
- fergie 7y agoSlightly alarming that github has allowed username:password on api calls up to now- they have definitely kept quiet about it
- nlolks 7y agoThanks for comments !
- derefr 7y ago> All password authentication will return a status code of 401... I’ve always found it strange that an HTTP 401 is used to indicate two very different server-side states: • “this resource requires authentication, and you didn’t attempt authentication” • “as an early step in the request flow, you tried to authenticate yourself—but your authentication failed (due to e.g. having an unrecognized username; or using the wrong authentication method; or, of course, having the wrong password)” I mean, I get it; in the end, after trying and failing to authenticate, the request-processing continues (with the “auth” field in the server’s model of the request state being nil, just like it would be if you hadn’t attempted auth); and the request you’re making at that point is still an attempt to request an authentication-required resource. You’re “not authenticated” at that point, so 401 it is. But it really seems like auth processing should have its own “off ramp” in the HTTP request-processing lifecycle—i.e. if you ask for auth, and auth fails, you get a code and the request isn’t processed any further, so it doesn’t matter that the request you made is auth-required. (After all, we mentally model HTTP resources, fundamentally, as URLs; and URLs put the auth stuff in the origin part, not in the request sent to the origin part. I would naively expect that an auth failure would resolve at the same stage as an unrecognized Host name!) When you’re coding an HTTP client, it’s very hard to debug a corrupt Authorization header, because all you know, when you have anything even slightly wrong, is that the server is pretending it didn’t see it! ----- And yeah, I know, in practice, why this isn’t the way things are. Historically, one of the first uses of the Authorization header was through Apache’s mod_auth_basic, which refers to an .htpasswd file in a directory to determine the set of valid auth credentials for all resources descending from that directory. In this model, auth is resource-specific, rather than server-specific; so it makes sense that, if you’re sending auth, and auth is unrecognized, but the specific resource you’re authing against turns out to not require auth, then the server can proceed just fine without sending you a 401. However, I don’t think there’s any modern use-case where auth is resource-specific like that. HTTP auth “realms” are almost always per-origin these days. It makes a lot more sense to think of auth as something happening at the level of an implicit HTTP gateway between the client and the server ultimately sending the resource, where the gateway can know what server (realm) the client wants to route to—and so can auth the client on that basis, and deny the request if that auth fails—but the gateway can’t know anything about what the auth requirement policies are for individual resources on the backend it’s sitting in front of.
- u801e 7y agoWhat is not secure about using HTTP basic auth over a properly secured HTTPS connection?
- nnutter 7y agoHaven’t read the article yet but I will be surprised if it claims that. I would imagine it’s more about using your primary means (password) of authn which has worse consequences than using a secondary, revocable means (token) upon compromise.
- nnutter 7y agoA comment below also points out the token ensures a higher quality secret is being used most of the time. Edit: typo
- u801e 7y agoThe blog post[1] that the article links to does state: >> We are announcing deprecations that will improve the security of GitHub apps and APIs [1] https://developer.github.com/changes/2019-11-05-deprecated-passwords-and-authorizations-api/ https://developer.github.com/changes/2019-11-05-deprecated-p...
- ptoomey3 7y agoIt’s not at all about the security of delivering credentials over https, but more about the the complexity of trying to defend against weak passwords/credential stuffing with an api. For example, it’s more or less impossible to add a defense in depth flow like https://github.blog/changelog/2019-07-01-verified-devices https://github.blog/changelog/2019-07-01-verified-devices to an api.
- u801e 7y ago> it’s more or less impossible to add a defense in depth flow like https://github.blog/changelog/2019-07-01-verified-devices https://github.blog/changelog/2019-07-01-verified-devices to an api. Except that email, as described in the blog you linked to, is not a secure means of communication. What would be secure is to use a client side TLS certificate as part of the authentication process. That is, your browser/device sends it as part of the TLS connection negotiation process and then you authenticate via the username and password (via HTTP basic auth). They're already doing something like that whenever one pushes or fetches from a git repository hosted on Github through ssh key authentication. It wouldn't be much of a stretch for Github to allow an account holder to upload a CSR and then Github signs it and makes a certificate, which the account holder can then add to the browser's or OS's certificate store.
- miken123 7y agoWondering when they will start with implementing proper access controls on their API's. At the moment, a personal access token does have scopes, but it is quite limited: - Repo access is all or nothing. A read-only token is not possible, an 'issues-only' token is not possible. - Personal access tokens are not scoped to repositories or organizations. So your personal toy project token also allows access to your super-sensitive employer's repository. On top of that, your employer is unable to prevent this, unless you start using Github Enterprise _and_ an SSH CA, which is far from trivial. It's nice that they drop username/password access, but as long as personal access tokens have such broad permissions, it does not really add any value (you should have been using 2FA anyway).
- whoisthisfor 7y agoAdding to this wish list, the ability to rotate a token automatically. I'd like to do something like this with secrets manager, but GitHub's API just doesn't allow it - https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets-lambda-function-overview.html https://docs.aws.amazon.com/secretsmanager/latest/userguide/...
- Latty 7y agoWhat is really weird is this isn't quite correct, they do have scoped personal access tokens, you just can't make them. If you use GitHub actions, it generates a scoped PAT that only works for that repository for your actions to use. I use deploy keys rather than a PAT as they can be scoped (single repo and can be read-only), but they are more work and are limited to git actions rather than the whole GitHub API. The fact they clearly have the internal capability for this makes it incredibly odd they aren't exposing it for users to use, and I agree it'd be a really valuable thing to have.
- ptoomey3 7y agoGitHub Actions tokens are actually based off our newer “GitHub apps” system and not “OAuth apps”. GitHub app tokens support much more granular controls (both in terms of abilities and resources). OAuth doesn’t lend itself to super granular controls since they are scope based (ex. Defining a scope per repository doesn’t really scale). This whole area is something we want to address with personal access tokens in the future.
- teknopaul 7y agoBreaking apis, is breaking apis. Even for security reasons. Removing something that works is not, in itself, "improving" security. It is breakage in the holy name of security. If you have broken your system in the name of security it is not a more secure system. Its just a broken system that does not do its job. It might be "more secure" when users fix api usage, in the mean time its useless and is going to cost everyone time & money to fix. It might makes more sense in the long run to move to something with a stable api.
- jimmaswell 7y agoEverything is getting more and more complicated for hobbyists over time. Mandatory HTTPS certs coming eventully, APIs forcing more convoluted authentication methods, GDPR compliance (probably going to scare away a lot of people from doing anything like writing a twitter clone hobby project, or even static sites where they might have to spend extra time configuring access logging) and other burdensome laws like the one from California, getting whined at if anyone catches a whiff you use passwords to log into SSH. So many barriers that less people are going to end up participating.
- Carpetsmoker 7y ago> APIs forcing more convoluted authentication methods It's not really that convoluted: it's just setting a header with a fixed token, which is actually simpler than HTTP auth.
- bullen 7y agoI think the auth method is slightly less important than the offered feature set. F.ex. you cannot ask if a specific user has sponsored you and for how much. This is probably the ONLY important feature to have an API for! The only way to get this data now is to paginate through all sponsors with their GraphQL interface!
- wildpeaks 7y agoWhat I'm most worried about is the deprecation of Personal Access Tokens because I have yet to find the equivalent for doing something like "Create a Deployment with a single cURL request to the Github API" that will work past September. I wish they replaced it by tokens tied to specific repos and with scopes instead of that new Webapp Flow thing that looks a lot more complicated to implement than a curl request (I had planned to look into it this month, but obviously other worldwide events took priority).
- kens 7y agoIs anyone else bothered by the use of "deprecating" to mean "removing"? Historically, deprecated features are ones that still exist, but their use is discouraged.
- larzang 7y agoAnd it does still exist, until November. Deprecation is a transition period, instead of just removal without warning, but without future scheduled removal then deprecation would serve no purpose.