GitHub dio a conocer recientemente algunos cambios en el ecosistema de NPM en relación a los problemas de seguridad que se han estado suscitando y uno de los más recientes fue que unos atacantes lograron hacerse con el control del paquete coa NPM y lanzaron las actualizaciones 2.0.3, 2.0.4, 2.1.1, 2.1.3 y 3.1.3, que incluían cambios maliciosos.

En relación a ello y con la creciente incidencia de la incautación de repositorios de grandes proyectos y la promoción de código malicioso a través del compromiso de las cuentas de los desarrolladores, GitHub está introduciendo una verificación extendida de cuentas.

Por separado, para los mantenedores y administradores de los 500 paquetes NPM más populares, la autenticación obligatoria de dos factores se introducirá a principios del próximo año.

Desde el 7 de diciembre de 2021 hasta el 4 de enero de 2022, todos los mantenedores que tienen derecho a publicar paquetes NPM, pero que no usan la autenticación de dos factores, serán transferidos para usar la verificación de cuenta extendida. La verificación extendida implica la necesidad de ingresar un código único que se envía por correo electrónico al intentar ingresar al sitio npmjs.com o realizar una operación autenticada en la utilidad npm.

La verificación extendida no reemplaza, sino que solo complementa la autenticación de dos factores opcional disponible anteriormente, que requiere la verificación de contraseñas de un solo uso (TOTP). La verificación de correo electrónico ampliada no se aplica cuando la autenticación de dos factores está habilitada. A partir del 1 de febrero de 2022, comenzará el proceso de transferencia a la autenticación obligatoria de dos factores de los 100 paquetes NPM más populares con la mayor cantidad de dependencias.

Hoy presentamos la verificación de inicio de sesión mejorada en el registro de npm, y comenzaremos una implementación escalonada para los mantenedores a partir del 7 de diciembre y concluyendo el 4 de enero. Los mantenedores del registro de npm que tienen acceso para publicar paquetes y no tienen autenticación de dos factores (2FA ) habilitado recibirá un correo electrónico con una contraseña de un solo uso (OTP) cuando se autentique a través del sitio web npmjs.com o la CLI de npm.

Esta OTP enviada por correo electrónico deberá proporcionarse además de la contraseña del usuario antes de autenticarse. Esta capa adicional de autenticación ayuda a prevenir ataques comunes de apropiación de cuentas, como el relleno de credenciales, que utilizan la contraseña comprometida y reutilizada de un usuario. Vale la pena señalar que la verificación de inicio de sesión mejorada está destinada a ser una protección básica adicional para todos los editores. No es un reemplazo para 2FA,NIST 800-63B . Alentamos a los mantenedores a optar por la autenticación 2FA. Al hacerlo, no necesitará realizar una verificación de inicio de sesión mejorada.

Después de completar la migración de los primeros cien, el cambio se propagará a los 500 paquetes NPM más populares en términos de número de dependencias.

Además de los esquemas de autenticación de dos factores disponibles actualmente basados ​​en aplicaciones para generar contraseñas de un solo uso (Authy, Google Authenticator, FreeOTP, etc.), en abril de 2022, planean agregar la capacidad de usar claves de hardware y escáneres biométricos para lo cual existe soporte para el protocolo WebAuthn, y también la capacidad de registrar y administrar varios factores de autenticación adicionales.

Recordemos que según un estudio realizado en 2020, solo el 9.27% ​​de los administradores de paquetes usan autenticación de dos factores para proteger el acceso, y en el 13.37% de los casos, al registrar nuevas cuentas, los desarrolladores intentaron reutilizar contraseñas comprometidas que aparecen en contraseñas conocidas.

Durante el análisis de la solidez de las contraseñas utilizadas, se logró acceder al 12% de las cuentas en NPM (13% de los paquetes) debido al uso de contraseñas predecibles y triviales como «123456». Entre las problemáticas se encontraban 4 cuentas de usuario de los 20 paquetes más populares, 13 cuentas cuyos paquetes se descargaron más de 50 millones de veces al mes, 40 – más de 10 millones de descargas al mes y 282 con más de 1 millón de descargas al mes. Teniendo en cuenta la carga de módulos a lo largo de la cadena de dependencias, comprometer cuentas que no son de confianza podría afectar hasta el 52% de todos los módulos en NPM en total.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en la nota original en el siguiente enlace.