Muy básico, problema de todos los desarrolladores de la cara: cada vez que el usuario envía el formulario, la contraseña se envía a través de la red y que debe ser protegida. El sitio que desarrollar para no tener HTTPS. Tampoco lo hace el propietario quiere comprar un certificado SSL, ni está interesado en un auto firmado por uno. Así que quiero proteger la contraseña enviada a través de HTTP con Javascript en el formulario.

Ansiosos downvoters: Cómo enviar contraseña de forma segura a través de HTTP? NO dan ninguna solución sensata y estoy en otra situación.

Si puedo usar MD5, uno puede revertir esa cadena de contraseña. ¿Qué acerca de nonce/HMAC? Cualquier disposición de la biblioteca de Javascript para que? O ¿tienes alguna sugerencia/sugerencia a abordar? Gracias de antemano!

InformationsquelleAutor Viet | 2010-01-05

11 Comentarios

  1. 77

    No hay manera de enviar una contraseña de forma segura que el usuario pueda verificar sin SSL.

    Seguro, usted puede escribir código JavaScript que hacer una contraseña segura para la transmisión por cable a través de hash o de clave pública de cifrado. Pero ¿cómo puede estar seguro de que el propio JavaScript no ha sido manipulados por el hombre-en-el-medio antes de llegar a ellos, para enviar la contraseña a un atacante en lugar de el sitio, o incluso poner en peligro la seguridad del algoritmo? La única manera sería para ellos para ser expertos programadores y les han inspeccionar cada línea de su página y de secuencia de comandos para asegurarse de que era kosher antes de escribir la contraseña. Que no es un escenario realista.

    Si quieres contraseñas a salvo de hombre-en-el-medio de ataques, usted debe comprar un certificado SSL. No hay otra manera. Acostumbrarse a él.

    Si puedo usar MD5, uno puede revertir esa cadena de contraseña.

    No… no trivialmente al menos. Mientras MD5 ha ataques en su contra, es un algoritmo de hash y por lo tanto unreversable. Usted tendría por fuerza bruta es.

    Pero, de nuevo, un hombre-en-el-medio atacante no necesita mirar su Md5. Simplemente puede sabotear el JavaScript que enviar al usuario a hacer el Md5.

    • +1 gracias por tu explicación.
    • Excelente post. Traté de hacer una contraseña segura entrada con JavaScript, y se dio cuenta de que no era posible por estas razones exactas. Me gustaría poder tener lea esto primero.
    • <<Mientras que el MD5 ha ataques en su contra, es un algoritmo de hash y por lo tanto unreversable. Usted tendría por fuerza bruta es.>> Te estás olvidando de que no son pre-calculados tablas de MD5 había hash de contraseña, lo que significa que la «fuerza Bruta» que bien podría ser rápido y trivial.
    • EricLaw: Usted se refiere a tablas de arco iris? Contienen solamente los hashes de texto hasta una determinada longitud.
    • De todos modos, antes de elegir una función de hash, todo el mundo debería ver los últimos detalles de la que decida en: valerieaurora.org/hash.html, específicamente, MD5, SHA0, SHA1, se consideran a todos los muertos. Utilice sólo SHA-2.
    • «Si desea que las contraseñas para estar a salvo de hombre-en-el-medio de ataques, usted debe comprar un certificado SSL. No hay otra manera.» Una tontería. Usted acaba de agregar un reto para una segunda ronda de la mezcla. Consulte groups.google.com/group/comp.lang.php/browse_thread/thread/… C.
    • Como Jerry Stuckle dice en el hilo, que todavía no. La adición de más seguridad en la parte superior no hace ninguna diferencia; el usuario tiene que leer y comprobar que la secuencia de comandos de cliente que se les envía era kosher antes de empezar a escribir sus credenciales. Que no va a suceder. Necesitas un secreto de algún tipo de mecanismo de arranque de una conexión segura SSL se establece que, en la forma de reparto de CAs. Sin ella, usted podría estar hablando al azar activo-MitM hacker pretender ser el sitio web de destino. Contraseña hash de inicio de sesión de esquemas, aunque potencialmente útil para otras razones, sólo puede derrotar pasivo MitM.
    • +1 Gracias por la explicación adicional 🙂

  2. 24

    La solución es no enviar la contraseña a todos. El uso de desafío/respuesta.

    En la forma original de incluir un gran bloque de texto al azar junto con una clave. Original de la tienda de texto al azar en la sesión basado en la clave en el servidor. Cuando el cliente envía el formulario, el uso de JS para encriptar el texto al azar y la contraseña juntos. A continuación, enviar el nombre de usuario, clave, y el hash de texto al azar para el servidor. NO enviar la contraseña. En el servidor, utilice la clave de la búsqueda de la original de texto al azar, realizar la misma operación de hash con la contraseña almacenada. Si el servidor-hash valor coincide con el cliente hash valor, entonces usted sabe que el cliente entró en el derecho contraseña sin el envío de la contraseña para el servidor.

    Si la contraseña es correcta o no, vencen la clave y el texto al azar para cada uno son de un solo uso.

    • +1 Hola Sam, gracias. El concepto que usted describe es mencionado por «nonce» en mi pregunta. No estoy seguro de cómo probar su fiabilidad & seguridad todavía.
    • Usted todavía tendrá que enviar la contraseña al menos una vez en el servidor para almacenar en la base de datos. ¿Qué vas a hacer en ese caso?
    • sí, si usted está manejando su propia contraseña, a continuación, el uso que usted necesita para pasar al ajuste de la contraseña. Nos autenticar contra LDAP así que en realidad no tenemos el original de la contraseña almacenada. Buen punto, aunque.
    • Lo que me gustaría hacer es que el servidor de crear la contraseña y el correo electrónico al propietario
    • cuando usted necesita para proporcionar de restablecimiento de contraseña a través de e-mail, es mejor enviar una sola vez el enlace que restablece la contraseña y no enviar la contraseña real en sí. Esto evita los problemas de seguridad de la contraseña se transmite a través de e-mail y se la almacena en correo electrónico más tarde.
    • Y si yo soy el «hombre en el medio» me subiría a que un hash de la cadena, y la utilizan para autenticar, por lo que no importa lo que usted hizo en el navegador. Y haciendo el mismo hash en el cliente como en el servidor, se ha mostrado cómo la autenticación del lado del server, lo algoritmo que estás usando, ¿cuántos pases etc.
    • Esto no es suficiente para proteger contra un MITM que podrían modificar el código JS devuelto por el servidor para capturar el campo de la contraseña de contenido (o a través de un ataque de cross site que podría registrar un oyente en la entrada de contraseña). Para protegerse contra esto usted necesita Subresource integridad de hacer valer sus javascript y CSP.
    • sí, muy buenos puntos. Esta pregunta y la respuesta de los 8 años y hoy en día yo no recomendaría a nadie ejecuta un sitio sin https como ahora es mucho más común y más barato de lo que lo era hace 8 años.

  3. 11

    Si quieres REALMENTE profundo en esto, mira la Diffie-Hellman de intercambio de claves que fue creado para «permitir que las dos partes que no tienen ningún conocimiento previo de la otra, para establecer conjuntamente una clave secreta compartida a través de un canal de comunicaciones inseguro»

    Yo no soy un experto en criptografía, así que no estoy completamente de saber si es realmente seguro si un atacante tiene tanto en el Cliente (JavaScript de código fuente) y el mecanismo de transporte (Packet sniffer)

    • Es seguro si lo haces bien… pero hacerlo bien es extremadamente difícil. SSL es mucho menos trabajo.
  4. 4

    Por desgracia, no habrá manera de garantizar la seguridad de no encriptada de solicitud. Cualquier persona con acceso a tu código javascript simplemente ser capaz de aplicar ingeniería inversa/manipular con él y cualquier persona con un sniffer de paquetes será capaz de ver el tráfico sin cifrar. Estos dos hechos juntos significa:

    No SSL? No hay seguridad.

    • También me gustaría argumentar que SSL es tan malo como no hay seguridad de que usted puede comprar un certificado firmado de CA para un dominio que no es suya. Aunque cada vez es más raro, pero estoy seguro de que puede encontrar una CA en la que va a tomar mi dinero y firmar el certificado. Con que – ¿cómo sabes que el chase.com es realmente chase sitio y no a los atacantes? Ambas pueden tener validez los certificados con firma.
    • Los grandes no lo hacen esto y muchos de los otros son poco compatibles en los navegadores. La situación no es perfecto, pero yo no la llamo «tan malo» como no hay seguridad.
    • Lo que está mal. SSL es sólo un protocolo, no hay ninguna seguridad SSL de por sí. La seguridad viene de Diffie Helman/Clave de la derivación y la puede implementar en Javascript. Usted necesita por lo menos 3 paso (2 intercambios) entre el cliente y el servidor para asegurarse de que el código Javascript es correcto (como SSL). Todo está marcada lado del servidor.
  5. 1

    Cualquier transmisión que usted tiene que estar en el claro; que es, sin SSL y su crítica de la información será expuesta. Vale la pena discutir ese punto con el Propietario del sitio. En otras palabras, es mejor tomar las medidas necesarias para fortalecer la transmisión de datos, y SSL es una de las básicas, los hoteles de pasos que usted puede tomar.

  6. 1

    no creo que el problema aquí es la tecnología, sino cómo explicar la importancia de SSL. Provea de ellos con fiable de materiales de lectura, estoy seguro de que hay mucho en la web.

  7. 1

    La solución requiere que el cliente sea capaz de cifrar la contraseña utilizando un secreto de la clave de cifrado conocido sólo para el cliente y el servidor.

    SSL logra esto por que requiere el servidor y el cliente navegador web para tener su propio asimétrica público/privado par de claves, el cual utilizan para codificar y transmitir una clave de sesión aleatoria entre ellos. El resto de la conversación, a continuación, utiliza esa seguro de la clave de sesión.

    Entonces usted se está preguntando cómo resolver el mismo problema como SSL sin el beneficio de tener una clave secreta que se conoce sólo para el cliente y el servidor. No soy un experto, pero parece que esto no se puede hacer, o al menos no fácilmente.

    • No. Sólo uno sólo necesita un certificado. El cliente no generar la clave de sesión; no cifrar; y no enviarlo. Es negociado a través de una clave de un protocolo de acuerdo.
    • Sí, el servidor crea y cifra la clave de sesión. Pero, ¿cuál es la clave de protocolo de acuerdo se realiza sin que el cliente tenga su propio (asimétrica) de la clave de cifrado?
    • El principio es que: el servidor envía su identidad y un pseudo-aleatorios valor (premaster clave) que se deriva de un secreto que él sabe. Una vez que el cliente validar la identidad del servidor (en el certificado), es generar un par de claves al azar. Con la parte privada, utiliza el premasterkey y la transforman y enviarlo de vuelta. Luego de que ambos se derivan de una clave secreta comunes, sin que ninguno de ellos revelan su clave privada, por lo tanto un MITM no pudo encontrar la clave de sesión.
    • Derecho, por lo tanto el servidor como el cliente tienen su propio público/privado de los pares de claves, el cual utilizan para derivar una clave de sesión conocido sólo a ellos. OP estaba preguntando cómo hacer esto sin pares de claves, que en la medida que puedo decir, no se puede hacer de forma segura.
    • Lo importante es que el cliente generar un nuevo par de claves para cada sesión (de modo que el cliente no necesita de antemano). El servidor, sin embargo, es siempre utilizando el mismo par de claves. SSL sólo añade una cadena de firma para asegurarse de que el servidor es la de la derecha la de algunos conocidos «de oro» de las raíces.
    • Así que, para responder a la pregunta, sin la cadena de confianza, una solución es usar SSH como sistema, es decir, una vez que el cliente ha validado el servidor, se almacena en un permanente caché (por ejemplo localStorage) la clave pública del servidor y la dirección IP (por ejemplo). Más allá de la conexión, cualquier discrepancia debe detener el cliente de procesamiento adicional.

  8. 1

    Si usted no tiene acceso a SSL, MD5 debe ser adecuado para evitar el descubrimiento accidental de contraseñas (como en un archivo de registro de red o algo). Cualquier otra cosa sería una pérdida de tiempo. Sólo asegúrese de que la aplicación no dar acceso a la información sensible (es decir, números de tarjetas de crédito, historial médico, etc).

    Al igual que otros comentaristas han sugerido, un grave atacante será capaz de romper cualquier tipo de seguridad en la página. Incluso SSL es una pequeña barrera ya que la mayoría de los usuarios de usar fácil de adivinar contraseñas, volver a usar la misma contraseña en todas partes, va a dar su contraseña a nadie que le pide, o puede ser engañado en dar su contraseña a través de una página copiada o «soporte técnico» de la llamada de teléfono.

  9. 0

    — Inglés —
    creo en algo, pero no sé si podría estar realmente seguro. Si se puede poner el formulario en un archivo php, entonces usted puede crear un algoritm para crear una cadena basada en el tiempo o en algo más, y luego poner esta cadena en el código html.

    Cuando el usuario escriba una contraseña en un campo de entrada de contraseña, al depurar lo que podremos ver el valor escrito por el usuario, así que antes de enviar la información a través de post o get, puede utilizar la contraseña de usuario como una sugerencia para cifrar la cadena cifrada previosly generado, y entonces, solo envió en lugar de la contraseña ingresada por el usuario.

    De esta forma, los atacantes no tienen en su interior el código js, por lo que será necesario descubrir el algoritm que cree descifrar.

    Esto es sólo una idea, así que si usted me puede decir cómo se puede no ser seguro, te lo agradecería.

    — Español —
    Se me acaba de ocurrir algo que puede servir, pero no se si realmente el mar algo seguro. Por medio de php puedes generar un algoritmo que cree de la onu cadena en base al de marca de hora o algo más, y después colocar esta cadena en el html.

    Nota que cuando alguien escribe una contraseña en un campo de entrada de tipo contraseña, con un debug no se puede ver el valor que tecleo el usuario (no se si exista manera pero no quise investigar mas), asi que podemos utilizar la contraseña que el usuario escribió como palabra clave para encriptar la cadena de texto que previamente habiamos generado con php, por medio de un algoritmo en JS. Sería algo así como encriptar lo encriptado. Posteriormente lo que estariamos enviado no sería la contraseña tecleada, si no esta última cadena resultante.

    Buscando la onu contra, lo único que se me ocurra es que el atacante tendrá que dedicarle mucho tiempo para citrato de encontrar el agoritmo que creamos por medio de php y poder decriptar la cadena final, o tendrá que hackear el servidor para acceder al php y obtener el algoritmo.

    Esto es solo una idea, por lo que si pueden decirme como esto puede no ser seguro, se los agradecería.

  10. 0

    Como se ha mencionado, nada de esto es seguro contra servidor de suplantación de identidad, ya que requiere una capacidad de confiar en el lado del cliente con Javascript. Pero si estamos seguros de que el servidor no puede ser suplantada (firmado cert, el hash de la firma inmune a la longitud de extensión, etc.) pero no que la conexión es inmune a los espías, he aquí cómo me gustaría implementarlo.

    Creo que la manera más segura es, en lugar de almacenar H(contraseña), donde H es la función hash de la elección, la tienda de g^H(contraseña), es decir, el uso de la contraseña de la clave privada de Diffie-Hellman de intercambio de claves. (Usted debe también, probablemente, el uso de un aleatoria g para diferentes usuarios, demasiado, se convierte en su sal). A continuación, para comprobar, de generar un nonce b, enviar al usuario g^b, y calcule (g^H(contraseña))^b. El usuario no necesita saber g–solo tienen que calcular (g^b)^H(contraseña) = (g^H(contraseña))^b. Ahora usted tiene un número que ambas partes saben iff el usuario haya introducido la contraseña correcta, y la construcción de un desafío-respuesta cero-prueba de conocimiento basados en el conocimiento de que el número correcto es trivial, mientras que el número aleatorio que se utiliza como servidor de la «clave privada», hace que el enfoque sea inmune a los ataques de reproducción.

    • Lo que el cliente puede hacer un MITM puede hacer así. Usted habla de un «firmado cert», ¿cuál es la diferencia de tener instalado un certificado SSL? Y ¿a qué te refieres con «el servidor no puede ser falsificado», significa que la comunicación no puede ser alterado, sólo escuchaba?
    • Lo que me refería era a que, básicamente, esta solución es inútil a menos que la identidad del servidor ya está validado para el cliente, lo que generalmente implica certificados SSL y de extremo a extremo de cifrado en el mundo de hoy. Sí, me refería a una situación en la que el espionaje es posible, pero hacerse pasar por el servidor o la alteración de su salida undetectably no es, por ejemplo, la clave pública del servidor es conocido (validados por fuentes de confianza) y los signos de todos sus mensajes con un SHA3 hash cifrado con su clave privada.
    • Estoy entendiendo que es el derecho que significa que a medida que el contenido es entregado de forma segura este mecanismo sería algo seguro para un no-ssl capa de api? No es que yo estoy defendiendo, solo por curiosidad. Estoy realmente quieren implementar algo en nuestro interior la pila como este. Tenemos un único servidor de autenticación que queremos que todas nuestras aplicaciones para compartir. Nuestras aplicaciones no necesitan saber acerca de la contraseña, así que este reto concepto de respuesta podría responder a esa necesidad, a pesar de que todavía iba a servir todo SSL.
    • Para el registro, me refiero a que el de un servidor malicioso sólo podría servir deliberadamente insegura Javascript que transmite el mensaje en texto sin formato.

Dejar respuesta

Please enter your comment!
Please enter your name here