I think showing user passwords to the admin user as default is just plain wrong. If you really have admins that require to see the passwords of their clients, make at least some kind of option to turn them off as default. I don’t want to know every password of my clients or my fellow admin users. And I certainly don’t want them to see mine.
I don’t know any other system that let’s admin users to pretend as client users.
Hey Matti,
I agree with you, to some degree, but the reality of passwords make it impossible to do otherwise. Jamie and I fought saving passwords in a readable format for two or three years…but people complained a LOT about having to type in the password whenever making changes to various services, and the reality is that if a user has administrative login in Webmin there’s nothing anyone can do to prevent them from doing everything a user-level password permits.
Here’s why we store them:
Think about everywhere passwords are used…
Now imagine you had to punch in a password everytime any of those features were used, enabled, etc.–not just any password, either, one that you then had to communicate to your user (because you’re asking to not know their password, remember?). Now, keep in mind, none of these passwords uses the same hash type, so we can’t just pass around the hashed password and drop it into place, as that won’t work. We could pretend that the data is encrypted and hash it with our own two way hash…but then we’d just be pretending. Any administrative level user could get hold of the password, anyway. We could hash it against the root level user, and then it’d only be accessible to root…which might be OK for some folks, but not anyone that delegates anything to non-root users. I suppose we could allow hashing against some key that you could inform all of your administrators of. However, virtual server administrators would no longer be able to do any of the stuff above, without typing in passwords for all of them. You customers won’t enjoy that.
Folks were every bit as indignant as you are now that they had to keep typing in passwords and telling their users about all these different passwords. Life is hard, and we can’t please everyone, I’m afraid. 
If you’ve got an idea for how to solve this problem, I’m all ears…but as it stands, it’s the lesser of two evils.
Oh, yeah, I’ll ask Jamie to add an option to hide the show password link. No reason to make it easy (though finding it out will always be possible for an administrative user).
Well I agree that admin (root level) users are able to get hold of all users password one way or another. And I’m not complaining about you saving passwords in plain format because I know they can only be read by root. But what I am complaining about is that virtualmin shows passwords of email users BY DEFAULT in the edit page. That is insane. Even if you try not to know the password you have made that impossible.
That password should be replaced with a link “show password” as I have seen somewhere. That way a wise root user (usually has no need to know email users’ passwords) don’t accidentally see those passwords.
So this complaint is not about the very basic design structure of webmin but simply a user interface issue.
I just realized that virtualmin shows the password of email users by default only in one of my virtual servers. Any reason for that? Actually in those virtualservers where email is enabled, I can’t even see the passwords. But on one another virtual server that is for subversion use only, the passwords are shown as default without any link “show password”. I don’t understand this policy.
Hey Matti,
3.46 will allow you to turn off displaying of passwords (3.45 is already in QC testing, to be released today).
I’m not sure why it would offer to display only for one virtual server and not others…that’s a little strange. Were the others imported rather than created from scratch? If so, they won’t have a password to display (because they were copied in already hashed). Also, if they were created in an older version of Virtualmin, the same will be true, as we didn’t start saving a working password until about a year ago.