Let's say I wish to setup a classic username & password authentication strategy on a server. All communication is encrypted via TLS. But ideally, I still do not want the server to be able to read the passwords in plain-text, even temporarily. To that end the client could send the password that is hashed and salted with some key (for simplicity let's assume it's the username). Let's call this a derived password. The server would then in turn hash and salt the derived password using an algorithm like Bcrypt or PBKDF2 and store it for future requests.
So far none of this is novel and there are plenty of discussions about this topic. But what I cannot find in these discussions is how to perform server-side validation of the strength of the plain-text password in question? Any client-side strength validation can be bypassed, or a client application might have a bug that insufficiently validates the strength, hence, strength validation is ought to be done on the server. But at the same time I do not want the server to have access to the plain-text password.
So my question is, are those 2 requirements mutually exclusive, or is there some way to achieve both requirements? Could the strength validation be done based on the derived password? At the very least, is it possible to check the length of the plain-text password using the derived password to prevent registration with, say, empty password? Or do I, as a project owner, just have to accept that some users can bypass client-side validation and shoulder no responsibility if their accounts get compromised as a result of bypassing client-side strength validation?
I realize that one could employ a mixed strategy, where a password is sent from a client in plain-text form only during registration/password reset, and in salted, hashed form for any subsequent request. This is an improvement over sending password in plain-text all the time, but still does not satisfy the requirement of never exposing the plain-text password to the server.