¿Por qué las claves PGP y SSH no tienen un uso más generalizado como segundo factor al autenticarse?

Veamos qué ofrecen PGP y SSH para este propósito:

• PGP:
  El cliente debe instalar el software PGP que no está instalado de forma predeterminada en la mayoría de los sistemas. El cliente debe crear un par de claves PGP. Luego, debe enviar la clave pública al servidor para que el servidor pueda usarla más tarde para la validación. Al autenticarse con 2FA, el servidor enviará un desafío que el cliente debe firmar con su clave privada y devolver el desafío firmado como respuesta. Por supuesto, el cliente debe proteger su clave contra el robo, tal vez con una contraseña.
• SSH:
  El cliente debe instalar el software SSH que no está instalado de forma predeterminada en la mayoría de los sistemas. Debe crear par de claves y enviar la parte pública al servidor. Al autenticarse con 2FA contra algún servicio web, el cliente debe crear una conexión SSH a un servidor relacionado y el servidor debe combinar la autenticación exitosa utilizando SSH y el inicio de sesión en el sitio web de alguna manera juntos, tal vez con algún token adicional que el cliente tenga para dar después de usar SSH. Y oops, podría haber un firewall en el modo de bloqueo de SSH. Y, por supuesto, el cliente debe proteger la clave contra el robo.

Por lo tanto, esencialmente ambas soluciones se reducen a:

• inicialmente instala algún software
• cree un par de claves estáticas y publique la parte pública (esto podría integrarse en el software por conveniencia, pero actualmente no lo está)
• de alguna manera obtén un desafío del servidor y de alguna manera devuelve el desafío firmado. Y de alguna manera el servidor debe integrar la validación del desafío en el proceso de autenticación. "de alguna manera" porque no hay un proceso ya establecido para esto que integre todo con el flujo de autenticación utilizado en las aplicaciones web.
• y, por supuesto, el cliente debe proteger su clave

El mismo procedimiento se puede hacer mucho más fácil con un certificado TLS del sitio del cliente. Esto todavía deja la creación del certificado como un problema importante (pero esto también es posible en el navegador hoy), pero al menos la validación ya está integrada en el protocolo HTTPS.

Además, no puedo ver cómo estas soluciones proporcionan una mejor experiencia de usuario o experiencia de integración que las soluciones 2FA existentes. No son fáciles de usar , requieren software adicional, requieren nuevas formas de integración con el servidor, etc. Y tampoco proporcionan una mejor seguridad . Entonces, ¿por qué preocuparse y no tomar las soluciones más nuevas que fueron diseñadas teniendo en cuenta la facilidad de uso y la integración del servidor?

Aparte de eso, las soluciones 2FA baratas actuales hacen uso de un teléfono móvil. Estos proporcionan generalmente una mejor arquitectura de seguridad que las PC actuales. Y son un dispositivo de hardware adicional al que el usuario debe tener acceso, lo que hace que la protección ofrecida por 2FA sea más sólida.

Falta de portabilidad

SSH y PGP son ampliamente utilizados, pero no son tecnologías web. Ha habido una tecnología web equivalente durante muchos años: certificados de cliente SSL. Sin embargo, esto no es muy utilizado.

La razón es la falta de portabilidad. Si tiene un certificado de cliente SSL en el escritorio de su hogar, es difícil moverlo a otro lugar. Por lo tanto, no puede iniciar sesión desde su computadora portátil de trabajo, el escritorio de su suegra, etc.

Existe una solución de certificado de cliente portátil que ha existido durante mucho tiempo y es de muy alta seguridad: las tarjetas inteligentes. La clave privada se almacena en la tarjeta inteligente y nunca se libera. Sin embargo, esto se ha visto principalmente en aplicaciones de alta seguridad, como la banca corporativa en línea.

A principios de la década de 2000, hubo una innovación limitada en torno a la autenticación. Los esfuerzos dirigidos al mercado masivo, como Microsoft Passport y OpenID, realmente no despegaron. La mayoría de los productos estaban dirigidos a la gama alta: acceso VPN corporativo, etc. Esto ahora está cambiando, y estamos viendo innovación en la autenticación del mercado masivo. Por ejemplo:

• Persona de Mozilla : esencialmente hace que un certificado de cliente sea portátil almacenándolo en la nube. Años atrás, esto habría sido rechazado como una idea loca, pero en los últimos tiempos el modelo de amenaza se comprende mejor y los beneficios son evidentes.

• U2F : trae la alta seguridad de las tarjetas inteligentes al mercado masivo. Los dispositivos son más portátiles y es seguro usar un dispositivo en muchos sitios web diferentes. Por lo tanto, U2F es una tecnología que se adapta perfectamente a los patrones de uso modernos, por lo que es un éxito.

Porque factores de autenticación adicionales deberían, idealmente, estar fuera de banda. Como un teléfono, un token o algún tipo de mensaje telepático.

U2F es bueno porque NO PUEDES extraer la clave privada y requiere un toque físico en el dispositivo antes de que firme.

Para el público en general, cualquier autenticación de 2 factores debe entenderse en menos de 2 minutos, de lo contrario, fallará muy rápidamente ya que pocas personas podrán entenderlo. Eso generalmente requiere el uso de algo con lo que la gente ya está familiarizada o es muy simple.

PGP y SSH son tecnologías complejas que muy pocas personas, excepto los desarrolladores y las personas de operaciones de TI entienden. Como Stephen señala, ambos requieren no solo instalar el software, sino también comprender métodos muy complejos para generar archivos, enviarlos a un tercero y, mucho peor, comprender los conceptos subyacentes involucrados. Para la persona promedio, esto llevaría muchas horas de entrenamiento, prueba y error, y conceptos completamente nuevos. Incluso entonces, tendrías altas tasas de fracaso.

Contraste eso con las soluciones que se utilizan en 2-factor. Mensajes de texto, tokens que muestran números o llamadas telefónicas. Los mensajes de texto y las llamadas telefónicas son cosas con las que las personas ya están familiarizadas. Un token duro es un poco más complejo, pero se puede entrenar a un usuario en menos de 2 minutos sobre cómo usar estos dispositivos porque son simples.

El complemento EnigForm FireFox fue un enfoque muy promisorio. Y en combinación con una tarjeta SmartCard OpenPGP, era al menos tan segura como FIDO U2FA. Es una pena que no haya tenido una adopción generalizada.

Dos cosas.

1. Es la forma en que siempre ha sido

La biometría o los tokens de hardware (como RSA SecurID) fueron el estándar para 2FA, y luego todos obtuvieron teléfonos celulares y luego teléfonos inteligentes. De repente, fue fácil crear un segundo factor enviando a las personas un correo electrónico a sus teléfonos inteligentes, a una aplicación en sus teléfonos inteligentes o un sms a teléfonos más antiguos.

El hecho de que pudieras usar un cifrado de clave pública en su lugar no se consideró un segundo factor, ya que normalmente usabas claves públicas en lugar de una contraseña. Esa era la percepción de la gente, y para ser honesta, hasta ahora tampoco había pensado mucho en ello.

2. Es menos seguro

Aunque un mensaje a una aplicación ya es más fácil de interceptar que RSA SecurID (o Yubikey u otro token de hardware) y, por lo tanto, es menos seguro, el uso de la autenticación de clave pública es incluso menos seguro que eso:

Un token puede ser interceptado mientras lo escribe, pero su clave privada puede ser robada de su computadora de una vez por todas. La fuente del segundo factor no está en un servidor (enviando mensajes de texto) ni oculta en algún módulo a prueba de manipulaciones (un token), es en el sistema que usa todo el tiempo para muchas cosas.

(Debe tenerse en cuenta que las tarjetas inteligentes resuelven esto, pero entonces, conozco muy pocas personas que usan eso fuera del trabajo).

Además, la mayoría de las otras respuestas incluyen "nadie tiene esto" de una forma u otra, y tienen razón. Pero la mayoría de la gente tampoco usa 2FA. Creo que la superposición entre la gente de tecnología que usa SSH y / o PGP y 2FA es significativa, invalidando el argumento de que nadie usa SSH, PGP o algo similar. Especialmente lugares como Github podrían ofrecer totalmente SSH como un segundo factor; ya son compatibles con las claves SSH (y la gente lo usa! ), pero no para 2FA.