¿Por qué los sitios principales (Facebook, Google, etc.) todavía envían contraseñas sin problemas? [duplicar]

5

RESUMEN RÁPIDO:

Parece que los sitios web modernos, por motivos de seguridad, deberían tener al cliente para que los identifique con sus propias contraseñas antes de enviarlas al servidor, que las volverá a usar para evitar que se filtre la contraseña original (probablemente se reutilizará en diferentes sitios). y también para hacer que sea necesario descifrar de forma individual, en lugar de simplemente descifrar una sola clave SSL.

PREGUNTA ORIGINAL:

Simplemente hice una comprobación rápida para asegurarme, y me sorprendió ver que los principales sitios web parecen seguir enviando contraseñas en su formato original para los inicios de sesión, aunque sobre SSL / TLS. Entiendo que están hacinándolos y sazonándolos antes de ponerlos en la base de datos. Sin embargo, todavía veo un problema con eso.

Parece que hash todas las contraseñas con un salt del sitio en el lado del cliente antes de enviarlas, y luego el hash del hash sería sustancialmente más seguro para los clientes, especialmente a la luz de noticias recientes :

  

La NSA y sus aliados rutinariamente interceptan tales conexiones, por millones. Según un documento de la NSA, la agencia tenía la intención de descifrar 10 millones de conexiones https por día a finales de 2012. Los servicios de inteligencia están particularmente interesados en el momento en que un usuario escribe su contraseña . Para finales de 2012, se suponía que el sistema podía "detectar la presencia de al menos 100 aplicaciones de cifrado basadas en contraseñas" en cada caso unas 20,000 veces al mes. (énfasis añadido)

Si bien entiendo que desde una perspectiva de eficiencia, no es necesario que el cliente tenga el hash de la contraseña, estoy más interesado en el hecho de que el hashing de la contraseña original significaría que incluso si los datos fueron interceptados, ya sea en el servidor, antes -hashing, o durante la conexión y luego descifrar el SSL, solo sería útil para iniciar sesión en el sitio web para el que fue interceptado.

Supongo que debería ser una preocupación importante considerando mucha gente que reutiliza contraseñas , sin embargo, estos sitios masivos todavía están enviando el Contraseña original y hash en su final. ¿Hay una razón técnica detrás de esto, o es solo una práctica antigua que idealmente debería cambiarse?

EDITAR PARA ACLARAR: No estoy sugiriendo que estos sitios comiencen a hacer todo el hash en el lado del cliente y simplemente lo coloquen en su base de datos tal como están, definitivamente deberían hash / salt el hash. Mi sugerencia es que el cliente borre la contraseña para que el servidor no tenga idea de cuáles eran los datos originales y, por lo tanto, la misma contraseña se puede reutilizar, y un compromiso en un sitio web no significaría un compromiso con su contraseña en otros sitios. Como una ventaja adicional, también limitaría el acceso descubierto por los proxies maliciosos a los sitios registrados, en lugar de entregarles su contraseña.

    
pregunta Ecksters 04.03.2015 - 14:44
fuente

1 respuesta

3

Tenemos que distinguir entre los siguientes dos escenarios:

1) Un pirata informático determinado intenta obtener las contraseñas

En esta situación, SSL generalmente proporciona suficiente protección, y es bien difícil descifrar SSL bien implementado. Tan pronto como el atacante pudiera iniciar con éxito un ataque ManInTheMiddle, el hash del lado del cliente no obtendría más protección de todos modos, porque el atacante podría eliminar fácilmente el script (JS), que está calculando el hash.

2) Se inicia un ataque automático

Si hubiera una organización capaz de leer tráfico SSL, calcular un hash del lado del cliente aumentaría sus costos, porque en un ataque automatizado solo verían el hash de la contraseña. Sin embargo, tan pronto como su interés por un sitio sea lo suficientemente grande, podrían escribir código para eliminar automáticamente la secuencia de comandos de este sitio.

Si solo tienen el hash, aún podrían tratar de fuerza bruta este hash. Dado que probablemente utilice un lado del cliente hash rápido (SHA *), el forzamiento de la fuerza bruta debería ser relativamente fácil. Usar un hash lento (PBKDF2 o BCrypt) es difícil de implementar, con un lenguaje del lado del cliente lento como JS. Incluso si usted calculara un lado de cliente hash lento, tuvo que reducir el tiempo en el lado del servidor, porque no desea que el usuario espere demasiado. Operar hashing del lado del servidor con el hashing del lado del cliente disminuiría la seguridad, ya que el hashing del lado del servidor se puede hacer más rápido (más rondas) que el hashing del lado del cliente.

➽ Esto significa que podría hacerles la vida más difícil, pero no podría detenerlos si su interés es lo suficientemente grande. Si el usuario es consciente de la seguridad y elige una contraseña muy segura, un hash del lado del cliente podría ayudar, pero este usuario probablemente no reutilizará la contraseña.

    
respondido por el martinstoeckli 04.03.2015 - 15:39
fuente

Lea otras preguntas en las etiquetas