Supongo que su objetivo es (como sugiere @owen) detener el uso de contraseñas comunes (por ejemplo, password123) utilizadas por su base de usuarios. Por lo general, esto es "algo malo" para la seguridad, ya que limitará de manera artificial la elección de las contraseñas de manera impredecible para el usuario.
Si piensa en la experiencia del usuario final de esta función, ¿le daría un mensaje "oye que eligió una contraseña común, elige otra"? Si es así, apostaría a que la mayoría de los usuarios pegarán un 1 o! al final de la contraseña e intente nuevamente y / o se frustre y salga (dependiendo del sitio), y como no va a revelar la lista de contraseñas de uso común, no hay forma de que el usuario sepa cuáles son / no están permitidos.
Un mejor enfoque podría ser comparar las contraseñas con una lista común, a la que puede señalarlas y si eligen una de esas contraseñas, sugieren que es una mala idea, pero déjelos seguir adelante si así lo desean.
Dicho esto, suponiendo que su objetivo sea el mismo que el anterior, no necesitaría tener las contraseñas asociadas con cuentas de usuario específicas, solo las necesitaría en una lista, por lo que no hay demasiados errores (en la mayoría de los casos) con simplemente almacenándolos con la misma sal y hash, luego verificando a medida que agrega nuevos usuarios. Si un atacante compromete esa tabla, todo lo que tiene (si rompe los hashes) es una lista de contraseñas utilizadas en la base de datos sin una forma directa de asociarlas de nuevo a usuarios específicos.
Otro riesgo a considerar si adopta este enfoque es que si el sistema permite que los usuarios se registren automáticamente, un atacante podría simplemente iterar sobre las contraseñas de uso común para ver cuáles han utilizado sus usuarios, ya que la aplicación las rechazará. ..