Show Password in 15.x
Idea shared by David Young - April 12, 2016 at 8:49 AM
Completed
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.

 

218 Replies

Reply to Thread
1
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

www.smartertools.com

3
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.
6
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)?
5
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.
5
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.
 
6
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.
0
Shaun,

I was under the impression that the SmarterMail account passwords were now Salted & Hashed, in which case it simply wouldn't be possible to Show Password any longer. I was okay with Show Password being removed under this assumption as all Web Apps should have passwords Salted & Hashed. End of story, no exemptions, no excuses, and no apologies.

However, it sounds like from your explanation that such is not the case, and they are either still stored in plain-text or are encrypted with an algorithm that allows them to be easily decrypted, being neither Hashed or Salted. If that is the case then this is discouraging as this still leaves the account passwords highly vulnerable.

Unlike some, I am okay with the Temporary Password, Reset Password, and the automated Forgot Password function, but I am certainly not okay with account passwords still being stored in plain-text (or being able to be decrypted) in SmarterMail. I feel that if they are genuinely concerned about security that they wouldn't do it by being obscure but would rather do it properly; by Hashing, Salting (& Padding to avoid the Bicycle vulnerability) all account passwords.
3
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.
0
I think you've carefully skipped over a lot of the arguments for leaving this in - basically, your position has been "this is what we are doing, live with it" There was no discussion at all with your customers as far as I can tell, but some of use from both sides of the argument debated which would be better.

And this move can decrease security because users can and will make their passwords easier and easier to remember to avoid the huge pain involved (for non technical users) to reconfigure all their devices.
1
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.
0
Hi:

I really regret upgrading to v.15. Show password was a very important feature for us and saved us a lot of time. Now, we are spending extra time to fix passwords for the clients which is making us all very unhappy.

Please put that feature back...

Yousuf
0
Release notes:
Added: System administrators can now create temporary passwords for user accounts to troubleshoot issues. The actual user’s passwords can no longer be displayed in webmail while managing a domain.
0
GetUser API should still return password as string, but string is empty when query to the API.
0
Matt Petty Replied
Employee Post
This is probably why you can't see the password via API.
https://gyazo.com/a901a3dd2f06ab6baee4ba6053f33bdb.png
Matt Petty
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Hi,

Are you doing this via the API? It is no secret that the API currently works to display the password.

We were told this would still function in the beta forum, until SmarterTools changes the encryption so it is not reversible.

-dave
0
Hi Brian,

My point exactly, ST has said this is a baby step leading up to changes in the encryption. I tried to get them to hold this off one version, it makes more sense with a complete interface change to implement this, and maybe by then they can change the encryption.

Since you can lookup a password via the API still, that means nothing has changed internally.

-dave
0
Matt Petty Replied
Employee Post
We actually implemented a feature to disallow certain admins from being able to access passwords via the API. This is in no way a hidden feature, https://gyazo.com/a901a3dd2f06ab6baee4ba6053f33bdb.png
Matt Petty
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
No I am not. How I'm doing it is a trade secret.. I respect Smartertools and what they have in their product and releasing how I'm doing that is simply not fair to them. I would prefer them to revisit this and seriously think about the comments their clients are posting on this thread. It appears that in whole the consensus is to return the show password feature. Do that and then have a serious discussion on encryption that can satisfy all people concerned.

If I or you were nothing more then a casual user I could understand their position. Since the people posting on just this thread are not just casual users, more weight should be given to our views since many of us have to support numerous end users.

Its illogical not to seriously consider what we have to say and utilize the years of exp many of us have in IT.
7
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
http://www.kendra.com
support@kendra.com
425-397-7911
Junk Email filtered ISP
2
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?
0
Matt Petty Replied
Employee Post
It's an additional password that can be used to access an account. It won't affect the original password or its use, it just "sits beside" it.
Matt Petty
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
I understand both sides, if possible made it optional, we have more work now but i must agree that admins shouldn't have access to private password. (since a great part of user use the same password in different services)
We always hide to our clients that we have password access, must of then wouldn't accept if they know that we have access to password. My technicians complain a bit but they understand that this is the right way of doing host.
0
Hi, We have been customers of Smartertools since 2005. Version 15 has many nice features, but we are not going to upgrade because of the password feature. Our tech support staff spends hours each day answering calls from clients who have forgotten their passwords. If each call resulted in re-setting up phones, computers, and tablets, we are probably tripling our tech support time.

Passwords are a security disaster. Google, Apple, and others are trying to come up with an alternative, and we will probably see a new solution in the next year or two. Eliminating the password feature for sysadmins is an unnecessary tech burden. If the question is one of liability, we are already liable for their websites and email accounts. Making tech support more difficult for sysadmins is not a solution.
3
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?
3
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.
0
Note, my question is if the passwords are hashed, not if they are encrypted. They should also be hashed using something like bcrypt so that even if the file they are stored in is compromised it would not be feasible to crack them given a decently long password. If they are only encrypted that doesn't help because the encryption key is easy to find.
0
Why is there only one answer? Why can't you offer a Show Password feature to those sysadmins that want it... and the ones that do not want it can have it disabled? There are strong feelings on both sides of the issue... this would satisfy everyone. Make it optional.
4
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.
 
-Tim
0
It actually was in the release notes for 15.0.5932

Added: System administrators can now create temporary passwords for user accounts to troubleshoot issues. The actual user’s passwords can no longer be displayed in webmail while managing a domain
3
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?
9
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.
0
I agree 100%a
0
Not everybody has SMS, so while that might help it won't work for everyone. Plus it would require an SMS gateway like Twilio which has a cost that somebody would have to pay for. I think end-user self-help password retrieval via SMS is a good option to have, but somewhat unrelated to this thread.