6 conferências para a sua conta do GitHub não virar porta de entrada

A conta do GitHub de quem programa abre muito mais que o próprio código. Ela publica pacotes, dispara pipelines com acesso à nuvem, guarda segredos de projeto e, muitas vezes, entra em organizações de clientes. Quem toma a conta herda tudo isso.

Por isso vale uma revisão de meia hora, com a conta aberta ao lado. São seis conferências, cada uma com o que olhar e como saber se está certo.

1. A autenticação em dois fatores está ligada

Para boa parte de quem contribui com código, nem é mais escolha. Desde março de 2023 o GitHub exige 2FA de forma gradual de quem publica app ou action, cria releases ou administra repositórios importantes. Quem é selecionado recebe um e-mail, tem 45 dias para ativar e mais uma semana de carência. Depois disso, o acesso ao GitHub.com fica bloqueado até a ativação, e a conta bloqueada não autoriza apps novos nem cria tokens novos.

Não espere o e-mail. A ativação fica em Settings, Password and authentication, e leva cinco minutos com o celular na mão.

2. O método principal é um app autenticador

O GitHub trata o código de um app autenticador (TOTP) como o método principal recomendado. SMS é aceito em parte dos países, mas a própria documentação avisa que ele tem riscos de segurança que alguns cenários não toleram. Se o seu 2FA está no SMS, troque pelo app. Qualquer autenticador que gere códigos de seis dígitos a cada 30 segundos serve, e o código passa a viver no aparelho, sem depender da operadora.

3. Há um segundo método cadastrado

Passkeys e chaves de segurança físicas não servem como método principal no GitHub, mas servem como reserva, e o app GitHub Mobile também. A recomendação da documentação é ter dois ou mais métodos. O motivo é prático: celular perdido com o único autenticador é conta trancada.

4. Os códigos de recuperação estão guardados fora do celular

Ao ativar o 2FA, o GitHub entrega 16 códigos de recuperação, cada um de uso único. A orientação da página de recuperação é guardá-los num gerenciador de senhas e não compartilhar. Confira se você sabe onde estão. Se não sabe, gere uma lista nova em Settings, Password and authentication: a lista nova invalida a antiga.

5. As chaves SSH são todas suas, e todas atuais

Em Settings, SSH and GPG keys, cada chave mostra o nome e quando foi usada pela última vez. Chave de um notebook que você não tem mais, ou com nome que você não reconhece, sai. Uma chave por computador, com nome que diga qual é, torna essa conferência rápida.

6. Os tokens têm prazo e o menor acesso possível

Token pessoal (PAT) é senha com outro nome, e costuma ficar esquecido em arquivo de configuração. Em Settings, Developer settings, revise os tokens: apague os que não usa, prefira os de acesso refinado, limitados aos repositórios que precisam, e sempre com data de validade. Faça o mesmo em Applications, com os apps OAuth que você autorizou e não usa mais.

Um detalhe que pega muita gente: conta bloqueada por falta de 2FA continua com os tokens antigos funcionando. Bloquear a conta não desliga o que já estava emitido, e é por isso que a limpeza dos tokens não pode esperar o susto.

Depois da revisão

Marque na agenda a próxima, daqui a seis meses. A primeira conferência dá trabalho. As seguintes levam dez minutos, porque sobra pouco para limpar.

Se você administra uma organização no GitHub, a revisão tem uma segunda parte: quem ainda tem acesso, com que papel, e se a organização exige 2FA de todos os membros. Ex-funcionário com acesso de escrita a repositório de cliente é o tipo de coisa que ninguém lembra até precisar lembrar.

Fontes: GitHub Docs: 2FA obrigatória, GitHub Docs: métodos de recuperação

Produzido com auxílio de IA e revisado pela redação.