I do not mean generating a hash on the client side and then storing it in the database directly. I found a few questions with similar theme, but most of those answers assumed a scenario where passwords were send through unencrypted connections or the client hash was stored directly in database.
(1) The scenario I am describing is an extra step on top of the existing workflows where user sends the plaintext via https connection and the server hashes it with a salt and store the hash and salt in the database. So instead of sending the actual password what if a hash is calculated on the client side and sent to the server. For all intents and purposes the server then considers this initial client hash as the user's plaintext password and then rehash with the salt using its own hashing method as it would usually do. In a case where the server accidently logs user's password input (eg: while debugging), the actual password will still be safe.
(2) Also if client side hashing is not a bad security practice, what about appending a common string unique to the app (eg: app's domain name) or a unique string(eg: username) to user's password before hashing to ensure that the client hash for same password would be different from a similar hash generated by another app. Does it matter the position of such a string (appended or prepended).
One problem I can think of is that the server would be unable to enforce a specific password complexity upon the users. Users can still be warned (or passwords can be rejected) on the client side, but a user can still choose to bypass it and send across any string that is of same length as the expected hash length.
