The basic idea in this approach is to encode the password before sending it, no matter in which direction. Therefore we could be sure that the plain password cannot be read without breaking the encoding before. While this approach has some merit, it is only really effective in reality when the encoding is either hard, lossy or both as with an encoding that is neither, a rule may be found to extract the original password again.
On the other hand, sending a password that went through such treatment to the user, it would/should be impossible for the user to find out if this password is really his or not. All web services that provide a reminder function where the stored password is sent to the user, and this password is, above all, in plain text too, may not be considered secure at all.
For this reason such reminder functions can only work with additional information (e.g. “whats the name of your first pet?”) provided by the user that was agreed upon earlier.
So to ensure the privacy of the password through its whole lifecycle is hard and needs some adjustments to otherwise accepted behavior, on the side of the users as well as the system.
The password must be generated by the user, it is then encoded locally with a lossy method and transferred over a secure connection (ssh,…) to the server where the password will be stored in a lossy state. All further compares base on the user sending a lossy encoded password and the server side controlling it.