Should BCRYPT be used for client-side password hashing

Question

I am concerned about the use of bcrypt for client-side password generation. I am developing a password generation function to be used client-side, similar to PwdHash and PasswordMaker.

Much has been said about the advantage of using bcrypt over faster hash functions because it slows down brute force attacks. I know bcrypt uses Blowfish internally, which is a symmetric encryption algorithm rather than a hash algorithm. So there must be a hard-coded key somewhere to use bcrypt, and since Blowfish is being used, it stands to reason that if the key is discovered, the password derivation can be reversed and the original password discovered.

Since client-side code can be decompiled, the key could be easily discovered, making bcrypt unsafe to use client-side. Is my reasoning correct or have I missed something?

Also, in a related question, wouldn't the same argument be valid server-side as well. A hash function cannot be reversed, but an encryption function can be if the key is known. Wouldn't it be safer to use a real hash server side, even if it is faster and therefore more susceptible to brute force attack, than to use bcrypt which is reversible?

EDIT: user10008 notes below (post has been removed) that only parts of Blowfish are used in bcrypt and gave me a link. When I followed a link I found a function prototype that includes key as the last argument. So I still see the key being used to kick-start the bcrypt algorithm. If the key is required, and bcrypt uses symmetrical encryption instead of hashing, isn't the operation reversible?

EDIT: Good answers from both martinstoeckli and user10008. I gave the answer to marginstoeckli because of the last sentence in the response:

BCrypt can be seen as encrypting with throwing away of the key.

This really cleared it up for me. Basically, we go through 2 phases

P -> K ; P,K -> C

and then throw away key K, leaving cyphertext C. Because we throw away the key K, we cannot decrypt back to plaintext P. Throwing away K effectively makes bcrypt a one-way function.

EDIT: From user10008, the steps I gave above are more complex, however the essence is that the key K is used in the final phase and discarded. Thanks user10008.

Answer 1

It's just the other way round, BCrypt does not encrypt the password with a secret key, rather it uses the password as the key to encrypt a known text. In the setup where the key is generated, it uses both salt and the password (variable EksBlowfishSetup.key), to generate a key (variable bcrypt.state) used for encryption.

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 can be seen as encrypting with throwing away of the key.

Answer 2

Bcrypt is not reversible. You can use it client-side as well as server-side.

The key is not static but rather dependent on the password, generated by the function call EksBlowfishSetup(cost, salt, input). The plaintext is known and public, its "OrpheanBeholderScryDoubt". If you wanted to retrieve the key, you would need to mount a known-plaintext attack on 64-times-blowfish, which is very hard, and then you would still only get the key, and not the password.

Wikipedia gives a pseudocode overview of the bcrypt algorithm:

 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)

Answer 3

Edited to add: It turns out that what I've written is correct, but it isn't an answer to the question that was asked. I apologize.

Whatever you send from client to server is the password, whether it has been hashed, sliced, or diced. A password hashed on the client is no more secure than the same string, unhashed. If it is intercepted, it can be used for a replay attack in either case.

The important thing is to be sure the password is transmitted encrypted, e.g. with SSL/TLS.

Have a look at this for a fuller explanation: https://crackstation.net/hashing-security.htm

Answer 4

It's not clear what language you're using, but in the more recent PHP they make this easy by having you use a built-in hash function that can account for the latest and best encryption. There's a verify function to test against the hash. There is also a rehash function that can account for future changes, such that the old hashes can be updated and still verified against. Given the proper implementation, this should take care of most of the issues you might run against. However, as Jeff-Inventor ChromeOS points out, most uses of a hash don't require much more than a simpler algorithm. It depends on your needs and how much you are willing to sacrifice security over processing time/power.

Answer 5

Common practice is just to use any hash algorithm, such as SHA-2 on the client. For slightly more security, a slow hash can be used such as PBKDF2, bcrypt, or scrypt. A slow hash is a hash designed to require a great deal of computational power, making brute force attacks with lists of common password more diffucult.

The actual security advantage of slow hashes is not large, though, because users select passwords from a fairly small list of common passwords. In my own analysis, about one million passwords (20 bits) recover 50% of accounts (http://www.w3.org/2005/Security/usability-ws/presentations/37-google.pdf). As few as 1000 passwords recover a significant fraction of accounts (6.1%).

It's impossible to hash such a small amount of entropy enough that it becomes a significant hurdle for an attacker.