Should BCRYPT be used for client-side password hashing

Ken Clubb
  • Should BCRYPT be used for client-side password hashing Ken Clubb

    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.

  • 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

Tags
passwords hash bcrypt
Related questions and answers
  • encoded. The transmission is done via HTTPS. The server decodes username+password and computes a hash from the password which he then checks with a hash for that user in the database. I have taken the hashing algorithm and code from here and here. My assumptions: If I assume that the client itself has not been compromised, this should be secure. If someone gains access to the server's database... because it means that I am slightly limited when it comes to the use of frameworks that might help with security. What I am currently doing is the following: The client has the password stored

  • of security through the Keyed hashing ? P.S: I am aware of the value that slow hashing algorithms add by reducing the possibility of passwords getting compromised through brute force attacks. Just want... the password hash when needed). Since the salt is meant to be random (to protect them from the rainbow tables / dictionary attacks), the salt provided to the pbkdf2 should be a concatenation of the key and a random bytes generated from a CSPRNG. [salt] = [secret key] + [random bytes from a CSPRNG] Finally, I will dare to ask a silly question (will dare to ask since high iteration count

  • he has the salts too. The article mentions HMAC with a secret key. this is pretty unclear to me ? what is the secret key ? how is it tied to each user ? i can login from any machine in the world, so how is the secret key tracked ? And again we have the same scenario as above if the database is compromised . how does password sending from client to server work exactly. I understand the server...I was going through (https://crackstation.net/hashing-security.htm) about doing password hashing / storage the right way. I understood most of it but i still have some questions and doubts which

  • I read at crackstation not to use these variants of bcrypt* ($1$, $2$, $2a$, $2x$, $3$),but I've used bcrypt ($2a$) in various sensitive implementations recently. Can any security expert clarify why recommending ($2y$, $5$, $6$) instead of ($1$, $2$, $2a$, $2x$, $3$), what is the original version proposed by Niels Provos, and in what they differ bcrypt is a key derivation function for passwords... is an adaptive function: over time, the iteration count can be increased to make it slower, so it remains resistant to brute-force search attacks even with increasing computation power.

  • access to your source code and probably won't be able to guess your wacky hash, making any attempt at a brute force impossible. (This one is the real motivation behind me asking this question) BCrypt...I'm afraid I'll have tomatoes thrown at me for asking this old question, but here goes. After reading that cooking up your own password hash out of existing hashing functions is dangerous over... then these wacky hashes still function as secure hashes, and our system doesn't break Kerckoffs's principle anymore than it would with a standard hash. Here are two possible (and worthwhile, as far as I

  • . The password that is hashed is "password" so it shouldn't be a problem to crack utilising basic wordlists. That leaves me with the possibility that I'm using a wrong hashing algorithm in my cracking session or more likely I'm using the salts incorrectly during the session. What am I doing wrong? Do you know what algorithm is applied for authentication between a client and MySQL server? How do I apply... is in plain text but the password is hashed using two salts which are also visible in the "server greeting" packet sent to the client, right after TCP connection is established. I've ran Hash-Identifier

  • I've been reading about it. This article helped me a lot. But the more I read the more complicated it seems. For example: Is it better to use bcrypt, or PBKDF2, sha2 or something else for the salt? How do I add HMAC encryption passwords? Suppose I have to store passwords (all information, hashes, salt .... ) in a single file. I plan to do it this way: Obtain password from the end user. Create a salt. Create hash = SHA256(salt + password) and store salt together with hash in the file. But I am not sure how to improve it. I do not understand how to use HMAC Well the question is: What

  • I'm making an auth service so I've been looking for some good Java/Groovy implementations of password + salt hashing. I've found this article on crackstation along with a code example and decided to make it mine. First thing I noticed is SHA1 and only 1000 iterations so I changed those to SHA256 and 90510(still have to test the performance on the server and perhaps increase it to at least 100k... to giving away a piece of the key? Or am I just too paranoid. I have removed it, but I'm wondering why is it there? What is the purpose of showing that? In case the default number of iterations changes

  • when trying to login. E.g. the user can choose the current (day + 7). So, if my password is myPassword, and today's date is 11, then I have to type myPassword18. Which means that if I have to login... that viewpoint. Validating the user's password during login: I am using password hashing/validation as it is described here https://crackstation.net/hashing-security.htm#properhashing so, the hashing part looks without issues, and I am hashing only the myPassword part of course. During validation when I fetch the user's data from the database I can check and see that that option is enabled, and based

Data information