¿Hay valor en almacenar contraseñas en su propia tabla con claves cifradas o con hash?

Si usa una función de hashing de contraseña criptográfica apropiada (por ejemplo, bcrypt, scrypt o PBKDF2), el valor agregado por este enfoque es insignificante. Así que, en realidad, la solución es simplemente copiar sus contraseñas de manera responsable en primer lugar.

Eche un vistazo a mi respuesta aquí hablando sobre la información de segregación de contraseñas. Combinado con un conjunto de permisos diferente que no permite la lectura pero que permite la comparación por medio de un procedimiento almacenado, la separación de la información de la contraseña sería realmente útil.

No puede ir efectivamente cifrando o haciendo hashing de valores clave porque la salida sería aleatoria. O bien necesitaría un espacio lo suficientemente grande para evitar colisiones y luego se encontraría con cantidades dolorosas de fragmentación de la base de datos donde se producen inserciones en todo el lugar y las páginas se dividen. Los valores clave deben permanecer incrementando los enteros para la cordura de todos.

  

Supongo que podría ser fácil detectar un ataque que está utilizando una lista de contraseñas que existen para los usuarios en el sistema y bloquear o cerrar el ataque de otra manera.

No. Eso implicaría verificar la lista completa de posibles hashes, lo que sería costoso si ha utilizado métodos adecuados de salazón y hashing.

Si comparte con sal y contraseñas sus contraseñas de manera adecuada, el sistema que usted propone no agrega ningún valor. Si un atacante puede obtener una base de datos, probablemente puede obtener ambas. Un hash agregado en la clave externa no proporciona ningún aumento apreciable en la seguridad más allá del hashing de sus contraseñas.

Además, dependiendo de cómo implemente dicho sistema, podría causar pérdidas sustanciales de rendimiento.

Esto es seguridad por oscuridad, OMI. El paso adicional del hashing de la ID de usuario para generar una contraseña es trivial para recrear una vez que se conoce. Debido a que los nombres de usuario no se almacenan en forma de hash en su tabla de usuarios, y porque algo, en algún lugar, debe tener acceso de lectura a ambas bases de datos, si un atacante puede obtener un volcado de su tabla de usuarios y obtener nombres de usuarios, puede obtener un volcado de la tabla de contraseñas también y conecte los puntos. Lo único desconocido es el algoritmo de hash utilizado, y debido a que hay un pequeño número de funciones hash seguras adecuadas para este propósito, es trivial probarlas todas (y no piense ni por un minuto que estoy abogando por crear su propio hash). o usar uno oscuro, eso es más seguridad por oscuridad).

Si el método de hashing es seguro y la contraseña tiene una entropía no trivial ( las 10 contraseñas más comunes más comunes y derivaciones simples de los mismos tienen efectivamente cero entropía, ya que son lo primero que intentará hacer un cracker), puede pintar con aerosol su hash de contraseña en su automóvil y conducirlo a la mitad de DEF CON y estará perfectamente bien. Ese es el punto; el ataque más eficiente del hash ideal debería ser el ataque de cumpleaños, que aún debería ser inviable con la combinación adecuada de entropía de entrada, tamaño de compendio y costo computacional.

Hashea las contraseñas por una razón específica: en caso de que un atacante pueda obtener una copia de las tablas de su servidor. Hundimos contraseñas para evitar que el atacante incremente un acceso parcial de solo lectura a un acceso de lectura-escritura (consulte esta entrada de blog para una discusión más detallada). El hash de contraseñas ya es una segunda capa de defensa.

Su propuesta es acerca de agregar una tercera capa: tiene valor solo si el escenario de ataque es que el atacante podría obtener un acceso de solo lectura en la tabla one pero no en ambas. Sin embargo, este escenario no es muy realista, ya que tal acceso de solo lectura proviene a menudo de ataques de inyección de SQL, y los elementos del servidor que tienen el permiso para leer la tabla de usuarios a menudo también tienen el permiso de leer la contraseña con hash (en particular el sistema de inicio de sesión, que debe, por definición, utilizar ambos).

Por lo tanto, debe equilibrar la seguridad adicional con la complejidad adicional, ya que se sabe que la complejidad es el enemigo enemigo de la seguridad. En ese caso, no creo que la complejidad adicional valga la pena, ya que el escenario para el que la división de la tabla agregaría algo de seguridad es inverosímil.