¿Por qué casi no hay contraseñas hash de páginas web en el cliente antes de enviarlas (y volverlas a cifrar en el servidor), para "proteger" contra la reutilización de contraseñas?

46

Hay muchos sitios en Internet que requieren información de inicio de sesión, y la única forma de protegerse contra la reutilización de contraseñas es la "promesa" de que las contraseñas se cifran en el servidor, lo que no siempre es cierto.

Entonces, me pregunto, ¿qué tan difícil es crear una página web que muestre las contraseñas en la computadora del cliente (con Javascript), antes de enviarlas al servidor, donde se volverán a codificar? En teoría, esto no brinda ninguna seguridad adicional, pero en la práctica esto puede usarse para proteger contra "sitios corruptos" que no introducen su contraseña en el servidor.

— Martín Fixman
fuente

18

una contraseña hash enviada en clear no es mejor que una contraseña enviada en clear si el servidor solo compara hashes, el hombre en el medio ataca este tipo de "seguridad"

3

La mejor solución es (imo) un administrador de contraseñas del lado del cliente. De esa manera, puede generar una cadena aleatoria de caracteres como contraseña y no dependerá del servidor para 'protegerlo'.

— Dean Harding

2

@Jarrod: sin embargo, me parece que diferentes sitios web que utilizan diferentes algoritmos de hash del lado del cliente evitarían el ataque descrito por ese cómic. Una contraseña ampliamente reutilizada se convierte en muchas contraseñas diferentes a través de los diferentes algoritmos hash. Ese cálculo de hash del lado del cliente no impide que se apliquen otros tipos de seguridad, como enviar el hash a través de una conexión segura.

— Steve314

2

@ Steve314 mi punto es que cualquier cosa en el cliente está comprometida por defecto. Puede hacer hash y hash y hash, si se hace en el cliente y se pasa de un lado a otro en el servidor clear, es solo una masturbación matemática en ese momento. Tuve que arreglar un sistema que heredé, que fue diseñado exactamente de la manera en que usted y el OP lo describen, constantemente fue pirateado por adolescentes con Wireshark. Solo lo bloqueamos cuando lo REALciframos y ciframos y firmamos todas las cargas útiles desde y hacia el servidor, la manipulación de la cuenta se detuvo y nunca más volvió a ocurrir.

55

Parece que su plan para protegerse contra los sitios corruptos es pedirles a los sitios corruptos que configuren una mejor seguridad. ?

— pc1oad1etter

46

¿Por qué no se usa? Porque es mucho trabajo extra para ganancia cero. Tal sistema no sería más seguro. Incluso podría ser menos seguro porque da la falsa impresión de ser más seguro, lo que lleva a los usuarios a adoptar prácticas menos seguras (como la reutilización de contraseñas, contraseñas de diccionario, etc.).

— Rein Henrichs
fuente

2

Esta es la mejor respuesta hasta ahora.

1

Es como el cifrado de Blu-Ray y DVD. Ni siquiera requiere una llave para desbloquear. La única "protección" que proporcionó fue que cuando salieron los DVD por primera vez, cuesta más comprar un disco para copiarlo que comprar una copia completa de la película. Por supuesto, ahora puede comprar un DVD por un dólar y aún más es el hecho de que las claves son de conocimiento público ahora. Lo mismo está sucediendo con Blu-Ray

— Michael Brown

2

Creo que el hashing de una contraseña del lado del cliente agrega seguridad. Si estoy escuchando, solo puedo ver tu hash, no tu contraseña. Si el servidor envía un desafío (como debería), el hash ni siquiera es reutilizable.

— Andomar

2

Creo que el enfoque de x4u puede ser apropiado para algunas aplicaciones donde los requisitos de seguridad se encuentran en algún lugar entre la transmisión de contraseñas en el cable y el uso de certificados. Creo que algunos de los que dicen no están pasando por alto que el hashing de la contraseña antes de que se conecte se realiza además del manejo estándar de credenciales del lado del servidor. Entonces la pregunta es esta: ¿la propuesta de x4u mejora la seguridad en el escenario de transmisión de contraseña en el cable o no? Yo digo que sí. La clave para darse cuenta de esto radica en el uso de sales por contraseña.

— LOAS

66

La forma correcta de prevenir ataques MITM es el cifrado de extremo a extremo. TLS (https) existe: utilízalo. No inventes tus propios esquemas criptográficos.

— Rein Henrichs

14

En teoría, esto no brinda ninguna seguridad adicional, pero en la práctica esto puede usarse para proteger contra "sitios corruptos" que no introducen su contraseña en el servidor.

¿Cómo te protege esto exactamente? Parece que todo lo que quieres hacer es descifrar la contraseña cifrada que no tiene sentido. Porque la contraseña hash se convertiría en la contraseña.

Hay muchos sitios en Internet que requieren información de inicio de sesión, y la única forma de protegerse contra la reutilización de contraseñas es la "promesa" de que las contraseñas se cifran en el servidor, lo que no siempre es cierto.

¿Qué tal no usar la misma contraseña para más de un sitio? La razón por la cual los sitios web tienen la contraseña en teoría es para evitar el acceso a su cuenta si se ven comprometidos. Usar la misma contraseña para múltiples sitios web es simplemente estúpido.

Si usó javascript, todo lo que el "hacker" tendría que hacer es usar el mismo método en las contraseñas hash-hashed. Una vez que tenga la información de hash, es justo el tiempo que toma calcular la contraseña-> mismo hash en la base de datos, lo cual es un factor que impide el acceso a una cuenta.

— Ramhound
fuente

1

Si su navegador siempre lo utiliza de la misma manera, entonces sí, su hash puede usarse como contraseña en cualquier otro lugar. Pero, ¿qué pasa si los navegadores asignan una sal basada en el sitio (¿tal vez el dominio?) Antes de hacer hash y enviarlo al sitio? Creo que es una idea interesante.

— Tesserex

2

si está en el cliente está comprometido, cualquier sal en el cliente está a la vista, esta es una pregunta ilógica. Si no comprende la respuesta de @ Ramhound, no debería escribir código que deba ser seguro, y comenzar a leer sobre seguridad y criptografía desde el principio.

3

Cuando cita el póster original, formatee el texto como tal (seleccione el texto y use el ícono de la cita justo arriba del editor)

— Marjan Venema

1

Jarrod, sigue tus propios consejos e infórmate un poco antes de hacer afirmaciones ridículas. Un hombre en el medio del ataque es inútil contra funciones hash seguras con una longitud de sal razonable. Y mi sugerencia no es de ninguna manera 'seguridad por oscuridad', en realidad es segura según lo que actualmente conocen y aceptan los expertos en este campo y se usa de la misma manera en muchos protocolos. No es mi invención, acabo de aplicar un procedimiento bien entendido a un inicio de sesión en el sitio web. Sus suposiciones falsas no obtienen ninguna sustancia por el hecho de que obviamente también son compartidas por muchos otros.

— x4u

3

Si el cliente conoce la sal y se envía de forma transparente desde un servidor, cualquier cosa en el medio también lo sabe. Nunca dije, necesitaba deshacer el hash, si conoces la sal del cliente, entonces no es seguro.

11

Porque agregaría poco o ningún valor. La razón del hash es que si su base de datos es hackeada, el hacker no tendría una lista de contraseñas válidas, solo hashes. Por lo tanto, no podían hacerse pasar por ningún usuario. Su sistema no tiene conocimiento de la contraseña.

Secure proviene de certificados SSL más alguna forma de autenticación. Quiero que mis usuarios proporcionen una contraseña para poder calcular el hash a partir de ella.

Además, el algoritmo de hash estaría en el servidor en un área más segura. Poniéndolo en el cliente, es bastante fácil obtener el código fuente de Javascript, incluso si se trata de archivos de scripts referenciados ocultos.

— Jon Raynor
fuente

3

Esta es la mejor respuesta. Debe encriptar en la capa de transporte. Sin hacer eso, el resto no es seguro. Sí, podría escribir una función de cifrado ... pero esa función sería visible para los usuarios finales (maliciosos). Utiliza SSL.

— pc1oad1etter

La seguridad de un algoritmo de hash no debería depender de si es secreto. Los algoritmos de hash para la seguridad deben ser funciones unidireccionales: incluso si tiene el código, es difícil deshacerlo. Por el contrario, debe usar una conocida biblioteca de hash diseñada solo para contraseñas. Si no se conoce bien, es casi seguro que tiene errores o está mal propuesto.

— leewz

6

La solución es más simple que eso. Certificados de clientes. Creo un certificado de cliente en mi máquina. Cuando me registro en un sitio web, hacemos un apretón de manos con mi certificado de cliente y el certificado del servidor.

No se intercambian contraseñas e incluso si alguien piratea la base de datos, todo lo que tendrá es la clave pública de mi certificado de cliente (que debe ser salado y encriptado por el servidor para un mayor nivel de seguridad).

El certificado del cliente puede almacenarse en una tarjeta inteligente (y cargarse en una bóveda segura en línea con una contraseña maestra).

La belleza de todo es que elimina el concepto de phishing ... nunca ingresas una contraseña en un sitio web, solo estás dando un apretón de manos con ese sitio web. Todo lo que obtienen es su clave pública, que es inútil sin una clave privada. La única susceptibilidad es encontrar una colisión durante un apretón de manos y eso solo funcionaría una vez en un solo sitio web.

Microsoft intentó proporcionar algo así en Windows con Cardspace y luego lo envió como un estándar abierto. OAuth es algo similar, pero depende de una "parte emisora" intermediada. InfoCards por otro lado podría ser auto emitido. Esa es la solución real al problema de la contraseña ... eliminar las contraseñas por completo.

Sin embargo, OAuth es un paso en la dirección correcta.

— Michael Brown
fuente

55

Si bien los certificados de cliente son un enfoque razonable para algunos casos de uso, no son algo que se pueda agregar fácilmente al inicio de sesión de un sitio web. Requieren una gran cooperación de los usuarios y dependen de cuán segura sea la clave privada de los usuarios. El uso de una clave privada puede ser seguro o conveniente, pero no ambos al mismo tiempo.

— x4u

5

la mayoría de las respuestas aquí parecen perder por completo el punto del hash de contraseña del lado del cliente.

el punto no es asegurar el acceso al servidor en el que está iniciando sesión, ya que interceptar un hash no es más seguro que interceptar una contraseña de texto sin formato.

El punto es realmente asegurar la contraseña del usuario , que generalmente es mucho más valiosa que el acceso de inicio de sesión individual del sitio, ya que la mayoría de los usuarios reutilizarán su contraseña para múltiples sitios (no deberían hacerlo, pero la realidad es que lo hacen, por lo que no se debe descartar) )

SSL es ideal para protegerse contra los ataques MITM, pero si una aplicación de inicio de sesión se ve comprometida en el servidor, SSL no protegerá a sus usuarios. Si alguien ha obtenido acceso malicioso a un servidor web, es probable que pueda interceptar las contraseñas en texto sin formato porque, en la mayoría de los casos, las contraseñas solo se cifran mediante un script en el servidor. entonces el atacante puede probar esas contraseñas en otros sitios (generalmente más valiosos) usando nombres de usuario similares.

la seguridad es defensa en profundidad, y el hash del lado del cliente simplemente agrega otra capa. recuerde que si bien proteger el acceso a su propio sitio es importante, proteger el secreto de las contraseñas de sus usuarios es mucho más importante debido a la reutilización de contraseñas en otros sitios.

— crujiente
fuente

2

La respuesta aceptada comparte su punto bastante bien. Aunque "la mayoría de las respuestas" no lo hacen y debido a que su respuesta realmente no agrega mucho valor, no tiene sentido resucitar esta pregunta.

— Frank

probablemente sea más un comentario que una respuesta (disculpas por no descubrir cómo agregar al hilo de comentarios de respuesta aceptado), y aunque mi punto se comparte en la respuesta aceptada, aparentemente no fue lo suficientemente claro ya que las respuestas parecen para cepillarlo todavía. gracias por los comentarios

— crutchy

@Frank la respuesta aceptada limita con ser demasiado largo para molestarse en leer. entra en demasiados detalles de cómo se puede implementar esto y se desvanece sobre los beneficios hacia el final. Tener un TL; DR en una respuesta diferente es beneficioso.

— Julio

2

@Jules: Por eso existe la edición.

— Robert Harvey

1

@JarrodRoberson Creo que no estás confundiendo más seguro con inseguro ? Si sucede MITM, el acceso al sitio ya está abandonado, ¿no? A menos que use un certificado de cliente en lugar de una contraseña, lo que sería demasiado complejo para los usuarios comunes. A mi modo de ver, el hash del lado del cliente evita que la misma contraseña se vea comprometida en otros sitios, suponiendo que cada algoritmo de hashing sea único. Puede que no sea más seguro, pero tampoco es menos seguro de ninguna manera. Entonces, ¿por qué presionas tanto en esto? Encontré esto desde meta, y esta es la mejor respuesta que veo hasta ahora.

— zypA13510

1

Definitivamente es posible, y en realidad no es necesario esperar un sitio web.

Echa un vistazo a SuperGenPass . Es un bookmarklet.

Simplemente reconoce los campos de las contraseñas, concatena lo que escribe con el dominio del sitio web, lo mezcla, lo manipula un poco para obtener solo caracteres "admitidos" en la contraseña, y solo entonces su contraseña cifrada se envía por cable.

Al utilizar el dominio del sitio en el proceso, obtendrá una contraseña única por sitio, incluso si siempre reutiliza la misma contraseña.

No es extremadamente seguro (base64-MD5), pero distribuye perfectamente una implementación basada en sha-2 si lo desea.

El único inconveniente es si el dominio cambia, en cuyo caso tendrá que pedirle al sitio web que restablezca su contraseña porque no podrá recuperarla usted mismo ... Sin embargo, esto no sucede a menudo, así que lo considero un compensación aceptable.

— Matthieu M.
fuente

Esto es lo que estaba pensando cuando leí la pregunta; Es prácticamente inútil que los sitios hagan su propio hash del lado del cliente, pero una extensión del navegador que lo haga (usando algo de sal basado en el dominio) anularía efectivamente los riesgos asociados con la reutilización de contraseñas. Por supuesto, la parte divertida viene cuando intentas iniciar sesión desde otra máquina ...

— Aaronaught

3

Esto ya no es más seguro que cualquier otro esquema que pasa la contraseña en claro. Hace que la contraseña sea única, pero aún no está encriptada , pero si tengo un servidor en el medio, puedo tomar la contraseña complicada pero clara y usarla todo lo que quiera, no está cambiando. Un hash no es una bala mágica, ni siquiera es cifrado, se llaman hashes criptográficos, pero eso no significa que sean cifrados. No importa si mi contraseña es passwordo un SHA-256 passwordcon algo de sal que el cliente conoce, un hombre en el medio adjunto puede capturarla.

@Jarrod Roberson: puede usar la contraseña, por supuesto, pero no puede reutilizarla para otra de mis cuentas, que es el punto. Por lo tanto, si uno de los sitios web en los que me conecto obtuvo su base de contraseñas robada, y las almacenaron en claro, entonces mis otras cuentas están a salvo.

— Matthieu M.

@Aaronaught: ahí es donde realmente brilla. Dado que la contraseña enviada se deriva únicamente del dominio del sitio web en el que inicia sesión y una contraseña maestra de su elección, puede iniciar sesión desde cualquier computadora (y navegador) siempre que tenga el marcador. Por eso es algo más cómodo que un certificado.

— Matthieu M.

66

@Jarrod: Esta no es una medida de seguridad para el sitio , es una medida de seguridad para el usuario . Si todos usaran un esquema como este, la reutilización de la contraseña no sería un problema. Un esquema MITM podría usar la contraseña cifrada por el cliente para obtener acceso a ese sitio, pero solo a ese sitio. Ahí es donde radica la mejora. Por lo general, esperaría poder acceder a muchas cuentas simplemente descifrando una contraseña, porque es probable que esa contraseña se reutilice; en este caso, prácticamente se garantiza que la contraseña descifrada solo sea válida para el sitio o la base de datos en la que se encontró.

— Aaronaught

0

Me gusta la respuesta de X4u, pero en mi opinión, algo así debería integrarse en el navegador / la especificación html, ya que en este momento es solo la mitad de la respuesta.

Aquí hay un problema que tengo como usuario: no tengo idea de si mi contraseña se va a cambiar en el otro extremo cuando se almacene en la base de datos. Las líneas entre mí y el servidor pueden estar encriptadas, pero no tengo idea de lo que le sucede a mi contraseña una vez que llega al destino; tal vez se almacena como texto sin formato. El administrador de la base de datos puede terminar vendiendo la base de datos y, antes de que se dé cuenta, todo el mundo conoce su contraseña.

La mayoría de los usuarios reutilizan las contraseñas. Gente no técnica porque no conocen mejor. Personal técnico porque una vez que se llega a la 15ª contraseña, la mayoría de las personas no tienen la posibilidad de recordarla a menos que las escriban (lo que todos sabemos también es una mala idea).

Si Chrome o IE o lo que sea que esté usando podría decirme que un cuadro de contraseña se convertirá instantáneamente en el lado del cliente utilizando una sal generada por el servidor y de manera efectiva la contraseña en sí, entonces sabría que como usuario podría reutilizar Una contraseña con menos riesgo. Todavía quiero los canales encriptados, así como no quiero que caiga ningún alero durante la transmisión.

El usuario necesita saber que su contraseña ni siquiera está disponible para ser enviada al servidor, solo el hash. En la actualidad, incluso utilizando la solución X4U, no tienen forma de saber que este es el caso porque no se sabe si esa tecnología está en uso.

— Chris Nevill
fuente

1

está integrado en la autenticación de resumen de búsqueda del navegador y verá los pasos de ida y vuelta tomados en http para obtener un hash de contraseña, con información adicional y verificado en el servidor.

— gbjbaanb

-1

Creo que es un buen método para usar al construir algo como un marco, CMS, software de foro, etc., donde no controlas los servidores en los que podría estar instalado. Es decir, SÍ, siempre debe recomendar el uso de SSL para los inicios de sesión y la actividad de inicio de sesión, pero algunos sitios que usan su framework / cms no lo tendrán, por lo que aún podrían beneficiarse de esto.

Como otros han señalado, el beneficio aquí NO es que un ataque MITM no podría permitir que otra persona inicie sesión en este sitio en particular como usted, sino que ese atacante no podría usar el mismo combo de nombre de usuario / contraseña para inicie sesión posiblemente en docenas de otros sitios en los que pueda tener cuentas.

Tal esquema debería funcionar con una sal aleatoria o con una combinación de sales específicas del sitio y específicas del nombre de usuario, de modo que alguien que obtenga la contraseña no pueda usarla para el mismo nombre de usuario en otros sitios (incluso sitios que usan el mismo esquema de hashing) ), ni contra otros usuarios del sitio que puedan tener la misma contraseña.

Otros han sugerido que los usuarios deben crear contraseñas únicas para cada sitio que usan, o usar administradores de contraseñas. Si bien este es un buen consejo en teoría, todos sabemos que es una locura confiar en el mundo real. El porcentaje de usuarios que hacen cualquiera de estas cosas es pequeño y dudo que eso cambie pronto.

Por lo tanto, un hash de contraseña de JavaScript es lo menos que un desarrollador de framework / cms puede hacer para limitar el daño de alguien que intercepta contraseñas en tránsito (lo cual es fácil en las redes wifi en estos días) si el propietario del sitio y los usuarios finales son negligentes sobre seguridad (que probablemente lo sean).

— matthewv789
fuente