Cifrado de contraseña bidireccional sin ssl

Question

Estoy usando la API de twitter de basic-auth (no longer available) para integrar Twitter con el sistema de comentarios de mi blog. El problema con esta y muchas otras API web es que requieren el nombre de usuario y la contraseña del usuario para hacer algo útil. No quiero lidiar con la molestia y el costo de instalar un certificado SSL, pero tampoco quiero que se pasen las contraseñas por cable en texto claro.

Supongo que mi pregunta general es: ¿Cómo puedo enviar datos confidenciales a través de un canal inseguro?

Ésta es mi solución actual y me gustaría saber si hay agujeros en ella:

1. generar una clave aleatoria en el servidor (estoy usando PHP).
2. Guarde la clave en una sesión y también envíe la clave en una variable de JavaScript.
3. Al enviar el formulario, use Triple DES in javascript con la clave para encriptar la contraseña.
4. En el servidor, descifre la contraseña usando la clave de la sesión y luego destruya la sesión.

El resultado final es que solo la contraseña cifrada se envía por cable y la clave solo se usa una vez y nunca se envía con la contraseña. ¿Problema resuelto?

Answer 1

Su método tiene un defecto: si alguien interceptara la transmisión de la clave al usuario y la respuesta encriptada del usuario podría descifrar la respuesta y obtener el nombre de usuario/contraseña del usuario.

Sin embargo, hay una forma segura de enviar información a través de un medio inseguro, siempre y cuando la información no se pueda modificar en tránsito conocida como Diffie-Hellman algorithm. Básicamente, dos partes pueden calcular la clave compartida utilizada para encriptar los datos en función de sus conversaciones; sin embargo, un observador no tiene suficiente información para deducir la clave.

Sin embargo, configurar la conversación entre el cliente y el servidor puede ser complicado y tomar mucho más tiempo que simplemente aplicar SSL a su sitio. Ni siquiera tiene que pagar, puede generar un certificado autofirmado que proporcione el cifrado necesario. Esto no protegerá contra los ataques de hombre en el medio, pero tampoco lo hará el algoritmo de Diffie-Hellman.

Answer 2

1. generar una clave aleatoria en el servidor (estoy usando PHP).
2. Guarde la clave en una sesión y también envíe la clave en una variable de JavaScript.
3. Al enviar el formulario, use Triple DES en javascript con la clave para encriptar la contraseña.

Esto evita el envío de la contraseña en el claro sobre el alambre, pero requiere que usted envíe la llave en la clara sobre el alambre, lo que permitiría a cualquier persona espiando para descifrar la contraseña.

Se ha dicho antes y lo repetiré: ¡no intente inventar sus propios protocolos criptográficos! Existen protocolos establecidos para este tipo de cosas que han sido creados, revisados ​​por pares, golpeados, pirateados, empujados y pinchados por profesionales, ¡utilícenlos! Ninguna persona podrá llegar a algo mejor que la comunidad de seguridad y criptografía trabajando juntas.

Answer 3

Entonces, ¿cómo es esto más seguro? Aunque podría haber asegurado el navegador <> su servidor, ¿qué ocurre con el resto de Internet (su servidor <> twitter)?

En mi humilde opinión, es inaceptable pedir un nombre de usuario y contraseña de otro servicio y esperar que las personas ingresen eso. Y si te importa tanto, no los integre hasta que no se hayan equivocado y vuelve a habilitar OAuth. (Lo soportaron por un tiempo, pero lo desactivó hace unos meses.)

Mientras tanto, ¿por qué no ofrecer OpenID? Cada cuenta de Google, Yahoo !, VOX etc. tiene una. La gente puede no estar al tanto, pero las posibilidades son realmente altas de que ya tengan OpenID. Check this list para ver lo que quiero decir.

Answer 4

Cuando la clave se envía entre el cliente y el servidor, es texto claro y sujeto a intercepción. Combine eso con el texto encriptado de la contraseña y descifre la contraseña.

Diffie-Hellman es una buena solución. Si solo necesita autenticarlos y no transmitir la contraseña (porque la contraseña ya está almacenada en el servidor), puede usar HTTP Digest Authentication, o alguna variación de la misma.

Answer 5

No necesita tener un certificado en su servidor; depende del cliente si están dispuestos a hablar con un servidor no autenticado. El acuerdo clave aún se puede realizar para establecer un canal privado. Sin embargo, no sería seguro enviar credenciales privadas a un servidor no autenticado, razón por la cual no se ve SSL utilizado de esta manera en la práctica.

Para responder a su pregunta general: simplemente envíela. Creo que su real pregunta general es: “ ¿Cómo envío datos confidenciales a través de un canal inseguro — y lo mantengo seguro? ”No puede.

Parece que ha decidido que la seguridad no vale los $ 10 – 20 por mes que costaría un certificado, y para proteger contraseñas de Twitter, eso es probablemente cierto. Entonces, ¿por qué pasar el tiempo para proporcionar la ilusión de seguridad? Simplemente deje en claro a sus usuarios que su contraseña se enviará sin restricciones y les permitirá tomar su propia decisión.

Answer 6

he implementado un enfoque diferente

1. Servidor: nombre de usuario y contraseña en hash almacenado en la base de datos del servidor
2. : enviar un desafío con el formulario para solicitar la contraseña, almacenarlo en la sesión con una marca de tiempo y la dirección IP del cliente
3. cliente: hash de la contraseña, el desafío concat | nombre de usuario | passwordhash, el hash de nuevo y que lo ponga al servidor
4. servidor: verificar marca de tiempo, IP, haga lo mismo concatenación/hash y compárelo

Esto se aplica a la transmisión de una contraseña. Usarlo para datos significa usar el hash final como la clave de cifrado para el texto plano y generar un vector de inicialización aleatorio transmitido con el texto de cifrado al servidor.

¿Alguna observación sobre esto?

Answer 7

¿Cómo puedo enviar datos confidenciales a través de un canal inseguro

con una clave secreta precompartida. Esto es lo que intenta en su solución sugerida, pero no puede enviar esa clave sobre el canal inseguro. Alguien mencionó DH, lo que te ayudará a negociar una clave. Pero la otra parte de lo que SSL hace es proporcionar autenticación, para evitar ataques de intermediarios para que el cliente sepa que está negociando una clave con la persona con la que intenta comunicarse.

El consejo de Chris Upchurch es realmente la única buena respuesta que hay para el 99,99% de los ingenieros: no lo hagas. Deje que otra persona lo haga y use su solución (como los tipos que escribieron el cliente/servidor SSL).

Creo que la solución ideal aquí sería conseguir que Twitter admita OpenID y luego usar eso.

Answer 8

Un certificado ssl autofirmado no cuesta dinero. Para un servicio gratuito de Twitter, probablemente sea bueno para los usuarios.

Answer 9

A OLI

En su approch por ejemplo, estoy en la misma subred con el mismo router, así que conseguir la misma ip como mis colegas en mi trabajo. Abrí la misma URL en el navegador, por lo que el servidor genera la marca de tiempo con la misma IP, luego uso tcp/ip dump para olfatear la contraseña hash o no hash de la conexión de mis colegas. Puedo oler todo lo que envía. Así que tengo todos los hashes de su formulario, también tiene la marca de tiempo (mi) y la misma ip. Así que envío todo utilizando la herramienta de publicación y hey estoy loggen in.

Answer 10

Si no quieres usar SSL, ¿por qué no pruebas otro protocolo, como kerberos?

Una descripción básica está aquí: http://www.kerberos.org/software/tutorial.html

O si quieres ir un poco más en profundidad, ver http://www.hitmill.com/computers/kerberos.html

Answer 11

Tengo un problema similar (querer para cifrar los datos en formas sin pagar por una certificado ssl) así que hice un poco de búsqueda y encontré este proyecto: http://www.jcryption.org/

No lo he usado todavía pero parece fácil de implementar y pensé en compartirlo aquí en caso de que alguien más esté buscando algo como eso y encuentra ellos mismos en esta página como yo lo hice.

Answer 12

API y OAuth

En primer lugar, como otros han dicho, no debe estar usando la contraseña de un usuario para acceder a la API, que debería estar recibiendo un OAuth token. Esto le permitirá actuar en nombre de ese usuario sin necesidad de su contraseña. Este es un enfoque común utilizado por muchas API.

Key Exchange

Si necesita resolver el problema más general de intercambio de información a través de conexiones inseguras, hay varios protocolos de intercambio de claves como han mencionado en otras respuestas.

En general, los algoritmos de intercambio de claves son seguros para los intrusos, pero como no autentican la identidad de los usuarios, son vulnerables a los ataques de intermediarios.

Desde la página de Wikipedia sobre Diffie Hellman:

En la descripción original, el intercambio Diffie-Hellman por sí sola no proporciona autenticación de las partes que se comunican y por lo tanto vulnerable a un hombre -in- el ataque medio. Una persona en el medio puede establecer dos distintivos intercambios de claves Diffie-Hellman, uno con Alice y el otro con Bob, enmascarando efectivamente a Alicia con Bob, y viceversa, permitiendo al atacante descifrar (y leer o almacenar) luego vuelva a cifrar los mensajes pasados ​​entre ellos. Por lo general, se necesita un método para autenticar a las partes que se comunican entre sí para evitar este tipo de ataque. Las variantes de Diffie-Hellman, como STS, pueden ser utilizadas en su lugar para evitar este tipo de ataques.

Incluso STS es inseguro en algunos casos donde un atacante puede insertar su propia identidad (clave de firma) en lugar del remitente o el receptor.

identidad y autenticación

Este es exactamente el SSL problema está diseñado para resolver, mediante el establecimiento de una jerarquía de autoridades de la firma 'de confianza' que tienen en teoría verificado que posee un nombre de dominio, etc, alguien conectarse a un sitio web puede verificar que efectivamente se están comunicando con el servidor de ese dominio, y no con un hombre en el medio que se ha colocado en el medio.

Puede crear un certificado autofirmado que proporcionará la configuración necesaria para encriptar la conexión, pero no lo protegerá de los ataques intermedios por la misma razón que no lo hará el intercambio de clave Diffie-Hellman no autenticado.

Puede obtener certificados SSL gratuitos válidos durante 1 año desde https://www.startssl.com/ - Los uso para mis sitios personales. No son tan 'confiables' sea lo que sea lo que signifique, ya que solo realizan controles automáticos a las personas que solicitan uno, pero es gratis. También hay servicios que cuestan muy poco (£ 10/año desde 123-Reg en el Reino Unido).

Answer 13

El problema con la seguridad de javascript en el lado del cliente es que el atacante puede modificar el javascript en tránsito hacia un {return input} simple, lo que hace que su elaborado argumento de seguridad resulte innecesario. Solución: utilice el RSA proporcionado por el navegador (es decir, no transmitido). Por lo que sé, aún no está disponible.