Win Thu Aung, I can see the validity of your concern about showing a user's password to system administrator.  I understand that many people use the same password for multiple sites (including banking, etc.), which is a security risk itself. Regardless, one reason it's shown is for troubleshooting purposes, for example, with Outlook or another client. One option that we are considering (and we would love user inputs/concerns), would be to give a system admin the ability to generate a temp, time-sensitive password for a user for troubleshooting purposes.

 

There is no way to prevent a mailing server system administrator from not being able to view a user's email--this is part of their primary responsibilities.  A system admin is able to impersonate a user or even access a user's physical email folders and files on the server.  That is an expected function of a system admin.

 

With a temp, time-sensitive password the system admin would not be able to learn the user's password (at least not easily) which would bring some peace of mind to your customers.

 

EDIT: Passwords are saved on the server in an encrypted format.

Why not just remove the Show Password option, and leave the Impersonate option?  I've never really understood the need for Show Password.  It's easy enough to reset the password for a user if they forget.

Win Thu Aung, I completely agree with you. There is ZERO reason for an administrator to be able to see someone's password. They should have the ability to reset only, NEVER view. 

 

Based on this post (www.gironsec.com/blog/2012/08/cracking-smartermail-hashes/) it seems that the "encryption" is nothing more than a basic, incorrectly implemented Base64 encoding.

 

This is #6 on the OWASP list of application security flaws.

 

Robert, There should be an option in the software to allow it be insecure (the current config), or secure (salting and hashing passwords). I have been administering email servers for 10 years and NOT ONCE had the need to know a users password. If they didn't know it, they got directed to the control panel to reset it.

 

No need to change this in my opinion. Rather spend time making it easy and turnkey to force HTTPS access for all connections to webmail. This way we can be confident that the connection is encrypted whenever calling or viewing this information.

I kinda like the feature of being able to view a user's password.  Yes it is a degree of insecurity, but if the client doesn't complain, so be it, and it is simple to retrieve and present a user with their password in a pinch.

 

I can see where it would be an issue in certain circumstances (legal, medical [HIPAA], government) - and there should perhaps be an installation option to disable password retrieval per domain.  But then, the administrator could still login to user accounts by "Impersonating", so what to do then?

 

As I've already said, I'm content as it is for the time being.

 

 

.

 

 

 

 

The owness to vet who has access to e-mail content is further mandated by the recent FTC ruling [see: http://www.govinfosecurity.com/court-affirms-ftc-authority-on-cybersecurity-issues-a-8499] which clearly places the security of data on both the corporation and the service provider, giving the Justice Department complete authority over enforcing that privacy.

Note that the final provisions of the HITECH portion of HIPAA also prohibit any e-mail or data being stored outside of the United States.  The final HITECH provision also prohibits anyone by US EMPLOYEES from working with patient data, and requires a signed, letter of agency, from EACH employee of any agency or contractor who handles such data.  Those employees are also require to participate in mandatory in-services for the company for which they provide the service: TWICE A YEAR.

In the case of patient data and/or communications, access is non a need-to-know basis only.

In summary: It's not just about blocking the ability of e-mail operators and admins to see passwords, or whether e-mail administrators should have access to data, but the fact that such access is now both tempered, and regulated, by law; and, whether we are a corporation providing e-mail for our employees, or a provider, who makes e-mail available as a service, we are mandated to properly train those who have access to the systems which house those services with regard to what they are allowed, and not allowed, to do.