¿Cuáles son los riesgos potenciales de usar PGP para iniciar sesión en el sitio web?

Como esto es para propósitos de educación / aprendizaje y no una solución de producción, las advertencias normales sobre no lanzar sus propias soluciones de seguridad no se aplican. Sin embargo, todavía recomiendo encarecidamente ver algunas de las soluciones establecidas, posiblemente hacerlo después de intentar su propia solución es una buena idea, ya que puede comprender por qué las cosas se hacen de cierta manera o algunos de los problemas son un poco más.

Algunas cosas que debes considerar con tu solución (justo en la parte superior de mi cabeza, no hay un pensamiento realmente profundo).

• Cortar y pegar, o usar el portapapeles generalmente tiene varios riesgos de seguridad. La última vez que miré (hace ya un tiempo), Metasploit incluso tenía un módulo que podría usar para robar el contenido del portapapeles.

• Su esquema realmente solo proporciona garantías en una dirección. No hay nada que me impida obtener su clave pública, falsificar el sitio y luego crear una situación en la que crea que se autentica contra el sitio, pero en realidad se autentica contra mi sitio falso. Problemas similares con el hombre en el ataque central: el atacante puede simplemente pasarle la cadena cifrada, recuperar su versión desencriptada y luego iniciar sesión en el sitio. Deberá asegurarse de que sus conexiones están a través de SSL con un certificado SSL válido y verificable.

• Aleatoriedad de cadena de 1000 caracteres. Esta es a menudo la gran debilidad. Variar es difícil generar aleatoriedad real y es por eso que algunos programas que requieren aleatoriedad harán cosas como que muevas el mouse mientras se genera el valor aleatorio. Si su cadena inicial de 1000 caracteres es totalmente predecible, entonces sería posible reducir el espacio de búsqueda para las versiones descifradas de la cadena y evitar efectivamente la necesidad de tener su clave privada para descifrarla.

¿Qué estás tratando de lograr realmente? Su sistema parece ser una autenticación de dos factores ... sin el primer factor (la contraseña) y la complejidad adicional de tener que usar PGP.

Sin ningún orden en particular:

• ¿Protege su clave PGP con una frase de contraseña? Si es así, ¿está almacenado en la memoria caché o tiene que escribirlo cada 5 minutos? Si no, es probable que estés haciendo algo mal.
• ¿Por qué 5 minutos? ¿Por qué es esto mejor que una cookie de sesión razonablemente implementada?
• Cuestionaría la utilidad de tu esquema; y con mala usabilidad viene el hábito y terminas bajando la guardia.
• ¿Cómo obtiene su clave pública en el servidor? Si es un mecanismo automatizado donde el servidor lo recupera de un servidor de claves dado un ID de clave, entonces su sistema es vulnerable a un ataque MitM trivial. Si necesita transferir su clave al servidor fuera del canal, entonces estaría mucho mejor con una sesión ssh y una redirección de puertos.

No me malinterpretes, la idea suena agradable. Me encantaría si pudiera elaborar más, por ejemplo, cuáles son sus objetivos, cómo mide una mejora en la seguridad, etc., etc.

El riesgo es que la seguridad obstaculice la usabilidad hasta el punto en que nadie usará el sistema.

Está haciendo una autenticación de usuario de cliente asimétrico (a.k.a) aquí. Básicamente esto está bien.

Pero piensa en esto: ¡Lo que implementaste aquí ya existe! Se trata de las calles TLS y TLS de autenticación de cliente.

Puede configurar su servidor web para que requiera un certificado de cliente para iniciar la conexión TLS. Cada navegador soporta el uso de certificados de cliente. Todos admiten certificados blandos en el navegador / almacén de certificados y pueden proteger la clave privada con una frase de contraseña.

Algunos navegadores también admiten el uso de tarjetas inteligentes (IE, Firefox a través de PKCS11), por lo que la clave privada está contenida en una tarjeta inteligente y nunca dejará esto.

(Dejando la verificación del certificado fuera de alcance aquí) el servidor hace exactamente esto. El servidor envía un desafío (a.k.a. tu cadena aleatoria de 1000 caracteres) al navegador. El navegador firma esto con su clave privada, después de que proporcionó la frase de contraseña. Los datos se envían de vuelta al servidor y el servidor puede verificar la firma con su clave pública. Hecho.