¿Sería seguro usar una contraseña ya con hash + con sal?

  

realizó los pasos que un sitio web haría con la contraseña y usaría el resultado como nuestra contraseña actual

Esto casi solucionaría el problema de la reutilización de la contraseña. Si el usuario eligió una contraseña maestra y usó un hash de contraseña para obtener una contraseña diferente para cada servicio (por ejemplo, con el nombre de host del sitio web), cada sitio teóricamente no podrá acceder a las cuentas del usuario en otros servicios.

Sin embargo, digo "casi" porque, en la práctica, la mayoría de los usuarios eligen contraseñas con entropía insuficiente para protegerse con el hashing de contraseñas. Esto significa que cualquier servicio al que acceda el usuario (o cualquiera que interrumpa cualquiera de esos servicios) podría descifrar la contraseña derivada del usuario para determinar la contraseña maestra, dejando al usuario completamente comprometido. Por esta razón, las contraseñas generadas aleatoriamente + un administrador de contraseñas sigue siendo la mejor práctica, ya que las contraseñas resultantes no tienen relación entre sí (o con la contraseña maestra).

Dicho esto, con una contraseña suficientemente fuerte, este esquema es realmente seguro. Una contraseña de 8 palabras generada usando Diceware tendría aproximadamente 103 bits de entropía. Si este esquema se utilizara con un buen hash de contraseña, sería prácticamente imposible descifrar la contraseña maestra (suponiendo que la implementación sea correcta, no haya avances de cifrado, etc.).

Como se mencionó en los comentarios, aún es algo importante que el servidor tenga la "contraseña" que recibe. Imagínese si un atacante puede volcar una tabla de usuario, pero no puede comprometer completamente el servidor / servicio. El acceso a las contraseñas derivadas permitiría al atacante acceder a la cuenta de cualquier usuario en cualquier parte de ese servicio, lo que potencialmente podría ampliar el impacto de la violación.

En caso de que alguien malinterprete esto, permítame incluir un recordatorio rápido: implementar esto en JavaScript junto con un formulario de inicio de sesión no proporcionaría ninguna protección contra un servidor malicioso, ya que un servidor malintencionado puede reemplazar ese JavaScript con otra cosa.

Creo que tu falla está en esta declaración:

  

Si el cracker determina que este es el método que se usa, tomaría mucho más tiempo porque el hash en sí mismo toma tiempo de CPU, y tendrían que determinar el método de hashing utilizado. Además de eso, tendrían que aplicar la fuerza bruta a la semilla correcta ...

Como en su sistema, el hashing ocurre en el lado del cliente, el cracker tiene acceso al código que hace el hashing, probablemente Javascript, lo que significa que es el código fuente.

Del mismo modo, la sal debería estar contenida en el mismo Javascript.

Así que el cracker ya tiene todo lo que necesita en términos del algoritmo. Lo que en realidad no puede ser un problema, porque si su seguridad se basa en mantener el algoritmo en secreto, tiene otros problemas que resolver. En cualquier caso, el algoritmo sería fácil de adivinar, ya que solo hay unos pocos candidatos posibles (o puede rodar el suyo y esperar que realmente sea seguro. ¡Buena suerte con eso!)

En general, si entiendo su esquema correctamente, esto parece muy similar al esquema de autorización de desafío-respuesta NTLM en Windows. Aquí hay una reseña muy buena sobre los diversos vulnerabilidades de NTLM, y muchas pueden traducirse a su situación. El artículo es demasiado largo para citarlo, pero los problemas principales parecen ser:

• En NTLMv1, hubo detalles de implementación que dejaron vacíos. En efecto, convirtió la contraseña a solo una clave de 56 bits.
• NTLMv2 aún es vulnerable a ataques de intermediarios y otros ataques.