2FA obligatorio en GitHub: una entrevista con el jefe de seguridad Mike Hanley

Los ataques a las cadenas de suministro de software han aumentado en los últimos años. Los atacantes se sienten particularmente tentados a inyectar código malicioso en las bibliotecas de software utilizadas por muchos otros proyectos. La plataforma de alojamiento de código GitHub planea exigir a todos los usuarios que aporten código que aseguren su inicio de sesión con un segundo factor, como una contraseña única de la aplicación (2FA) a finales de este año. en muchas publicaciones GitHub anunció el cambio. Desde el 13 de marzo, se solicitó a los primeros usuarios que cambiaran. No hemos hablado con Mike Hanley, director de seguridad y vicepresidente sénior de GitHub, sobre la transición.

c’t: GitHub ha hecho gradualmente obligatoria la autenticación de dos factores desde marzo. El proceso debería estar concluido a finales de año. ¿Cómo empezó esto?

mike hanley: Comenzó en noviembre de 2021. En el registro de npm propiedad de GitHub, hubo algunas protestas (nota: los desarrolladores desconectaron sus repositorios o los bloquearon como protesta) y la cuenta de administrador de un paquete popular fue secuestrada. Esto permitió al atacante distribuir código malicioso. Este es un vector de ataque atractivo porque puede descargar código malicioso entre 10 000 y 100 000 veces más rápido, incluso si el problema se soluciona rápidamente. En respuesta, hicimos obligatoria la autenticación de dos factores en npm poco después. Hemos aprendido mucho en el camino y ahora queremos ofrecer la misma experiencia de usuario en GitHub.com.

c’t: GitHub tiene más de 100 millones de usuarios. ¿No se espera que el cambio obstaculice su trabajo?

Hanley: Tenemos un 2FA obligatorio para los usuarios que aportan código en GitHub.com, Anunciar con un año de anticipación, por lo que las empresas y la comunidad de código abierto están dispuestos. A fines del año pasado, informamos marzo como la fecha de inicio planificada. Desde el 13 de marzo, estamos dividiendo a los usuarios en grupos que necesitan un segundo factor para iniciar sesión. Por cierto, muchos usuarios del primer grupo ya han activado 2FA. También hay un generoso plazo de 45 días después del aviso, que puede extenderse por otra semana. Luego, cuando inicia sesión en GitHub.com, debe configurar un segundo factor como SMS, TOTP (contraseña de un solo uso basada en el tiempo) o usar GitHub Mobile. Recomendamos claves de seguridad para WebAuthn. Este es el método de autenticación más seguro actualmente disponible.

c’t: Pero no todo el mundo tiene acceso a estas claves de seguridad. La clave FIDO2 cuesta unos 50 euros.

Hanley: Sí, no son baratos. Queremos asegurarnos de tener métodos de autenticación seguros y no dejar a nadie fuera. Por eso también permitimos SMS como segundo factor, aunque la alternativa es menos segura que las demás. Hay que comprometerse para que la gente pueda seguir participando en los proyectos. Pero podemos intentar empujar a los usuarios hacia métodos de autenticación más seguros en algún momento.

C’t: ¿Cómo debería ser eso?

Hanley: Mostramos a los usuarios a intervalos regulares qué métodos de autenticación de dos factores han activado, si han impreso sus códigos de respaldo y preguntamos si todos estos mecanismos aún están actualizados. Esto se puede modificar fácilmente. Si solo tienes SMS como segundo factor, podemos señalar que también pueden usar GitHub Mobile, la aplicación TOTP o llaves de seguridad. Eventualmente podemos avanzar por un camino más directo, pero por ahora es importante para nosotros que los usuarios almacenen el segundo factor más seguro que tienen actualmente.

c’t: ¿Por qué los usuarios no eligen voluntariamente la autenticación de dos factores?

Hanley: Hay dos razones para esto. Si eres un desarrollador, no necesariamente tienes que asumir las consecuencias de cualquier incidente de seguridad. Esto no quiere decir que asuma que tienes malas intenciones, todo lo contrario. Pero si su cuenta es pirateada, el código malicioso puede filtrarse rápidamente en un paquete que utilizan cientos o miles de personas porque es parte de la cadena de suministro de software. Si la cuenta solo está protegida con una contraseña, puede tener un gran impacto. Además, creo que muchas de las integraciones de autenticación de dos factores no están bien implementadas.

No: ¿En términos de facilidad de uso?

Hanley: Sí, muchos profesionales de la seguridad son buenos para crear soluciones que creemos que son las mejores para los usuarios sin siquiera hablar con ellos. Pero esto es una trampa. Tal vez esté creando algo basado en un montón de suposiciones, pero los usuarios ocasionales o los desarrolladores sin experiencia en seguridad piensan: “¿Cuál es el punto? La forma en que funciona no tiene sentido para mí”.

c’t: La publicación del blog que anuncia el cambio establece que los usuarios que no activen 2FA después de la fecha límite no podrán usar algunas funciones hasta que lo hagan. ¿Quiénes son?

Hanley: Ya no podrá contribuir con código. Sin embargo, aún puede iniciar sesión y usar las otras funciones de GitHub.com. Predigo que a medida que avanza el año, cuantos más grupos nos adherimos a 2FA, más organizaciones y proyectos de código abierto en GitHub harán que 2FA sea un requisito para ser miembro. Creo que esto será otro incentivo para cumplir con este requisito.

c’t: Los beneficios de la autenticación de dos factores (2FA) para las organizaciones pueden ser obvios, pero muchos usuarios siguen siendo escépticos. Cuando Hayes informó en línea sobre los requisitos de 2FA de GitHub, un lector comentó: “¿Qué pasa si mi casa se incendia y mis claves de seguridad, teléfono inteligente y respaldo desaparecen? ¿Mi cuenta de GitHub está bloqueada para siempre?” que respondes

Hanley: Los desarrolladores son responsables de cuidar el plan de copias de seguridad. Esto puede tomar la forma de imprimir sus claves de respaldo y guardarlas en un lugar seguro, o asociar múltiples claves de seguridad con la cuenta. He vinculado GitHub Mobile en mi teléfono inteligente y varias claves de seguridad FIDO2, no todas locales, para asegurarme de no perder el acceso a los sistemas y la infraestructura. Recomendamos a todos los usuarios que hagan algo similar.

También verificamos regularmente si los usuarios aún pueden acceder a sus segundos factores e invertimos en nuestro soporte para que podamos ayudar a restaurar el acceso a la cuenta. Pero hacerlo bien es uno de los mayores desafíos. Lo último que queremos es crear vulnerabilidades a través del proceso de recuperación que pongan en riesgo a los desarrolladores y sus cuentas.

c’t: 2FA aumenta la seguridad, pero también hay vulnerabilidades, como el llamado agotamiento de MFA: digamos que el atacante conoce el nombre de usuario y la contraseña del desarrollador y ahora inunda el teléfono inteligente de la víctima con solicitudes de autorización hasta que son aceptadas. ¿Cómo se puede contrarrestar esto?

Hanley: La autorización a través de GitHub-Mobile va más allá de la simple afirmación. También debe comparar los números que se muestran con los números en la interfaz web. Esto no es ideal, ya que el atacante podría hacerse pasar por soporte de TI, por ejemplo, para marcar números, pero esto es mucho más difícil que otros ataques de spam instantáneo que utilizan métodos basados ​​en push que no incluyen este mecanismo.

c’t: ¿Qué pasa con los proxies inversos que se hacen pasar por sitios como Google o GitHub para interceptar tokens TOTP o robar cookies de sesión? Encontramos algunos de estos proyectos en GitHub.

HanleyLa mayoría de estos sofisticados ataques de phishing implican cierto nivel de engaño o ingeniería social. Como atacante, debe proporcionar a la víctima una URL que se parezca a GitHub.com. O puede que necesite ocupar una posición privilegiada en la red para poner el sitio frente a las víctimas. Algunos métodos de autenticación son vulnerables a estos ataques. La mejor protección es usar claves de seguridad FIDO2 para WebAuthn como segundo factor porque son resistentes al phishing.

c’t: la autenticación segura es un paso importante para proteger las cadenas de suministro de software. ¿Entonces que?

Hanley: Espero que haya más trabajo por hacer una vez que se complete la transición a 2FA obligatoria a finales de año. Podemos concluir que ciertos grupos de desarrolladores son un objetivo particularmente atractivo y ofrecerles medidas adicionales para proteger sus cuentas. Podríamos ofrecer políticas grupales a desarrolladores y organizaciones que, por ejemplo, solo desean desarrollar dentro de los espacios de código de GitHub, es decir, en una máquina virtual segura en la nube.

Así es como trabajamos en GitHub, donde todo está construido en un entorno de desarrollo alojado y seguro llamado Codespace, que también ofrecemos a nuestros clientes. En lugar de proteger miles de códigos de empleados, entornos de compilación locales y entornos de desarrollo locales, podemos centrarnos en proteger este punto y solo debemos asegurarnos de que todos los navegadores y sus dispositivos estén actualizados y cumplan con nuestros estándares de seguridad.

(ndi)