¿Por qué casi ninguna página web contiene contraseñas de hash en el cliente antes de enviarlas (y volver a marcarlas en el servidor), para "proteger" contra la reutilización de contraseñas?

¿Por qué no se usa? Porque es mucho trabajo extra para cero ganancia. 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 reutilización de contraseñas, contraseñas de diccionarios, etc.).

  

En teoría, esto no da ninguna seguridad adicional, pero en la práctica esto   puede usarse para protegerse contra "sitios deshonestos" que no dañan su   Contraseña en el servidor.

¿Cómo te protege esto exactamente? Suena como que todo lo que quieres hacer es hash la contraseña hash, que no tiene sentido. Porque la contraseña con 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"   que las contraseñas están en hash en el servidor, lo que no siempre es cierto.

¿Qué hay de no usar la misma contraseña para más de un sitio? En teoría, la razón por la que los sitios web contienen la contraseña es para evitar el acceso a su cuenta si ELLOS están comprometidos. Usar la misma contraseña para varios sitios web es estúpido.

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

Porque agregaría poco o ningún valor. La razón del hashing 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 pudieron hacerse pasar por ningún usuario. Su sistema no tiene conocimiento de la contraseña.

Secure proviene de certificados SSL más algún tipo 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. Al ponerlo en el cliente, es bastante fácil obtener el código fuente de Javascript, incluso si se trata de archivos de scripts de referencia ocultos.

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 utilizando mi certificado de cliente y el certificado del servidor.

No se intercambian contraseñas, e incluso si alguien piratea la base de datos, solo tendrá la clave pública de mi certificado de cliente (que el servidor debe incluir y cifrar para un mayor nivel de seguridad).

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

La belleza de todo esto es que elimina el concepto de phishing ... nunca ingresará una contraseña en un sitio web, solo tendrá que darle la mano a 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 como esto en Windows con Cardspace y más tarde lo presentó como un estándar abierto. OAuth es algo similar, pero se basa en una "parte emisora" intermediada. Las tarjetas de información, por otro lado, pueden ser auto emitidas. Esa es la verdadera solución al problema de la contraseña ... eliminando todas las contraseñas.

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

la mayoría de las respuestas aquí parecen pasar por alto el punto del hashing de la contraseña del lado del cliente.

el punto es no para 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 simple.

el punto es realmente asegurar la contraseña del usuario , que suele ser mucho más valiosa que el acceso de inicio de sesión al sitio individual, ya que la mayoría de los usuarios reutilizarán su contraseña para varios sitios (no deberían, pero la realidad es que lo hagan no debe ser desestimado).

ssl es ideal para la protección contra 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 de manera malintencionada a un servidor web, es probable que pueda interceptar contraseñas en texto sin formato porque en la mayoría de los casos las contraseñas solo se insertan mediante un script en el servidor. luego el atacante puede probar esas contraseñas en otros sitios (generalmente más valiosos) usando nombres de usuario similares.

la seguridad es una defensa en profundidad, y el hashing del lado del cliente simplemente agrega otra capa. recuerde que mientras que 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 la contraseña en otros sitios.

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

Echa un vistazo a SuperGenPass . Es un bookmarklet.

Simplemente reconoce los campos de contraseñas, concatena lo que escribes con el dominio del sitio web, lo procesa, lo manipula un poco para que solo se ingresen caracteres "admitidos" en la contraseña, y solo entonces se envía por correo electrónico la contraseña con hash.

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 distribuyes perfectamente una implementación basada en sha-2 si lo deseas.

El único inconveniente es si el dominio cambia, en cuyo caso deberá solicitar al sitio web que restablezca su contraseña porque no podrá recuperarla por sí mismo ... aunque no sucede a menudo, por lo que Considérelo como una compensación aceptable.

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

Este es un problema que tengo como usuario: no tengo ni idea de si mi contraseña va a estar oculta en el otro extremo cuando se almacene en la base de datos. Las líneas entre el servidor y yo pueden estar cifradas, pero no tengo idea de lo que pasa con mi contraseña una vez que llega al destino, tal vez se almacene 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 contraseñas. Personas no técnicas porque no conocen nada mejor. Personal técnico porque una vez que llegas a la contraseña número 15, la mayoría de las personas no tienen posibilidad de recordarlas 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 una casilla de contraseña será instantánea del lado del cliente usando un servidor generado por sal y efectivamente la propia contraseña en un espacio aislado, entonces lo sabría como usuario Podría reutilizar una contraseña con menos riesgo. Todavía querría los canales encriptados, así como no quiero que se escuchen escuchas durante la transmisión.

El usuario debe 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 de X4U, no tienen forma de saberlo, porque no se sabe si esa tecnología está en uso.

Creo que es un buen método para usar cuando se construye algo como un framework, 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 han señalado otros, el beneficio aquí NO es que un ataque MITM no pueda permitir que otra persona inicie sesión en este sitio en particular como usted, sino que ese atacante no podría usar el mismo nombre de usuario / combo de contraseña para iniciar sesión en posiblemente docenas de otros sitios en los que podría tener cuentas.

Un esquema de este tipo debe incluir sal aleatoria o 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 utilizarla para el mismo nombre de usuario en otros sitios (incluso los sitios que usan esquema de hashing idéntico), ni contra otros usuarios del sitio que puedan tener la misma contraseña.

Otros han sugerido que los usuarios deberían 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 hasher de contraseña javascript es lo menos que puede hacer un desarrollador de framework / cms 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 tanto el propietario del sitio como los usuarios finales están siendo negligentes con respecto a la seguridad (que probablemente sean)