Hashing contraseñas y tratar con duplicados

Una de las razones por las que password_hash produce resultados diferentes para la misma contraseña es para evitar fugas de información y hacer que las contraseñas sean más difíciles de descifrar si un atacante obtiene los hashes. Realmente no desea comprometer esta función de seguridad: no solo será una menor protección para los datos del cliente, sino que también lanzará su propia solución en lugar de utilizar soluciones bien admitidas y con un buen soporte.

El uso de una contraseña idéntica para detectar varias cuentas por parte del mismo titular de la cuenta es una mala idea, ya que puede causar falsos positivos y bloquear las cuentas legítimas.

El problema de X Y

Lo que tienes es el clásico XY Problem (xyproblem.info ). Desea evitar que los usuarios tengan varias cuentas, y piensa erróneamente que implementar un sistema de contraseña dañado y comparar hashes lo ayudará a resolver este problema. Así que preguntaste cómo detectar contraseñas idénticas. Tal como se describe en la respuesta de @Ggd, intentar esto genera falsos positivos, se puede eludir fácilmente y lo obliga a desechar prácticas de manejo de contraseñas probadas y verdaderas.

Resolviendo tu problema real

Su pregunta real detrás de la pregunta es "¿Cómo puedo evitar que los usuarios tengan varias cuentas?". Esta pregunta se le ha preguntado antes . Sin embargo, una pregunta es de 2008 e incluso menciona "Cuentas con la misma contraseña" como factor de mitigación, y la otra no entró en suficientes detalles / opciones, por lo que parece que este problema debería revisarse.

Como usted y su compañía ya han descubierto, no existe una solución simple e infalible para esto. Lo que puede hacer es tener un esfuerzo inteligente de varios frentes para minimizar el problema. Las comprobaciones válidas incluyen:

• Registro de IP : esto puede crear falsos positivos para los grupos que comparten una única IP pública y se puede evitar mediante el uso de proxies, tor o solicitudes DHCP. Sin embargo, puede ser un buen primer paso para investigar la posibilidad.
• Verificación de correo electrónico : exigir que el usuario proporcione y haga clic en una verificación de correo electrónico es otro cheque válido, pero fácilmente distribuido.
• Verificación de teléfono móvil : similar al correo electrónico, pero requiere validación por SMS al registrarse (menos intrusivo) o iniciar sesión (más intrusivo, posible DoS si el teléfono / señal no está disponible).
• Siga el dinero : solicite una tarjeta de crédito o un enlace a una cuenta válida de PayPal (u otro servicio). Posiblemente realice una micro-transacción y solicite los detalles para probar que la cuenta está bajo el control del usuario.
• Credencial específica del dominio : ¿se requiere una certificación para la base de usuarios (por ejemplo, un sitio para enfermeras registradas podría requerir un número de licencia válido)?

Sin duda, las soluciones prácticas para su problema requerirán un equilibrio. No desea desalentar a los usuarios con una barrera de entrada demasiado alta, a menos que esté más preocupado por "una persona, una cuenta" que por el crecimiento y la tracción. DEFINITIVAMENTE, no desea poner en peligro la seguridad de la cuenta de sus usuarios con un sistema de contraseña incorrecta como parte de este compromiso: los costos legales, financieros y de reputación de una violación superan con creces cualquier beneficio (dudoso).

Yo diría que hay una manera de hacerlo de manera segura, según esta declaración en su pregunta:

  

Una de las formas que han utilizado es comprobar si los hashes MD5 son los mismos en las dos cuentas sospechosas

Lo que se solicita no es una forma de identificar automáticamente cualquier par de cuentas con la misma contraseña. Solo necesita una forma de decidir si un par de cuentas comparten la misma contraseña una vez que ya existe una sospecha.

Basado en eso, resolvería el problema de esta manera:

1. Almacene la contraseña de forma segura con un hash con sal.
2. Cree una tabla adicional que enumere pares de cuentas que se sospecha que estén usando la misma contraseña y un estado para cada par.
3. Cuando se sospecha que una pareja está usando la misma contraseña, insértela en la tabla de sospechosos con el estado establecido en desconocido .
4. Después de cada búsqueda exitosa de inicio de sesión para el usuario en la tabla sospechosa.
5. Si se encuentra al usuario en la tabla sospechosa, pruebe la contraseña con el otro usuario en ese par. Si el estado es desconocido , cámbielo a idéntico o diferente .

Por supuesto, como han señalado otros, la contraseña que es idéntica es solo una señal de muchas. El enfoque más confiable sería combinar muchas señales diferentes. El método de verificación que propongo aquí solo debe usarse como una última medida si haría la diferencia entre la sospecha de estar por debajo o por encima del umbral para actuar.

Si las otras señales pueden colocar claramente los pares de cuentas en un lado del umbral, independientemente de la equivalencia de las contraseñas, no es necesario colocarlas en la tabla de sospechosos en primer lugar.

Hay una forma de verificar que una contraseña no coincida con ninguna contraseña.

Podrías, al cambiar la contraseña, verificar esa contraseña única con cada otra contraseña en la base de datos ya que tendrás la contraseña sin cifrar. Esto podría tomar un tiempo, pero es factible. Esto podría fácilmente conducir a un ataque DoS, ya que una sola acción podría causar una alta CPU durante un tiempo prolongado. Además, sin embargo, está al tanto de qué usuarios tienen contraseñas coincidentes que podrían usarse para priorizar qué contraseñas descifrar. Un atacante que ya tenga todas las contraseñas y la lista de usuarios con contraseñas coincidentes podría intentar forzar las contraseñas con varias cuentas primero.

Como lo expresan otras respuestas, no creo que este deba ser un método usado para determinar cuentas duplicadas. Las múltiples cuentas a las que se accede desde la misma IP probablemente proporcionarán menos falsos positivos. Sería mejor instalar una cookie que indique el último usuario que inició sesión e iniciar sesión silenciosamente cuando esa cookie no coincida con el usuario que está conectado actualmente.