2fa

Subscribe to all “2fa” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

~ cd github-changelog
~/github-changelog|main git log main
showing all changes successfully

Today we're enabling fine-grained personal access tokens (PATs) in Public Beta for all user accounts on GitHub.com. This new type of token gives developers and resource owners more control and visibility around token access. Learn more about this new token type in today's blog post.

These new tokens offer many more permissions to choose from, must be scoped to a specific organization or account, and must expire. Organization owners will also find new tools to manage tokens that can access their organization, and can require approval of those tokens before they may be used.

PATsv2-light2

You can try out the new token creation flow, and provide feedback in our community discussion.

For more information, see "Creating a fine-grained personal access token".

See more

Enterprise administrators can now choose to redirect signed-out Enterprise Managed Users to their company's single sign-on (SSO) page. This feature is available as a public beta.
By default, enterprises with Managed Users enabled are hidden, showing a 404 error page any time an enterprise resource is visited by a user that isn't already signed in to the enterprise.
If you enable this feature for your enterprise, visitors to resources in your enterprise, org, or user namespaces will immediately be presented with an SSO redirect if not already signed in to your enterprise.
This redirect helps users sign in to the correct account, rather than giving them the impression that the link they were given no longer works.

You can find this setting in the Authentication security section of your Enterprise Settings, below the single sign-on configuration sections.
image

Read more about this settings at "Automatic redirection for Enterprise Managed Users".

See more

Users with 2FA enabled may see false-alert flags in their security log for recovery_code_regenerated events between July 15 and August 11, 2022.
These events were improperly emitted during an upgrade to the 2FA platform. The storage format of the per-user value GitHub uses to generate your recovery codes was updated, causing the watch job to trigger the erroneous recovery_code_regenerated event.

No action is required from impacted users with regards to these events. GitHub has a policy to not delete security log events, even ones generated in error. For this reason, we are adding flags to signal that these events are false-alerts. No recovery codes were regenerated, and your existing saved recovery codes are still valid.

image

See more

When users access an organization with SAML SSO, GitHub stores a link between the SAML identity and the user's GitHub account. This link is used by SCIM and team synchronization to grant access within your organization or enterprise. If you break this link by signing into that organization with a different SAML identity, you are likely to lose access to resources inside that organization.

Starting gradually today and being fully rolled out tomorrow, users will see a warning message if they attempt to sign in with a different SAML account and change their linked identity. They'll have the option to go back to their IdP to sign in with a different account, which is usually the correct option. If they really intend to break the link to their previous SAML account and link to a new one, they can choose to continue.

Learn more by reading "About Authentication with SAML SSO".

See more

Two-Factored Authentication (2FA) is now enforced for maintainers of the top-500 packages, by dependents, on the npm registry.

To learn more about configuring 2FA, see Configuring two-factor authentication.
To learn more about 2FA in general, see About two-factor authentication.
For questions and comments, open a discussion in our feedback repository.

See more

GitHub changed which keys are supported in SSH and removed the unencrypted Git protocol.
You can read more about the motivation behind these changes in our blog post from last September.
As a reminder, these changes were:

  • Removed all support for DSA keys
  • Required SHA-2 signatures on all RSA keys uploaded after November 2, 2021 (RSA keys uploaded prior to the cutoff may still use SHA-1 signatures)
  • Removed legacy SSH algorithms HMAC-SHA-1 and CBC ciphers
  • Permanently disabled the unencrypted Git protocol
See more

The GitHub metadata endpoint now contains our SSH host keys.
(We'll continue offering host key fingerprints as well.)

{
  // new entry
  "ssh_keys": [
    "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl",
    "ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg=",
    "ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ=="
  ],
  // existing entry
  "ssh_key_fingerprints": [
    "SHA256_RSA": "nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8",
    "SHA256_ECDSA": "p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM",
    "SHA256_ED25519": "+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU"
  ],
  // ... rest of payload
}

These keys are in the OpenSSH known_hosts format for easy inclusion into existing known_hosts files.
This will make it easier to preconfigure systems which expect to connect via SSH.
For example, you can prime your CI runners with these keys before starting to fetch from GitHub.

The keys returned from the API include both SSH host keys that we're actively using, plus any that we're advertising via host key rotation for future use.
Currently, we're not offering any keys via rotation that aren't actively in use, but if we announce new host keys in the future, you can find them here as well during the rotation period.

See the meta API endpoint to learn more.

See more

GitHub recently introduced the ability to set an expiration date when creating or regenerating a personal access token (PAT). For a PAT that is authorized to access an organization protected by SAML single sign-on (SSO), the expiration date of that PAT is now available via the GET /orgs/{org}/credential-authorizations API.

Organization administrators can use the following gh command to see the expiration dates of all PATs that are authorized to access their org by authenticating with a PAT that has the read:org scope:

gh api --paginate /orgs/:org/credential-authorizations --jq='.[] | [.authorized_credential_expires_at]'

Learn more about authorizing a personal access token for use with SAML single sign-on.

See more

Recover Accounts Elsewhere allows a user to store a recovery token with a third-party recovery partner to use as a recovery method when their account is protected by two-factor authentication. Effective immediately, we will no longer be allowing new recovery tokens to be stored using Recover Accounts Elsewhere.

On December 1st, 2021, account recovery tokens stored using Recover Accounts Elsewhere will no longer be accepted as a recovery option when contacting support to recover access to your account. You will still be able to use our other recovery mechanisms to recover your account.

If you have registered an account recovery token using this feature, we recommend you take this opportunity to download your two-factor recovery codes. You can also revoke your recovery tokens using these steps:

  1. Navigate to the Account Security page.
  2. Scroll down to "Recovery tokens" and client "Edit".
  3. Click "Revoke token" for each token.

We'll be sending occasional email notifications throughout the deprecation period to all users with recovery tokens registered.

Questions? Take a look at our updated documentation on account recovery, or contact GitHub Support.

See more

GitHub will stop supporting API Authentication via Query Parameters with Actions on October 6th 2021 at 14:00 UTC. If you are passing credentials via query or path parameters, GitHub will respond with client errors. Please refer to this blog post for details on authenticating API requests to GitHub using the Authorization header.

Removal

  • October 6 2021 at 14:00 UTC
See more

As previously announced, on September 8th 2021 at 14:00 UTC, GitHub will stop supporting API Authentication via Query Parameters.

If you are passing credentials via query or path parameters, GitHub will respond with client errors. Please refer to this blog post for details on authenticating API requests to GitHub using the Authorization header.

Removal

  • September 8 2021 at 14:00 UTC

Please check the latest Enterprise release notes to learn in which version API Authentication via Query Parameters will be removed.

See more

As previously announced, starting on August 13, 2021, at 09:00 PST, we will no longer accept account passwords when authenticating Git operations on GitHub.com. Instead, token-based authentication (for example, personal access, OAuth, SSH Key, or GitHub App installation token) will be required for all authenticated Git operations.

Please refer to this blog post for instructions on what you need to do to continue using git operations securely.

Removal

  • August 13, 2021, at 09:00 PST
See more

As previously announced, on August 11 2021 at 14:00 UTC, GitHub will be removing the OAuth Application API to avoid unintentional logging of in-transit access tokens.

Please refer to this blog post on migrating to the replacement endpoints.

Removal

  • August 11 2021 at 14:00 UTC

Please check the latest Enterprise release notes to learn in which version the OAuth Application API will be removed.

See more

As previously communicated, on August 11, 2021 at 14:00 UTC for 48 hours, GitHub will be conducting the third and final scheduled brownout for API Authentication via Query Parameters.

If you are passing credentials via query or path parameters, GitHub will intermittently respond with client errors. Please refer to this blog post for details on authenticating API requests to GitHub using the Authorization header.

Brownouts

  • August 11, 2021: For 48 hours starting at 14:00 UTC

Removal

  • September 8 2021 at 14:00 UTC

Please check the latest Enterprise release notes to learn in which version API Authentication via Query Parameters will be removed.

See more

API requests made by a GitHub App on behalf of a user that has authorized the app are known as user-to-server requests.

The resources that can be accessed by these requests are constrained to the set of private resources that both the App and the authorizing user can access.

GitHub is now extending this access model, allowing user-to-server requests to also read public resources over the REST API. This includes, for example, the ability to list a public repository's issues and pull requests, and to access a public repository's comments and content.

Read more about authorizing GitHub Apps.

See more

You can now set an expiration date on your new and existing personal access tokens.

Setting an expiration date on personal access tokens is highly recommended as this helps keep your information secure. GitHub will send you an email when it's time to renew a token that's about to expire. Tokens that have expired can be regenerated, giving you a duplicate token with the same properties as the original.

When using a personal access token with the GitHub API, you'll see a new response header, GitHub-Authentication-Token-Expiration, indicating the token's expiration date. You can use this in scripts, for example to log a warning message as the expiration date approaches.

Learn more about personal access tokens and how to use them.

See more

As previously communicated, on June 9th, 2021 at 14:00 UTC we will be conducting the second scheduled brownout for API Authentication via Query Parameters and the OAuth Applications API. If you are passing credentials via query or path parameters, we will intermittently respond with client errors.

OAuth Application API

Please refer to this blog post on migrating to the replacement endpoints.

Brownouts

  • June 9, 2021: For 24 hours starting at 14:00 UTC

Removal

  • August 11 2021 at 14:00 UTC

Authentication via Query Parameters

Please refer to this blog post for authentication via headers.

Brownouts

  • June 9, 2021: For 24 hours starting at 14:00 UTC
  • August 11, 2021: For 48 hours starting at 14:00 UTC

Removal

  • September 8 2021 at 14:00 UTC

Please check the latest Enterprise release notes to learn in which version these functionalities will be removed.

See more

You can now authenticate to SSH using a FIDO2 security key by adding a sk-ecdsa-sha2-nistp256@openssh.com or sk-ssh-ed25519@openssh.com SSH key to your account. SSH security keys store secret key material on a separate hardware device that requires verification, such as a tap, to operate.

This combination of storing the key on separate hardware and requiring physical interaction for your SSH key offers additional security. Since the key is stored on hardware and is non-extractable, it can't be read or stolen by software running on the computer. Additionally, the tap prevents unauthorized use of the key since the security key will not operate until you physically interact with it.

Learn more about this feature from the accompanying blog post.

Learn more about adding an SSH key to your account.

See more

As previously communicated, on May 5th, 2021 we will be conducting the first scheduled brownout for API Authentication via Query Parameters and the OAuth Applications API. If you are passing credentials via query or path parameters, we will intermittently respond with client errors.

OAuth Application API

Please refer to this blog post on migrating to the replacement endpoints.

Brownouts

  • May 5, 2021: For 12 hours starting at 14:00 UTC
  • June 9, 2021: For 24 hours starting at 14:00 UTC

Removal

  • August 11 2021 at 14:00 UTC

Authentication via Query Parameters

Please refer to this blog post for authentication via headers.

Brownouts

  • May 5, 2021: For 12 hours starting at 14:00 UTC
  • June 9, 2021: For 24 hours starting at 14:00 UTC
  • August 11, 2021: For 48 hours starting at 14:00 UTC

Removal

  • September 8 2021 at 14:00 UTC

Please check the latest Enterprise release notes to learn in which version these functionalities will be removed.

See more

In February 2020, to strengthen the security of our API, we deprecated API Authentication via Query Parameters and the OAuth Application API to avoid unintentional logging of in-transit access tokens. In the coming months, we'll be removing these endpoints and authentication flow according to the following schedule:

OAuth Application API

Please refer to this blog post on migrating to the replacement endpoints.

Brownouts

  • May 5, 2021: For 12 hours starting at 14:00 UTC
  • June 9, 2021: For 24 hours starting at 14:00 UTC

Removal

  • August 11 2021 at 14:00 UTC

Authentication via Query Parameters

Please refer to this blog post for authentication via headers.

Brownouts

  • May 5, 2021: For 12 hours starting at 14:00 UTC
  • June 9, 2021: For 24 hours starting at 14:00 UTC
  • August 11, 2021: For 48 hours starting at 14:00 UTC

Removal

  • September 8 2021 at 14:00 UTC

Please check the latest Enterprise release notes to learn in which version these functionalities will be removed.

See more