¿Cuál es el punto de las contraseñas de hash?

Sí. Para obtener más análisis, consulte esta publicación de blog : almacenamos contraseñas con hash porque < em> parcial , se producen violaciones de solo lectura (aunque solo sea a través de una cinta de copia de seguridad extraviada) y no queremos que los atacantes puedan escalar inmediatamente esta violación a un acceso completo de lectura-escritura.

Además, las contraseñas son datos privados (por lo que muchos hombres usan el nombre de su novia como contraseña y es posible que su esposa no esté satisfecha), por lo que deberían estar protegidos contra la divulgación accidental a los ojos de los administradores de sistemas (o sus internos). ). Al menos, mirar una base de datos de contraseñas con hash es seguro.

  

¿Es la única razón por la que el hash protege las cuentas de los usuarios en otros sitios en caso de un compromiso?

No, esa no es la única razón. También es para proteger a la cuenta en su propio sitio de que alguien que no debería tener acceso acceda a ella.

Digamos que su sitio era vulnerable a un ataque de inyección de SQL, donde podría obtener el campo de contraseña de la base de datos para un usuario arbitrario. ¿No preferirías que ese campo de contraseña sea un hash de una sola vía? Tal vez puedan ejecutar un ataque de diccionario que consume mucho tiempo contra el hash, pero suponiendo que su clave sea reforzada (por ejemplo, bcrypt) no deberían poder romperla a menos que sea una de las contraseñas más débiles / más comunes.

O digamos que se dispara un administrador de sistemas. ¿Desea que haya tenido acceso a todos los millones de nombres de usuario / contraseñas? Claro, mientras estaban empleados podrían haber tenido acceso para ver la información de cualquier usuario desde su cuenta de administrador, pero ahora que ya no están empleados, ya no deberían tener ningún acceso. Con las contraseñas de texto simple, es posible que hayan memorizado o robado algunas contraseñas que pueden usar en una fecha posterior para ingresar en cuentas aleatorias. (Además, es posible que se requiera que su sistema mantenga un registro de auditoría de quién accede a qué información cuando; por lo tanto, hay una gran diferencia entre un administrador que busca la información de la cuenta de un usuario y alguien que inicia sesión desde fuera del sistema que mira su propia información con su contraseña propia). Por supuesto, un administrador del sistema podría almacenar los parámetros de la POST desde la página de inicio de sesión en los registros del servidor web y obtener las contraseñas de texto simple si quisieran , pero sería sospechoso y probablemente se les pueda rastrear.

O tal vez alguien haya encontrado una de sus antiguas copias de seguridad de la base de datos. ¿Quieres que tengan fácil acceso a todas las contraseñas?

La línea de base es (a) que debe hashear las contraseñas de seguridad en su propio sitio de manera segura (por ejemplo, bcrypt), y (b) nunca debe reutilizar la misma contraseña en diferentes sitios (ya que nunca puede estar seguro de que están tomando las precauciones adecuadas con él).

Hashing the password lo protege en caso de que su infraestructura no sea tan segura como cree.

A pesar de sus mejores esfuerzos, será hackeado en algún momento de su carrera de TI. Su estrategia luego pasa de la prevención (que no funcionó en al menos este caso) al control de daños y la recuperación de desastres. Parte de eso es garantizar que incluso si un atacante se apoderó de datos confidenciales al descargar la base de datos, no podría usarlo para su mayor ventaja (al menos no antes de que pueda hacer suficientes cambios en el sistema para hacer que esos datos sean inútiles).

Introduce la contraseña hash. El hash está diseñado para producir un valor único para un mensaje único que aún se puede comparar por igualdad, pero que no tiene una relación matemática o referencial aparente con el mensaje original (y, por lo tanto, no puede ser "revertido" de manera eficiente cuando se le da solo el valor hash ). Entonces, tu atacante encuentra una grieta en la armadura exterior y se abre camino en tu red. Obtiene acceso al sistema de archivos de su base de datos y extrae su archivo MDF. Lo abre en su propia computadora local y busca datos de la cuenta de usuario que puede usar para llegar aún más lejos. Bueno, ¿adivinen qué? todo lo que ve es un montón de galimatías donde deberían estar sus contraseñas mal obtenidas. La cantidad de conocimiento que obtiene el atacante al ver los hashes, suponiendo que hayan sido adecuadamente salados y empleen un hash criptográficamente seguro, le brindarán la ayuda más mínima para poder acceder a su sistema.

Ahora, hay maneras más fáciles de descifrar un hash de contraseña que de descifrar otros mensajes hash, porque " a través de 20 años de esfuerzo, hemos logrado capacitó a todos para usar contraseñas que son difíciles de recordar para los humanos, pero fáciles de adivinar para las computadoras ". Sin embargo, el hash aún tiene valor, especialmente cuando se utiliza un hash diseñado para ser costoso de calcular, como BCrypt o PBKDF2. Cuando un hash de contraseña tarda un segundo en calcularse, incluso una contraseña débil (28 bits de entropía) llevaría hasta 8 años para adivinar mediante fuerza bruta, y si obliga a los usuarios a cambiar sus contraseñas regularmente, el atacante debe comenzar de nuevo ( después de alcanzar el nuevo volcado de base de datos) cada vez.

Como mencionan los demás, una contraseña con hash (no reversible) es mejor porque puede mirar la base de datos sin revelar la contraseña de los usuarios y ralentizar a un atacante. Pero hay algunos otros puntos que son posibles cuando la contraseña solo la conoce el propietario de la cuenta.

Puedes cifrar los datos con una clave aleatoria. La clave aleatoria se encripta con la contraseña del usuario. Entonces solo ese usuario puede obtener acceso, incluso si alguien cambia el hash en la base de datos. El inconveniente es, por supuesto, que si el usuario olvida la contraseña, todos los datos se pierden.

Esto puede incluso extenderse con certificados. Todos pueden cifrar, pero necesita la contraseña (que no es reversible del hash) para volver a leerla.

Tal sistema sería derrotado si almacenas las contraseñas claras. Tal sistema no es usual, pero ciertamente posible. Y en un sistema de este tipo, incluso con acceso r / w completo, debe interceptar la contraseña o los datos para obtener los datos, cambiar el sistema, lo que requiere a) mucho tiempo b) buen conocimiento del sistema y es por lo tanto no es tan fácil.

Edite: Ubuntu usa la contraseña de usuario para de / cifrar el directorio de inicio como lo describí . Si las contraseñas se almacenaran en texto claro, el administrador todavía podría acceder a los datos. Claro, mientras el usuario inicia sesión o se cambia el sistema para compartir las claves, copiar el directorio de inicio, etc., los datos ya no son seguros.

Pero las contraseñas de hash son como usar un chaleco de bala. Todavía se puede disparar en la cabeza.

No puedes pensar en un compromiso como un estado simple de tu compromiso o tu no. Hay diferentes niveles de compromiso y diferentes niveles de protección para limitar el compromiso o alertarlo cuando se haya visto comprometido. Si bien parece que estamos viendo un aumento en los compromisos de tipo "ciberdelito" activo y dirigido, es importante tener en cuenta que muchos, algunos incluso podrían sugerir una mayoría, de los compromisos de datos se han producido a través de accidentes y configuraciones erróneas en lugar de un "pirateo" deliberado. Si bien aún está limitado, el hecho de que su contraseña esté oculta proporciona cierta protección cuando el administrador del sistema cambia accidentalmente los permisos en un archivo clave y alguien puede descargar una copia de la base de datos de contraseñas del sitio.

Su punto con respecto a los administradores del sistema es válido. Aquí es donde la reputación se vuelve muy importante. Si utiliza un proveedor de correo electrónico que no conoce y no tiene confianza en él, que no tiene una reputación real, entonces debería estar muy preocupado o simplemente aceptar que existe una gran posibilidad de que un administrador de sistema esté leyendo su correo electrónico. El punto es que en la vida, a menudo tenemos que confiar en personas que realmente no conocemos bien. Hacemos esto todo el tiempo. La última vez que estuvo en un restaurante, ¿confió al camarero con su tarjeta de crédito? ¿Cuánta confianza depositas en la recepcionista de tu clínica médica?

A menudo, lo calcularemos en función de la reputación y el costo. Sabemos que la buena seguridad tiene un costo. Desafortunadamente, lo que mucha gente no reconoce es que los proveedores de servicios 'económicos' o económicos deben reducir los costos en algún lugar y, con demasiada frecuencia, ese lugar es la seguridad.

La conclusión es que en la mayoría de los sistemas, en algún nivel, habrá alguien que tenga acceso completo a toda su información y que no necesite su contraseña (existen situaciones en las que esto no es estrictamente cierto, pero sí lo son. en la minoría, así que asumamos que este no es el caso). La pregunta entonces es si confía en este proveedor de servicios con sus datos privados. ¿Está pagando lo suficiente para esperar un servicio confidencial? ¿Tiene el proveedor una inversión suficiente en reputación que tomará las medidas suficientes para garantizar que sus datos estén lo suficientemente protegidos, es decir, que se realice una selección adecuada del personal, buenas pistas de auditoría y una auditoría suficiente de los procesos para garantizar que los procesos de negocios sean adecuados y se sigan, etc.