Creo que la falla en tu plan es tu declaración
H0 es desconocido para los hackers, pero aún es verificable por el servidor.
Este no es el caso. Recuerda que los hashes son una forma. Todo lo que el servidor ha recibido de usted es H1, que se ha convertido en H2 (y que ahora está comprometido). El servidor no sabe cuál fue la entrada que generó H1 (es decir, H0). Además, se supone que el servidor solo ha mantenido H2 y no retiene H1. Si hubieran retenido H1, entonces sí, podrían tener H0 y comparar con H1, pero han mantenido H2.
Si lo piensas, si bien H1 es lo que originalmente enviaste al servidor, desde la perspectiva del servidor, es solo una contraseña, una contraseña potencialmente larga, pero solo una contraseña. El servidor entonces necesita hash esa contraseña para almacenarla (creando H2). También esperamos que el servidor no tenga registro de H1. Cuando se autentica, envía H1, que el servidor utiliza para obtener H2. Para que su esquema funcione, el servidor también tendría que mantener H1, lo que sería como mantener una contraseña de texto simple. Una vez que un pirata informático se apoderó de la base de datos de hashes H1, puede acceder al servidor como el usuario asociado con ese hash sin tener que hacer nada más.
La otra parte de su sugerencia, que probablemente necesite más reflexión, es
Parchea el cliente para enviar ahora (y el servidor ahora requiere) el hash H0.
Ese es un problema potencial o, al menos, es probable que sea tanto trabajo como simplemente cambiar su contraseña. Si tuviera que permitir este tipo de cambio automáticamente y, por lo tanto, reducir / evitar la necesidad de que el usuario tome medidas, está abriendo otro posible problema de seguridad: cómo / quién iniciaría ese parche y cómo evitaría el parche no autorizado. Si desea que el usuario realice la aplicación de parches, probablemente se requiera más esfuerzo para hacerlo bien que solo para cambiar su contraseña.
EDITAR: Como se señaló en el comentario, se puede verificar el hash H0 mediante el hash dos veces H0 - > H1 - > H2 y comparando con el H2 que tiene el servidor. Así que tal vez esa parte de la ecuación podría funcionar.
Sin embargo, la aplicación de parches o la coordinación del cambio de usar H1 a usar H0 sigue siendo un problema IMO. Los mecanismos de actualización / parche "normales" no funcionarán, ya que dichos mecanismos se basan en una única "fuente de verdad" de confianza. Por ejemplo, si está en Windows confía en el servicio de actualización de Windows y si está en OSX, confíe en el servicio de actualización de OSX. Pero con respecto a los sitios web, estamos tratando con infraestructura descentralizada.
Considere un entorno en el que todos o algunos subconjuntos de todos los servidores web hayan adoptado este esquema. Si un servidor web está comprometido, de alguna manera es necesario que el servidor informe al cliente que ahora necesita enviar H0 en lugar de H1. En este punto, las cosas comienzan a ser muy complejas y la complejidad es el enemigo natural de la seguridad.
No puede realizar el cambio globalmente, es decir, ahora requiere que todos los sitios que usan este esquema utilicen H0 en lugar de H1 porque esto causaría un problema de coordinación. De alguna manera, tendría que decirle a todos los servidores que usan el esquema que cambien a H0 - > H1 - > Método h2. Ahora tiene que actualizar los servidores y los clientes y coordinar ese cambio o algunos sitios dejarán de funcionar.
Por lo tanto, deberá hacerlo por sitio. Esto significa que necesitaría tener algún mecanismo integrado en su esquema que le permita al servidor indicar al hash que desea para la autenticación: H0 o H1. Ahora tienes otro problema. ¿Cómo se protege contra un servidor falso que solicita H0?
Dado que uno de los mayores problemas con cualquier esquema de contraseña es que las personas tienden a usar la misma contraseña en varios sitios. Sabemos que esto es una mala práctica, pero la gente lo hace de todos modos. Si fuera a visitar un servidor defectuoso, podría pedir H0. Ahora ese servidor tiene H0 y puede hacerlo para obtener H1 y usar ese hash para acceder a otros servidores que podría usar que aún dependen del H1 original como contraseña. Esto incluso podría ser parte de otro vector de ataque en hosts comprometidos: una vez que haya comprometido a un host, podría comenzar a solicitar hashes H0.
el verdadero problema aquí es que estamos agregando complejidad adicional, lo que agregará 'agujeros' imprevistos que solo agregan la mínima seguridad adicional posible y no solucionan el enfoque fundamental (y probablemente no solucionable) del uso de contraseñas para garantizar el acceso. Estas contraseñas como un control de acceso en sí mismas simplemente se rompen. Lo que realmente se necesita es una forma conveniente de agregar factores adicionales al proceso de autenticación y alejarse de los enfoques que se basan en una simple palabra secreta