0

Imagine a scenario where a client application is sending a password to a backend server so that the server can validate that the user entered the correct password when being compared to a stored variation of the password.

The transport mechanism is HTTPS with the server providing HSTS & HPKP to the user agent and strong cryptographic ciphers being preferred by the server scoring A+ on SSL labs test. None the less, we may wish to avoid sending the original user provided password to the server from the user agent. Instead perhaps we'd send a hash after a number of rounds of SHA-256 on the client.

On the server-side, for the storage of passwords we are using bcrypt with a large number of rounds.

From a cryptographic point of view, is there any disadvantage to performing bcrypt on the already sha-256 hashed value as opposed to directly on the plain text password? Does the fixed length nature of the input text when using hashes somehow undermine the strengths of the algorithm.

EDIT: I'm not asking about performance such as the memory, CPU, storage requirements or wall clock time required to calculate, store, sent or compare values. I'm purely interested in whether applying a hash prior to applying bcrypt could weaken the strength of bcrypt in the case of a disclosure of the full list of stored values.

David
  • 5,464
  • 15
  • 47
  • 86
  • Why bother hashing the password before sending it from the client? This gains you nothing. You are just changing what the password is. If you are hashing the password client side you need to hash that hash or encrypt that hash before storing server side. – bhspencer Jun 08 '18 at 13:42
  • Frankly you should just follow the industry standard recommendations. Which is don't hash the password client side. And on the server side store a salted hash of the password. – bhspencer Jun 08 '18 at 13:45
  • I'm not sure it's entirely true to say that the industry standard is to not hash the password client side and that it gains you nothing. I've worked with colleagues who have worked in major UK banks who have said that this was standard in their mobile banking apps (do never send clear text passwords to the server - even if the transport mechanism is HTTPS). There can be opportunity for accidental disclosure, perhaps a MITM who has managed to manipulate certificates, accidental logging on the server side which logs plain text passwords which happened recently at twitter. – David Jun 08 '18 at 13:56
  • Do you see that if you hash the password client side you are just changing what the password is? If the hashed password being sent to the server is intercepted, the bad guy could use that hash to log in. Which is to say if the hash is compromised it can be used to log in with. You had better not be logging the client side hashed password in the server logs as it is now equivalent to the password. – bhspencer Jun 08 '18 at 14:00
  • Regarding your other point, as stated in the OP, on the server we are using bcrypt to store the passwords which will include a salt and hash with a large number or rounds. AFAIK this is following good guidance in 2018: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet – David Jun 08 '18 at 14:00
  • Yes, you are right @bhspencer. It is just changing it and in the context of just my application it would mean that someone can just use the hash to login if they intercept it. The main difference is that even with password managers and user education coming along, many people do re-use passwords. Not sending the origin plain text password is (i think) not a bad thing to do. My main question really was does some cryptographic property of bcrypt degrade from a mathematical perspective if all inputs given to it are a fixed length and restricted character set (like a SHA2 hash) – David Jun 08 '18 at 14:02
  • I think your question would be a better fit for https://security.stackexchange.com/ – bhspencer Jun 08 '18 at 14:05
  • It is not exactly the answer you may be looking for, but in this [answer](https://stackoverflow.com/a/50714929/575765) I tried to explain why the advantage is only marginal. – martinstoeckli Jun 10 '18 at 14:02

1 Answers1

0

For anyone interested in this, I followed advice and asked on security.stackexchange.com here

David
  • 5,464
  • 15
  • 47
  • 86