Show Password in 15.x
Idea shared by David Young - April 12, 2016 at 8:49 AM
As the admin of numerous websites time is critical and spending time walking the bricks through setting up email is a huge waste of time. I can count on one hand the amount of them that can remember their passwords. Being able to show the password is a time saver for me. There is ZERO reasons to not allow the admin to see the passwords. If you are so fearful of this then they shouldn't be an admin. Making me suffer for some unfounded fear seems ludicrous. This same thinking is why companies don't allow employees to delete records in a database when in two lines of code any rouge employee can be stopped from doing anything bad.

Let's get back to some common sense programming here. Please return the show password feature. Of all the settings you have that's the one I prob care anything about since allows me to save time and do my job.


65 Replies

Reply to Thread
Andrea Rogers Replied
Employee Post
Hi David,
Thank you for your feedback. We did have an extensive discussion about this in the SmarterMail 15.x BETA category, which was removed from public view with the close of the BETAs. I'll paraphrase some of the conversation for you here.
Many have arguments similar to yours that 1) seeing the user's password makes troubleshooting far easier/faster than changing the password on multiple devices and 2) those managing a mail server should be trusted enough to have access to account passwords. Others made points that viewing a password is good for audits and being able to let a user know they need something more secure. 
I agree that our #1 problem with exploited accounts is because users use the same password for their SmarterMail email account as they use on other sites. We can do nothing but attempt to educate users to not use the same password on multiple sites, but removing the Show Password feature will make diagnosis of this problem (a simple password, or a common password character substitution) much more difficult. - Joe Wolf
It's common knowledge that management is permitted access to employees' business email accounts by law.  And as such, it could be considered reasonable that management and (by extension) email admins have access to passwords as well. - Paul Blank
Respectfully, you aren't on the receiving end handling a call where someone has a half dozen devices and no clue how to configure any of them. If a user has to arbitrarily change a password because they forgot it, this is going to exponentially increase the support burden of those who provide support. - Ben Conner
While I can agree these are valid concerns for adding this functionality back in, there are other views I'd ask you to consider. Like the views of some other users who disagree with its inclusion, proclaiming this functionality to be a huge security risk and a step back in today's emphasis on security: 
I'm shocked this feature ever existed. No password EVER should be exposed by anyone EVER.  This may be some convenience feature for some...but the only feature should be a reset password option... If any of my users knew this existed, they wouldn't use my system, they'd go to Gmail or something else. - Neal Culiner
...You cannot have an enterprise class product when admins can access a plain text password. Not only from the perspective that your admins or employees have it, but if you ever had a data breach the attack would have direct access to that too. Tim & team, thank you for removing this. It will be a slight pain in the rear to deal with, but processes can be adjusted. - Robbie Wright
Finally, some words from our CEO and VP on the matter:
When we develop our software we now must take into account signifiant and exhaustive third-party audits that companies are required to do. We must take into account compliancy tests and we also must take into account your insurance requirements and our insurance requirements.
The way to handle password management is by providing users a significant number of tools to retrieve passwords via Forgot Password, Secret Words, SMS, Alternate Email and more. Realize, no matter how many tools there are, you will need to create Business Rules that employees will follow to aid customers in setting up Alternate Emails, Phone Numbers etc.
Changing policies and procedures is far less damaging than a data breach. -Tim Uzzanti, CEO
As the industry moves toward security and the ability to lock down email servers and accounts, protecting the information of the users has become more important. While the ability to see a user’s password has been removed in 15.x, there are still options available for an administrator to troubleshoot or view a user’s account. In fact, the replacement to the ‘Show Password’ option, is the ability to create a temporary password that can be used to access the account. You can also still impersonate the user as a System Admin or manually change passwords as the domain administrator. - Derek Curtis, VP of Business
In closing, we do understand that the removal of the Show Password button may cause a change of policy for you. However, in this day and age, security is an absolute priority and will sometimes come at the expense of simplicity. Many new features in regards to security will be available in future versions. It is a process, and this is the first of many steps.

Andrea Rogers
Communications Specialist
SmarterTools Inc.
(877) 357-6278

I've already cracked the issue and solved my problem. I do appreciate the reach out though even though the solution took only about 15 minutes to resolve. The arguments from what I read that made up the decision came more based on a CYA then users input. Nothing wrong with that but a slight adjustment to the EULA handles that.

Thanks Andrea! Still happy I bought the application.
It 's true, the argument "show password" has technical and political aspects, positive and negative
Can you implement the sending of passwords to the customer via SMS mobile number (saved to mailbox account)?
Until mail itself is encrypted on the hard drive (which it's not) the removal of the "show password" function is simply security through obscurity.
Anyone with physical access to the server or via RDP can access all the data they want regardless of the password.
Next they'll remove mail archiving stating that one power user (the same and only user that could view a password) should not have access to every piece of mail on the server.
Go ask your compliance officer if one user being able to access all email on the server is compliant?
And before you respond "well you can disable archiving" tell me why we couldn't also just disable the viewing of passwords and leave that choice up to the administrator.
Lest we forget, the password for the administrator/master user can be reset by editing a single config file and restarting the service.
This decision is nothing more than security theatre.
I have to agree with David, BMark, and Brian.  This seems like it could have been (and still could be) a web.config setting.  For someone to change the web.config file they'd have to be logged into the hosting server - so at that point if it's a hacker having fun on the server you've got other issues.  Even make the default "off" to satisfy the auditing companies, but don't remove it altogether.
Luckily there is another way to get the passwords in plain text, and I'm sure it's the same way that David figured out.  I'm not going to say what it is for fear that it would be taken away too.  But it's easy enough to do that the decision to remove a "show password" button in the name of security is a myth at best.  We can still lookup a user's password in plain text - it just takes us 15 seconds to do now when it was 5 before.  10 seconds may not sound like a lot, but it adds up when you're doing it a few hundred times a month.
The other thing that's a little discouraging is that apparently there was an extensive discussion about this happening while 15.x was in BETA.  Perhaps the "show password" button isn't the biggest feature out there, but perhaps it was big enough to have the discussion in an area where people running production mail servers would be paying attention.  We don't have the luxury of time to be able to install a BETA product on a production mail server and then subsequently actively participate in a forum about it.  I understand that having BETA testers helps to ensure a better end-result product, but it seems unwise to use a BETA to test the REMOVAL of features.
Please reconsider your implementation of this.
It would be great if we could have the "Show Password" option back.  I have been using Smartermail since 2007 and I have gotten spoiled by its simplicity and the power it has provided me by enabling me to provide quick support to my customers.  I would even entertain the thought about having the  Primary Administrator with the ability to choose this as an option and having it set to off by default, thus resolving Smartertools concern for their insurance requirements.  This lets us be concerned about our insurance requirements instead of someone else making a choice for me.
At the core of this is who should determine what a program that we purchased should allow. This is a very robust program in general and certainly cost effective for what it can do. I can understand the reluctance to give certain powers to a person but we are talking admin here not run of the mill boobs without skills. If you are saying as Smartermail we don't want any litigation and removed it for that reason, as the rep from Smartermail posted, then please give us your clients some respect and say that. Don't try and play us by pretending to solicit opinion that is going to be dissed out of hand.

Its not hard to break the 'show password'. I will never reveal how I did it. Of course being a programmer for over 40 years helps, but there are certain things better left unsaid on an open forum.

I would simply prefer the feature to be replaced because the reason for removing it simply doesn't hold water.
We were aware that ST has removed the "show password" feature form the web interface before upgrading to v15. But what ST not said was that they also removed the opportunity to get the password though API.
Now we can't get the password anymore, we don't have them documented because we believed that the API function was still in place and usable.
What we want is a possibility to get them through API or tooling from command line (RDP). for decrypting the passwords.
If Smartertools is willing to reopen the discussion then I vote to put the "Show Password" back. If not then I guess it's time to look into other options.
Kendra Support
Junk Email filtered ISP
We have not updated to 15 yet due to this.
How does the temporary admin password work? Is it an additional password to let the admin login to the account and not lock the end user out? Or does it lock the end user out while it is in use?
I agree that Show Password is more of a security liability than it is a useful feature. For example, how would HIPAA, PCI, SAS, etc standards feel about viewing plain text passwords? I can't think of a single other system I use that allows passwords to be viewed in plain text. Passwords should be hashed using a strong method (like PBKDF2). If a user can't remember their password then they need to use a password manager which these days are very nice and the options are plentiful. Sorry folks, but this is 2016 and storing passwords in plain text, and more importantly allowing admins to view them with a click of a button (is there even an audit trail?) is 1990s-era security.

However, for the people with low-competency users there are some improvements that could be made. For example you could allow passwords reset links to be sent via SMS (using either SMS-to-Email gateways or pick an SMS provider like Twilio). This SMS feature could also be used for some sort of two-factor scheme.
Worst case you could support password hashing as an optional feature but I strongly agree that plain text passwords should not be the norm.
Question: In SM15 are the passwords still stored somewhere in plain text or are they hashed using a secure method?
It seems like this could be a global configuration option?  Those that don't want to see the passwords could set it one way, those that do could set it another way.
this is brutal... as a long time customer of smartermail I'm shocked it wouldnt have been in the release notes
New in this edition
-we made your life a pain in the !@#&^% by removing the ability to view your users passwords.
so now if someone wants a password we can reset... that really sucks when setups are often more complex than just a single client accessing a single account.
Please fix in the next release, this is a big deal to admins in their day to day duties.
The main problem of not seeing the password is when customers do not remember and call on time administrator.
If the password has to be changed every time, this time is a big problem because you have to reconfigure the client and any matching software. And this for the Administrator is a big waste of time.

The problem could be solved by simply integrating a system (protected) that sends in case of need the password via SMS to the customer's account number entered via webmail.
For maintenance / assistance okay temporary password and / or impersonation.
What do you think?
I posted this near the top but I think it got lost in the shuffle.  Why not offer two options... one that allows passwords to be seen and one that doesn't?  I don't see why this can't be done.
The Question now is will SmarterMail allow a Straight UP/DOWN vote on this?
Kendra Support
Junk Email filtered ISP
If there is concern about a global show password / hide password setting, how about making that a registry key that has to be manually changed by the server admin, or a checkbox during install that asks the user if they want passwords visible or not. 
If the "show password" setting was not exposed to the webmail interface or via the API, someone would need to have Windows Administrator credentials to the windows server in order to change these settings.  Seems like that should "C" everyone's "A" ?
The fact that a Smartermails rep has been noticeably absent since their first post speaks volumes.
That's really sad because I find that the people who I have interfaced with are genially good and honest people that seem to care about us.
Unf they don't make the decisions about these matters and the person that does has decided to place themselves above open discussion obv content to sit back and count their money.
Not that I am sure it will make any odds but I have to say having upgraded to 15, the show password was a function we used a lot, its now just a hassle. Whilst I apprecite this may have been done to align with some US laws SM need to bear in mind not all their clients are US based. Surely an option to turn that on and off would be a viable alternative.
As pointed out above, a sys admin or indeed the owner of the install can look at all the user emails anyway so if we wanted to hack an account we could do it now, not sure if this solves any loopholes??
As I started this with, not sure anyone will care or do anything but at least all of out thoughts and input on this are here in the forum.
We just need to keep the pressure on ST. Only then will there (perhaps) be a positive resolution to this issue.
I agree that the feature should be left in- passwords viewable. If you are concerned with a breach and that passwords would be accessed via an intruder, then encrypt the passwords and make a tool for exporting and decrypting the passwords by the admin. Other software manufacturers have this feature.
There could be a check box below the "Enable Password via API" checkbox.
Kendra Support
Junk Email filtered ISP
Does this blurb in the latest update mean this is now fixed?
"Fixed: Domain Administrators can no longer view or create temporary passwords for users."
I agree, this is the worst thing I've seen ST do.  I use the show password ALL the time when helping clients with password issues.  I also use it when an account has been compromised to look at the password and tell the client that.  Umm, 1234 isn't a very good password. Maybe we can try something else.  Like everyone else said, mail isn't encrypted on disk, in queue or anywhere else.  The only thing this does is keep admins from seeing a users password that they may, or may not have used elsewhere, and frankly, that's THIER problem if they've used the same password.  Don't burden US with it.
This has gotten VERY silly.  There should be BOTH options available and there are many ways to do this, including (maybe) the suggestion that the end-user has a checkbox in their settings, which allows the administrator to view their password.
This would be OFF by default - the end user would perhaps be reminded that this feature can be toggled at their will.
Again, there are great arguments on both sides of this; surely ST can come up with something that works for the "pro-show-password" crowd.