Depois do incidente em que invasores conseguiram assumir o controle do pacote NPM, o GitHub usará autenticação de dois fatores para o NPM.
O GitHub lançou recentemente algumas mudanças no ecossistema NPM em relação aos problemas de segurança que têm surgido e um dos mais recentes foi que os invasores conseguiram assumir o controle do pacote NPM coa e lançaram as atualizações 2.0.3, 2.0.4, 2.1 .1, 2.1.3 e 3.1.3, que incluíram mudanças maliciosas.
Em relação a isso e com o aumento da incidência de apreensão de repositórios de grandes projetos e a promoção de código malicioso por meio do comprometimento de contas de desenvolvedor, o GitHub está introduzindo uma verificação de conta estendida.
GitHub usará autenticação de dois fatores para o NPM
Separadamente, para mantenedores e administradores dos 500 pacotes NPM mais populares, a autenticação de dois fatores obrigatória será introduzida no início do próximo ano.
De 7 de dezembro de 2021 a 4 de janeiro de 2022, todos os mantenedores que têm o direito de publicar pacotes NPM, mas não usam autenticação de dois fatores, serão transferidos para usar a verificação de conta estendida.
A verificação estendida envolve a necessidade de inserir um código exclusivo que é enviado por e-mail ao tentar entrar no site npmjs.com ou realizar uma operação autenticada no utilitário npm.
A verificação estendida não substitui, mas apenas complementa a autenticação de dois fatores opcional disponível anteriormente, que requer a verificação de senhas de uso único (TOTP).
A verificação estendida de e-mail não se aplica quando a autenticação de dois fatores está habilitada. A partir de 1º de fevereiro de 2022, começará o processo de mudança para a autenticação obrigatória de dois fatores dos 100 pacotes NPM mais populares com mais dependências.
“Hoje estamos introduzindo a verificação de login aprimorada no registro npm e começaremos uma distribuição escalonada para mantenedores começando em 7 de dezembro e concluindo em 4 de janeiro. Os mantenedores do registro Npm que têm acesso para publicar pacotes e não têm a autenticação de dois fatores (2FA) habilitada receberão um e-mail com uma senha de uso único (OTP) ao se autenticarem no site npmjs.com ou no Npm CLI.
Este OTP enviado por e-mail deverá ser fornecido junto com a senha do usuário antes da autenticação. Essa camada adicional de autenticação ajuda a evitar ataques comuns de sequestro de contas, como o preenchimento de credenciais, que usam a senha comprometida e reutilizada de um usuário. É importante notar que a Verificação de login aprimorada se destina a ser uma proteção básica adicional para todos os editores. Não é um substituto para 2FA, NIST 800-63B. Encorajamos os mantenedores a optar pela autenticação 2FA. Ao fazer isso, você não precisará executar uma verificação avançada de login.”
Depois de concluir a migração dos primeiros cem, a mudança se propagará para os 500 pacotes NPM mais populares em termos de número de dependências.
Além dos esquemas de autenticação de dois fatores baseados em aplicativos atualmente disponíveis para a geração de senhas de uso único (Authy, Google Authenticator, FreeOTP etc.), em abril de 2022, eles planejam adicionar a capacidade de usar chaves de hardware e scanners biométricos para que há suporte para o protocolo WebAuthn, bem como a capacidade de registrar e gerenciar vários fatores de autenticação adicionais.
Lembre-se que de acordo com um estudo realizado em 2020, apenas 9,27% dos gerenciadores de pacotes usam autenticação de dois fatores para proteger o acesso, e em 13,37% dos casos, ao registrar novas contas, os desenvolvedores tentaram reutilizar senhas comprometidas que aparecem em senhas conhecidas .
Durante a análise da força das senhas utilizadas, 12% das contas em NPM (13% dos pacotes) foram acessadas devido ao uso de senhas previsíveis e triviais, como “123456”.
Entre os problemas estavam 4 contas de usuários dos 20 pacotes mais populares, 13 contas cujos pacotes foram baixados mais de 50 milhões de vezes por mês, 40 – mais de 10 milhões de downloads por mês e 282 com mais de 1 milhão de downloads por mês.
Considerando a carga de módulos ao longo da cadeia de dependência, comprometer contas não confiáveis pode afetar até 52% de todos os módulos em NPM no total.
Finalmente, se você estiver interessado em saber mais sobre ele, você pode consultar os detalhes na nota original no seguinte endereço.