¿Debería usarse BCRYPT para el hashing de contraseñas del lado del cliente?

Es al revés, BCrypt no cifra la contraseña con una clave secreta, sino que utiliza la contraseña como clave para cifrar un texto conocido. En la configuración donde se genera la clave, usa tanto salt como la contraseña (variable EksBlowfishSetup.key ), para generar una clave (variable bcrypt.state ) utilizada para el cifrado.

bcrypt(cost, salt, input)
    state \gets EksBlowfishSetup(cost, salt, input)
    ctext \gets "OrpheanBeholderScryDoubt" //three 64-bit blocks
    repeat (64)
        ctext \gets EncryptECB(state, ctext) //encrypt using standard Blowfish in ECB mode
    return Concatenate(cost, salt, ctext)

EksBlowfishSetup(cost, salt, key)
    state \gets InitState()
    state \gets ExpandKey(state, salt, key)
    repeat (2cost)
        state \gets ExpandKey(state, 0, key)
        state \gets ExpandKey(state, 0, salt)
    return state

BCrypt se puede ver como cifrado con la eliminación de la clave.

Bcrypt no es reversible. Puede usarlo tanto en el lado del cliente como en el lado del servidor.

La clave no es estática sino que depende de la contraseña, generada por la función call EksBlowfishSetup(cost, salt, input) . El texto plano es conocido y público, su "OrpheanBeholderScryDoubt" . Si desea recuperar la clave, deberá montar un ataque de texto sin formato conocido en 64-times-blowfish , que es muy difícil, y aún así solo obtendrías la clave, y no la contraseña.

Wikipedia proporciona una descripción general de pseudocódigo del algoritmo bcrypt :

 bcrypt(cost, salt, input)
     state ← EksBlowfishSetup(cost, salt, input)
     ctext ← "OrpheanBeholderScryDoubt" //three 64-bit blocks
     repeat (64)
         ctext ← EncryptECB(state, ctext) //encrypt using standard Blowfish in ECB mode
     return Concatenate(cost, salt, ctext)

Editado para agregar: Resulta que lo que he escrito es correcto, pero no es una respuesta a la pregunta que se hizo. Me disculpo.

Lo que sea que envíe desde el cliente al servidor es la contraseña, ya sea que se haya copiado, cortado o cortado. Una contraseña con hash en el cliente no es más segura que la misma cadena, sin romper. Si es interceptado, puede usarse para un ataque de repetición en cualquier caso.

Lo importante es asegurarse de que la contraseña se transmita encriptada , por ejemplo. con SSL / TLS.

Eche un vistazo a esto para obtener una explicación más completa: enlace

La práctica común es usar cualquier algoritmo hash, como SHA-2 en el cliente. Para un poco más de seguridad, se puede usar un hash lento como PBKDF2, bcrypt o scrypt. Un hash lento es un hash diseñado para requerir una gran cantidad de poder computacional, lo que hace que los ataques de fuerza bruta con listas de contraseñas comunes sean más difíciles.

La ventaja de seguridad real de los hashes lentos no es grande, sin embargo, porque los usuarios seleccionan las contraseñas de una lista bastante pequeña de contraseñas comunes. En mi propio análisis, cerca de un millón de contraseñas (20 bits) recuperan el 50% de las cuentas ( enlace ). Tan solo 1000 contraseñas recuperan una fracción significativa de las cuentas (6.1%).

Es imposible hacer un hash con una cantidad tan pequeña de entropía que se convierta en un obstáculo importante para un atacante.

No está claro qué lenguaje está utilizando, pero en el PHP más reciente, esto lo hace fácil al usar una función hash incorporada que puede dar cuenta del mejor y más reciente cifrado. Hay una función de verificación para probar contra el hash. También hay una función de rehash que puede dar cuenta de cambios futuros, de modo que los hashes antiguos pueden actualizarse y aún pueden verificarse. Dada la implementación adecuada, esto debería ocuparse de la mayoría de los problemas que podría enfrentar. Sin embargo, como señala Jeff-Inventor ChromeOS, la mayoría de los usos de un hash no requieren mucho más que un algoritmo más simple. Depende de sus necesidades y de cuánto esté dispuesto a sacrificar la seguridad en el tiempo / poder de procesamiento.