Back to Community Threads
12
Show Password in 15.x
Idea shared by David Young - 4/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
Employee Replied
4/14/2016 at 2:07 PM
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.
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
4/20/2016 at 8:12 AM
Employee Post
This is probably why you can't see the password via API.
https://gyazo.com/a901a3dd2f06ab6baee4ba6053f33bdb.png
Matt Petty Senior Software Developer SmarterTools Inc. 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
4/20/2016 at 10:29 AM
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 Senior Software Developer SmarterTools Inc. 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
4/21/2016 at 8:08 AM
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 Senior Software Developer SmarterTools Inc. 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.
0
Hi Shaun Peet, a system that connects to an SMS gateway (clickatell, Twilio, etc ...) is very simple, the sending cost is low (0,015 $), many software that use password using this method.
Which user does not have a smartphone / phone?
This method is much used, even for access to Internet banking, because it is not related?
0
bmark,
I don't have or have found I need a Smartphone. In the office I have a phone, on the road I wont use it, When I'm at a customers they pay me to work on there computer not to talk on the phone.
Kendra Support http://www.kendra.com support@kendra.com 425-397-7911 Junk Email filtered ISP
1
The Question now is will SmarterMail allow a Straight UP/DOWN vote on this?
Kendra Support http://www.kendra.com support@kendra.com 425-397-7911 Junk Email filtered ISP
0
Hi Leyda Matthew, I'm sorry, but the SMS you have to use only in case of need when the client does not remember your password and do not want to reconfigure the clients, otherwise there is no need it... You must not be on the phone.
0
sorry, my bad.

It says the passwords can no longer be displayed in webmail... is there another location where I could retrieve the users password?
0
While *most* people will have a phone, not *all* will. The "show password" button provided the option for an admin to provide help for *all* users. So my point was that while SMS password retrieval would be a good feature to have, it's not a suitable replacement for the "show password" button - which is the topic of this thread.

And while sending an individual SMS message is cheap the fact is that it's not free, which again the "show password" button was. So if a lot of people start requesting passwords via SMS it will add up and somebody has to pay for that.
0
Probably not. Only if there's a noticeable reduction in license renewals would they reconsider. It's really too bad because SM15 has a whole bunch of other really great new features / tools. We've got a work-around for the lack of "show password" button but as I mentioned earlier in the thread it takes us about 5X longer to do so.
0
Shaun Peet,
you're right, this is true, unfortunately, sending SMS is a cost, however is a solution to have flexibility for administrators (assistance) and security for the password.
I think that "customer password" should be private, the administrator needs to know only in the case of technical assistance (if there are no other ways) .
0
Tim - the API is still returning passwords (as mentioned by others in this thread)

But to your point about the transparency of this change, that's something I've been very disappointed about (and also mentioned earlier). SmarterTools is stating that there was a very lively and active discussion about this feature while SM15 was in BETA - implying that we had a chance to chime in then and didn't so too bad,, so sad. It's just hard for people with limited time / resources to test out every BETA product (in production, mind you) and actively participate in a forum. I wonder what percentage of the SM customer base actively participates in the BETAs. They've got TWO major releases this year of SM and ST (and SS?) - I was planning to take a closer look at the second round since those are major changes and I'm wondering how many others were doing the same.
0
One idea would be to integrate a button "send SMS password" to the phone number of the customer, instead of the button "Show password."
In this way it is the Administrator who provides support and may also charge a fee for technical assistance (recovery password). But without creating a new password that could create many complications for email clients, software, etc ..
0
Well we can agree to disagree then - although I mostly agree with you so I'm not sure why we're arguing.

My point, again, is that if the SMS option doesn't work for *everyone* then it cannot be a replacement for the "show password" button - even if the SMS option is a very good thing to have (which I think it is, and I'm agreeing with you).

But my other point, as is echoed by many others on this thread, is that WE bought software with certain features available and to have a feature removed because of philosophical arguments - which not everyone agrees with - is a dangerous position to take. What if SmarterTools suddenly starts taking other political / religious views that are implemented in the products with NO configurable options for the customer base (us)?

The decision to remove the "show password" button and rationale for doing so is an entirely philosophical argument. It may have been imposed on SmarterTools (remember, they offer hosted services) by insurance / auditing companies, but not every SM installation is subject to those same restraints. My company is run by grown-ass adults who understand the implications of having plain text passwords available to administrators, and in our view the ease of use in being able to do so offsets the potential risks for our particular customer base. We don't want, and frankly don't appreciate, our chosen software vendors making those decisions for us.

The only appropriate fix to this particular problem is to make a web.config setting available to re-enable the "show password" button. Then also, add SMS retrieval as another useful option for anyone who wants to enable it, but don't require it.
0
I went thru this with Imail about 10-15 Years ago and instead of the heavy handed decisions I changed to SmarterMail. I'm thinking it may be time to move on if I can find a company who listens to all their customers.
Kendra Support http://www.kendra.com support@kendra.com 425-397-7911 Junk Email filtered ISP
0
Shaun Peet, Yes sure,
if there was the possibility to choose the feature "show password" on the System Configuration level would be the best choice, and "send SMS password" as an additional service.
Mine was a proposal to solve the problem by accepting both positions (security policy/privacy <> easy admin management) in the event that SM is not going to restore "show password" in any way.
We are in the comunity to discuss this I think, However, the final decision is up to SM.
0
@Andrea - I know this thread has been marked "Declined" but it might be a good idea for you or somebody at SmarterTools to read this thread and make some sort of comment.
0
Because Dave that would create a fork of having to support two programs. Even I wouldn't agree with that.
0
actually people were complaining in the beta thread and were told "too bad, so sad" anyway - there was no discussion, just a "this is how it is".
0
why would that be the case? Have an option in the main configuration file and have the program react accordingly.
0
If your going to create an option for 'show password' button and an admin can select that to allow to see the button then you might as well just put the 'show password' button back. So the only way to do it and satisfy anyone who has compliance issues would be to either have a version that has the button in it or one that doesn't and that creates the fork.
0
Smarterstats, smartertrack, smartermail with passwords, smartermail without passwords. It's just an additional product for Smartertools.
0
Since Smartermail already has roles built in why not allow the top level admin be able to see the password and the domain admin not have that feature.

Can a Smartermail employee access the passwords? Yes they can. They know the algorithm or hash and since we the end user don't really know what Smartermail is doing, i.e. sending all the information to themselves anyway isn't that just a big security breach in itself.

So what they're saying is you can trust us, Smartermail, but not who you designate as your admin.

Seems kind of strange when you are saying we are worried about being sued so we are removing this feature. Yet who's policing the police?
3
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" ?
0
This could be an installation option/registry key rather then a product fork.
0
Up until Version 15 only System Administrator's could see the Passwords. Users and Domain Admins could not see them. I guess System Admins cant be trusted anymore.
Kendra Support http://www.kendra.com support@kendra.com 425-397-7911 Junk Email filtered ISP
3
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.
5
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.
4
We just need to keep the pressure on ST. Only then will there (perhaps) be a positive resolution to this issue.
2
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.
1
There could be a check box below the "Enable Password via API" checkbox.
 
Kendra Support http://www.kendra.com support@kendra.com 425-397-7911 Junk Email filtered ISP
0
How would HIPAA, PCI, SAS, etc standards feel about a system administrator having access to plain text email they are not authorized to view via RDP or the archive feature?

Archiving is still a feature and email is still plain text on the disk so how does removing the password tool make the software any more compliant?
0
Viewing archived email is certainly a concern. However, when passwords are not stored in hashed form securely they are a security risk. They could be exposed via a vulnerability of some sort and then the email could be accessed remotely without RDP or admin credentials and it would likely never be noticed. Also the archive feature is optional and it would be possible to move the archive to another system to prevent admins from viewing it so its existence does not negate the need for password security.

My main point is that passwords should not be stored in plain text, whether or not the admin can view them. They should only be stored in a secure hashed form. The current implementation breaks a lot of security rules.
0
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."
0
Employee Replied
5/13/2016 at 8:05 AM
Employee Post
Hey Jim. It does not. This references a bug which allowed Domain Administrators to create temporary passwords for users. (Temporary passwords is what took the place of the Show Password feature.) Only System Administrators should have this ability.
0
Matt Petty Replied
5/13/2016 at 8:05 AM
Employee Post
No, only system administrators can create or view temporary passwords. This doesn't relate to seeing actual users passwords. Domain administrators having this level of access was not intended and we removed it.
Matt Petty Senior Software Developer SmarterTools Inc. www.smartertools.com
4
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.
4
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.
 
 
3
Well I guess ST has grown enough to start ignoring their clients....
0
Hmm, looking at your screenshot I can see I'm missing configuration tutorials and system administrators from my control panel. Instead I've got Administrator settings where I can only change the password. Does this mean I'm not using the master admin account?
0
Sean,
Sounds like you are logged in as a Domain Admin. Only the System Admin has access to the "Show Password". That's why the argument over showing the password is kind of bogus. I have lots of Domain admins for the domains I host and they don't have access to it. I only have 2 System admins that do has access to Show Password, Impersonate and other options.
Kendra Support http://www.kendra.com support@kendra.com 425-397-7911 Junk Email filtered ISP
0
Summers coming, The crickets are coming out to sing their song.
Kendra Support http://www.kendra.com support@kendra.com 425-397-7911 Junk Email filtered ISP
0
Matthew,
Thanks, it was certainly that. I was logged in as secondary system admin rather than the main admin. :)

Sean
1
In the end this decision was made by money and liability. If you read the CEO's comments its all about what would happen if they got sued, it wont change and it sucks and has me exploring other options.
1
How about a $5.00 option that enables the feature? This would make him some Starbucks Money and get him of the hook with the legal people since we paid for the Option.
Kendra Support http://www.kendra.com support@kendra.com 425-397-7911 Junk Email filtered ISP
0
I have to agree with a previous comment... if some users knew we are able to see their super secret password, they would freak and run screaming.  Too Big Brother.  We know enough about them, we don't need that aggravation.  And I don't need the major headache when someone finally hacks our database and gets all those passwords.
 
7
I'd like to see a link to the thread that was started about this during the BETA process. I find it hard to believe that it comes anywhere close to the amount of posts this has gotten.

Seems to me that since Smartermail is an ongoing product with releases coming fast and furious that opening this back up seems prudent.
 
It won't happen because I'll challenge the person from Smartertools that at least came by once to reply to return and offer up some answers to the numerous posts this has gotten.
 
Nobody in here has gotten out of line that you need to be scared. Come in and address our concerns and stop ignoring your job.
4
I'm afraid that's not a great answer, Connie.  The SM datastore remains INSECURE.  If anyone can access the SM domain files and folders on the SM server, they will have access to ALL EMAIL AND DATA STORED THERE. Really makes no difference if the passwords are secure or not. Sorry to burst your bubble there.  BTW many email admins think this is a FEATURE rather than a bug, because it's relatively simple for the (hopefully honest) SM admin to recover email, whatever the reason.  And many of us have our employer's / client's permission to have this access.  I, for one, have discussed this with my clients who use SM, and they are fully aware.
0
If your the Admin then a certain amount of trust is assumed. The ONLY reason I ever go into a site for the password is to give it to the boob who can't rem it. If I can't get it, and sometimes my hack doesn't work, then I just change it to something else. So explain to me how I benefit from seeing a password that the person who should know it... doesn't?

The problem then is after I change it now I get to waste an hour walking the same boob through how to find where on their computer they can change it to the new one.

If everyone used webmail this wouldn't be an issue but the majority of my clients don't.
6
So here's the scenario.  Mrs. Client calls up because she forgot her email password.  She wants to log into the webmail.  We re-set the password, breaking her phone and computer, but now she can get into webmail.  Then she calls back because she is getting an error message on her phone.  We change the password so that we can set it up on her phone.  Then she calls back because she is now getting an error message on her computer.  We change the password on her computer, and now her phone breaks again. 
 
After a couple of games of whack-a-mole, she changes hosting companies, and goes to one that has email that works.  Ours obviously doesn't work because she keeps getting error messages, and despite how nice our tech support people are on the phone, she doesn't want to spend her days constantly re-setting her passwords.  It's easier to go to a different hosting company that doesn't use Smartermail, and avoid all of this headache.  So we lose a client after spending hours in tech support.
7
You retain clients with support you don't make money from it.
 
Smartermail you really have opened a can of worms with this. Isn't it time you really addressed this and stop dodging the issue.
0
And here's the "best" part: when you change her password for her, you again KNOW the password.
5
... It would be great if we could have the "Show Password" option back.
It's a very annoying new feature for admin.
I understand that you did it for security reasons.
But you should find a way to restore somehow this usefull feature.
7
Up to this! We want "show password" back!!
0
You shouldn't be changing her password. You should be sending her a link so that she can change the password. It's called security.
0
And if you make this product less secure, we will dump it in a heartbeat and purchase something that is secure.
3
Folks, I think its time to give up on this thread.
 
It is pretty clear that most of the people commenting on this post (SmarterMail included) are either strongly for, or strongly against allowing admins to view passwords.  There are compelling arguments on both sides of the fence, but at this point I think its safe to say that it is very unlikely that very many people are willing to be swayed from one side to the other.
 
What we have here is essentially a junior varsity version of the Apple vs Microsoft argument. Those with differing opinions simply have different business needs, it doesn't make one side right or the other side wrong.  It just is what it is.
 
One thing I would encourage SmarterMail to consider is some type of mechanism to poll the customers with active support plans for their input on these type of significant changes in the future.  Many of us don't have time to experiment with running Beta software on a production (or non-production) server so many SmarterMail admins were taken by surprise on this one.  It is great that SmarterMail got feedback from the Beta team, but as others in this thread have mentioned - that's probably a relatively small percentage of the total (paying) SmarterMail installations.
 
Its also possible that this argument have been shut down several weeks ago, simply by showing that the majority of the (paying) customer base voted in favor of the change.
 
Just my 2 cents, spend it how you will. :)
0
Would this link, perhaps, be sent to their SM account, to which they have lost the password? Thinking about this, the admin would assign them a temporary password, and they'd want to change it as soon as they get in. So yes, the admin would have the password for a few minutes. But, as stated before, the admin still has full access to the account if they have admin rights to the SM files on the server, no matter if they have the user's password or not. *sigh*
0
SM requires a backup email address so the reset email would go there.
0
It's not about preventing access to the mail store, although the users thinks it makes it secure. It's all about you knowing what is probably the same password they use at their bank, on Amazon, on eBay, etc. You can now rock their world since you know the password they use everywhere else.
0
I wouldn't know. I am not going to deploy v15 until all (or most of) the pervasive email sync issues and calendar delay issues that have been reported are solved. I have certainly lost clients because of these problems.

My biggest SM client is on V11, with few (and generally far-between) issues that we don't work-around easily. Another couple of clients are on (open-source!) hmailserver+squrrelmail, and those are pretty-much set-and-forget. It's not uncommon that the hmail+squirrelmail server goes untouched for 6 months or more, except for backups and Windows updates. I understand that hmail+squirrelmail are JUST email programs, but it would be nice to have those few maintenance issues as a goal.
0
I agree - put this feature back! 80% of our calls are password related. Just had a customer call with a new phone needing help with email setup on device. Of course, doesn't remember his PW. So had to reset it, which resulted in an additional 25 minutes of time to walk him thru changing this on his Desktop, laptop and tablet. multiply that by 10 calls a day, and productivity just sank to the bottom
7
This is the single most tone deaf choice that SmarterTools has ever made.   As an administrator of 4 different SmarterMail servers, I can tell you that the single most used feature in troubleshooting is knowing the person's password.  This change would likely double the time spent on handling support issues.  Sure, removing the ability to decode passwords makes the passwords themselves more secure, but so would building a dome over my house in order to protect from trees falling on it, but do we all really need domes on our houses?  Is it worth it?  What known issue has this solved?  I'm not working for the damn NSA, I'm just a guy that offers email services.  Clearly it creates big issues for everyone who runs your software.

I just quickly backed out of an install of v15 because of this and will not update any of these servers until this feature is re-enabled.  Absolutely tone deaf folks.  This is a serious failure to understand your customers and their real needs.
0
I think not! The view password option is a must for administrators that support many customers, because customers want a way to know their forgotten password without change it.
The recovery mail is not a valid option because many client doesn't have a secondary mail.

A suggestion: make the recovery password e-mail editable in the users settings by administrators
This way the admin can make His mail the standard mail for recovery customers password.
0
A proposal: make parameter "e-mail for password recovery" editable in the users settings by administrators AND usable in "User Defaults" and "User Propagation".

This way an admin can make his own mail address the standard mail for recovery customers password.
 
Obviously, the recovery message must contain a way to view current password. 
3
I built an APP to find the password for a specific user using web services.  I needed to reduce my support time and the APP was the answer for me.  I think SMS would be a great idea for users to retrieve their own password in the future.
0
Is your APP available for us?
0
MailEnable adn mDaemon have that tool...
0
Id like to try it.
Kendra Support http://www.kendra.com support@kendra.com 425-397-7911 Junk Email filtered ISP
0
I'm actually in favor of the view password option too Gabriele, but as I mentioned in my post above, there's just as many people on the other side of the fence.
0
Yes, but it's clear that this could also be an option that you can enable or disable.
0
Agreed.

Unfortunately, that idea (and many others) have been proposed since SM 15 came out, but unfortunately SM has not made any further comments in this thread since they marked the feature request as "declined" over a month and a half ago.

I think that makes SM's stance on this topic pretty clear. We are just arguing with ourselves at this point.
2
I would find it a good solution when the primary admin can manage the show-password and impersonate functionality for sub-admins the same way he can already manage IP-restrictions for certain sub-admins.
 
Or - to make it more granular - to disable the show password and impersonate function for selected domains. 
 
So for example you can deny most support people to show passwords in clear text and at the same way allow special persons or the API-user to retrieve the passwords. (BTW: the API can still read the passwords also in v15)
But when show-password is disabled for a specific domain then it should be 100% impossible for whatever user to show the current password. 
0
Same here, and thanks in advance.
0
This only mystifies me even more as to why they took this out of the interface. Since passwords are still available after jumping through some hoops or by using a third-party product, all they have really done is plug a hole where an administrator account being hacked could expose these things through the web interface. There are so many other effective ways to lock administrator accounts down such as 2 factor authentication where you authorize a web browser after clicking on a link in email, and that protects all sorts of other things as well, not just existing passwords. What they did is just plain stupid and poorly thought out. It solves an almost non-existent problem in a way that greatly increases support costs for administrators.
4
So here's my proposal to enhance security with very little complication for administrators and no loss of functionality:

Add 2 factor authentication for administrators on the first login from a web browser just like banks and credit card companies do and put the damn passwords back.

The first time an administrator logs in, send them an email with a link to click on which sets a cookie in their web browser so that on future visits only single factor authentication is necessary.  This protects the entire SmarterMail system admin interface from unauthorized access and would therefore be more beneficial overall for security purposes, and at the same time there would be no loss of functionality.
0
We were told this was not possible via the web services.
0
it is possible and I am doing it with version 15 as long as smarter tools keeps this functionality in web services. I really never planned to make the APP public and I would need to compile it with a static service address for each server that needs to use which would keep it one app per server. Bottom line, I really cant just give it out.
0
if you provide an email address to me I will email just you 4 (Gabriele, Matt, Paul, Connie) the app compiled to your server and you can have it.
2
You can add more security to the show password function adding an automatic e-mail advise to the user every time the password is viewed (both to SM account and Recovery e-mail address if present)
0
Employee Replied
7/1/2016 at 9:50 AM
Employee Post
Hey guys, I'm glad you're able to find a workaround solution for this. However, I do want to make you aware: while this will work for the time being, as we transition our back-end with the same mindset as our front-end solutions, this functionality will eventually be removed.
0
What thrilling news.
0
Employee Replied
7/1/2016 at 11:20 AM
Employee Post
Sorry Paul, I know this isn't welcomed news. I just wanted to make sure you guys were aware...
0
How long can we expect this to function?
0
I'm taking bets that V16 will kill if for good. It made up my mind. My service Agreement expires in 2 Weeks and I'm not going to renew it.
Kendra Support http://www.kendra.com support@kendra.com 425-397-7911 Junk Email filtered ISP
0
100% true !!!
0
PLEASE DO NOT REMOVE THAT FUNCTION!!!! It's a MUST HAVE for Service Provider Administrators!!!!
2
PLEASE DO NOT REMOVE RETRIEVE PASSWORD BY APIs FUNCTION!!!! It's a MUST HAVE for Service Provider Administrators!!!!
3
This has created a ton of work for myself, and my clients are peeved, make this option an optional setting that we can decide if we want password encrypted or not, at least allow us the choice to select this, I understand there are companies that have to have it encrypted, good and fine, enable this option for yourselves, if we don't want it encrypted then let us choose the option the responsibility is on us.
 
The joke of it all is you can impersonate any account on the server without a password, so what the heck is the fuss all about having to encrypt the passwords, if an admin wanted to abuse/hack the account, they could easily change the password do what they want with it, and change it to something else, then when the person cant access his account they reset it and it works none the wiser..  so put it back and let us decide.
0
That's not what this is about! The issue is, if you know my email password, you now possibly know my password for my bank account, my credit card account, my eBay account, my Netflix account and any other account I as a dumb/lazy user chose to use this same password for. THAT is the issue here. Second to that is, I may trust you as my email administrator, however I DO NOT trust the rogue employee or hacker who at some point in time WILL hack your system and WILL steal all of those clear text passwords that I can now match up with the email address you had to use as your username on all of the above mentioned accounts. Ask any security expert and they will tell you, it's not IF they steal your database but WHEN. DO NOT make it easy for them to use that stolen data.
0
Connie, what you are saying may be true, but it is not a great reason to automatically remove this capability from SmarterMail. For example, a disreputable person with SM admin privileges can try to request a new password for any SM user from a bank, then impersonate the user, reset the password, and possibly access that user's bank account before the user knows what's happening. So removing this capability is not any kind of magic bullet.

To be sure, we as admins need to (try and) educate those "dumb/lazy" users of the importance of using different passwords for sensitive accounts!!
0
THIS is one very good solution, combined with the ability to shut this capability completely OFF per domain at the behest of management.

The automatic advisory to the user might also STRONGLY suggest that they use different passwords for different accounts.
5
Well almost 4 months later and the only reply from SmarterTools on this subject is from Andrea a few days ago (buried in a comment, no less) mentioning that they're planning to kill the web services API work-around that we're using.  I would have figured Tim Uzzanti would have commented at some point but the blinders are fully on.
 
We've been loyal SmarterTools customers for over 10 years now - we use SmarterMail, SmarterStats, and SmarterTrack and pay thousands each year to keep them all renewed.  A few thousand bucks is probably a drop in the bucket to SmarterTools, but to us it's still a pretty large investment.  Over the past 10 years we're talking at least $25,000.
 
And now we're at the point like many others have already said.  It's time for us to start looking for alternatives, and even if they end up costing us more I'd trade that in heartbeat for a service provider who's at least willing to engage their customers in a meaningful discussion.
 
When Mandrill / MailChimp did their "improvements" last year it would have cost us about 500% more to keep using their service.  Alternatives were still costlier than that, but the narrow-minded nature of what MailChimp did, and the short window of notice, meant that there was no way we'd ever do business with them again.  Every other provider in the email-as-a-service space welcomed former Mandrill customers with open arms.
 
So I think it would be good to have a discussion here, right on SmarterTools' own support community forums, about what alternatives exist for each of their products.  Given the amount of involvement by SmaterTools on this thread, I don't think any of them will ever notice all the free advertising being done for their competition.
 
Shame.
 
So - who's got suggestions for SmarterMail alternatives?  What about SmarterTrack and SmarterStats?
 
We currently use both SmarterStats and Clicky for traffic analysis.  So dropping SmarterStats is probably easy enough.  I'm thinking maybe InstantKB as a replacement for SmarterTrack - anybody have any experience with that?
 
 
0
One thing to keep in mind that once API access to the password field is taken away, that's going to make scripted migrations to another platform much more difficult. So if you are thinking about switching, you might hold off on installing the upcoming update that breaks the API.
0
Andrea, please NOTE (and FORWARD internally!) that many of your customers here are relying on reliable services. Completely removing something still used from many customers is the opposite of reliability.
Have we to expect that also other functionality will be simply removed even if your customers state that they will need it?
Why not remove support for this old dumb risky unencrypted smtp and pop3? common!
My suggestion to give the choice for invisible or retrievable passwords in the hand of each administrator seems not to be considered. Too bad as it would give us the same granularity like the "control of service access" for each domain and user. Customers/Admins who really want highest security then should have the knowledge that their password are stored absolutely nowhere. (means hash+salt and nothing else)
I wonder why Smartertools not considers necessary to satisfy requirements of such a notable customer group.
0
As a side note, we migrated to SmarterMail from a competing product years ago for similar reasons.

When we originally started using that product, it was a great fit for ISPs that host their own mail. We never thought we would ever move to another product.

However, as time went on - the product shifted focus towards a corporate audience. The development features and design decisions made that increasingly apparent as the original customer base of ISPs eventually got left behind.

We sincerely hope this is not the shape of things to come for SmarterMail.
0
We came from Imail to SM Version4 years ago. Now we are looking at going back. At that time price was a issue, now its less of a issue, passwords is the nail in the coffin for us. Pay up front for support (if they like you and say its a bug you get it back), Outlook support, IMAP problems and the list of things that don't seem to get fixed.
Kendra Support http://www.kendra.com support@kendra.com 425-397-7911 Junk Email filtered ISP
0
Matt Petty Replied
7/5/2016 at 12:00 PM
Employee Post
I just checked, we don't plan on removing any API's for SmarterMail 16. We may mark them as deprecated and move them out of the project in a later major version.
Matt Petty Senior Software Developer SmarterTools Inc. www.smartertools.com
0
@Matt - You and Andrea need to get on the same page with your messaging. Her comment from July 1 at 12:50 PM did little else then to fan the flames of this thread, and it appears you're trying to douse the fire. What really needs to happen is an official comment from Tim explaining why so many people on this thread (ie your CUSTOMERS) are wrong, and whether or not your company's decision is being reconsidered given the large amount of feedback here. I, and many others, need to make business decisions for the future and believe it or not, this is causing so much extra work for us that it's a deal-breaker. Even if no other hosted email software provides a feature to easily lookup a password, we're so upset with this lack of official response from SmarterTools that we're ready to take our business elsewhere.
0
I agree with Shaun. This is insane. I've been a SM user since 2008, and have paid for the enterprise version and upgrade protection every year since. Ability to see the password is very important. Users call in, they can't remember the password, they get irtated when we say, "I'm sorry, we can't see your password, we're going to have to reset it". Why? BECAUSE THAT MEANS THEY HAVE TO RESET IT ON EVERY DEVICE THEY USE TO CHECK EMAIL WITH. Like everyone else, we advise the client to use different passwords as it's not recommended to use the same one with other accounts.
7
I wish to add my voice to those who are against this poorly thought out change. We host mail for several community associations and the age of the average user in some of these places is 70+. Many people have come to computing at a very late stage, and need serious hand-holding and constant support. Taking away our ability to see passwords has had a serious impact on our support team and to the quality of the service we can provide to our customers.
 
I support the idea of making this a configuration option, OR putting 2 factor authentication onto admin level logins. Please put the passwords back and allow server admins to decide whether or not they want the added security.
1
For those of us who must pass security audits, we DO NOT want clear text passwords anywhere.
 
0
I think everyone supports the option of disabling/enabling this by way of a config file change or other method, but passwords are not stored in clear text, rather they are reversed on demand. Their method of encrypting passwords is in fact easily reversed regardless of what they did with their interface, in fact one security guy has released a tool that will reverse these. Their weak encryption of passwords allows for things like easily copying mail configs from server to server for migrations. There's been no indication that they are looking to upgrade their methods to something more secure and therefore hiding this from the Interface does next to nothing to actually protect passwords stored on these systems. This change did very little to increase actual security, and that's why it was an exceptionally bad decision since they failed to achieve their stated goal while removing an important feature that many of us use almost daily. Simply put, SmarterMail password hashes are not what any security-minded professional would consider to be secure.
0
@Connie - I think we all support your opinion as long as it isn't forced upon those who don't agree with it. And given the high technical / programming IQ of most of the people on this thread, we just can't figure out why this isn't a configurable option (with the default being the most secure choices). It's been a feature forever, so to remove it was probably almost as much work as it would have been to create a switch for it.
0
Far as I remember, SM passwords were always scrambled with some kind of hash. Fairly insecure, as noted by others, but hashed. This may a good time to once again remind everyone that the SmarterMail datastore is NOT encrypted (thank heaven!).
0
Their hash is known, it's contained in their DLL's where the code can be easily viewed, a tool for reversing them is available on the Internet, and in reality their hash is no more secure than shifting the alphabet. I'm not really complaining about that, but to remove this function and to tout it as being a security enhancement while the product clearly lacks such security just blows my mind.

The insecurity however enables flexibility. For instance, I can copy over the raw files for full mail domains from one server to another and they just work. It would be a lot of work for them to actually make this secure. Removing the show password function, while keeping it in the API and also having these weak hashes isn't even close to closing a hole. This was all for show. They commented out some code and called it more secure. That's it. I'm not fooled. I would like my feature back now please.
0
Since ST has apparently said that in future the passwords will be made much more secure - and much more difficult, if not impossible, to decrypt - and has ALSO apparently said that no change will be made to the current hash, we DO need some clarification of at least this issue. Thanks!
5
Tim Uzzanti Replied
7/6/2016 at 11:05 AM
Employee Post
As you're all aware, I'm not a normal CEO as I will speak my mind. To be honest, this thread blows my mind. I can't believe the lack of concern for security.
 
1 out of 10 tickets into our customer support department are servers that are under heavy load because a user's mailbox was comprised due to a password set at an incredible low security level. We provide tools for Mail Admins to use to help customers create strong, secure passwords. We provide tools to allow admins to let customers change their passwords themselves. While we thought they were just too busy to implement these policies, reading this thread it seems like security just isn't a concern. That is disappointing.
 
As an email administrator, much less as a service provider, YOU have an obligation to your users to provide them with a secure service and take every step possible because MAIL IS THE GATEWAY INTO SOMEONE'S LIFE!
 
This isn't about you but its about your customers!  You should be using this change, and the upcoming changes, as an opportunity to explain to your customers WHY this is GOOD for them! Why this change is the move towards providing them with a more secure environment. Why password policies are in place. Why strong passwords are SMART and NECESSARY in the world today. Use the innumerable stories about how people's email is hacked EVERY DAY -- every day people as well as world leaders -- as an example of WHY you can't see their password and WHY they should change it to something strong. Heck, you can even give THEM the ability to reset their own passwords via the webmail interface...that relieves YOU of the necessity to change it for them! Changing passwords isn't new -- people are used to it. Virtually every service they use requires strong passwords, login attempt blocks, recurring password changes and many, many more security features that they're already using. They will understand!
 
SmarterTools is taking an incredibly SLOW approach to solving how passwords are stored on the server so our customers and third-party integrations can adapt. WE WILL NOT BE CHANGING OUR POLICY!
This release we eliminating the risks for passwords being comprised at the web interface layer. And to clear up any confusion, in the NEXT release we will be eliminating the risks at the API and disk/encryption level. Regardless, Show Password is going away across the board.
Tim Uzzanti CEO SmarterTools Inc. www.smartertools.com
0
@Paul
From the security point of view it woud be very good to have this "much more" on security. In short words they will do like others and not store the password anywhere. Instead they one-way caclulate a salted hash. The password in the moment of authentication is provided by the user. Only if the JIT-calculated hash with the same salt is equal to that stored on the server the authentication will be successfull.

But even this would not make it impossible to provide (or keep) an optional data field that still contains the password in the same slightly encrypted but always recoverable and showable form as it is available at the moment. Each time the password is set or changed it will be "salt-hashed" + (optionaly) "weak-stored". This way anyone can choose what he want. Eventualy also granular down to the single mailbox.
0
Thank you for responding Tim it shows that at least you are paying attention.

Nobody is suggesting that security isn't important I'm not coming away with that as the issue here. Everyone can agree that its of paramount importance. The issue is the additional burden placed on us the admins to service the accounts on a daily basis.

Explaining to the bricks that they need better passwords then password123 isn't at the core of the problem. The problem is adding time to my day having to walk them through how to change the password not only in a desktop client but their tablet, cell phone or phones and on and on.

Knowing the password means I only need to tell them what it is and help them THAT device not several.

I don't get paid to set up their damn cell phones but removing that password option means that I am forced to do just that.

What everyone on my thread would appreciate is allowing some open dialog between us your customers and Smartertools to find some kind of middle ground that works for all of us. On the surface, regardless of saying that discussion for this was opened during the beta phase.. well looking at my thread it doesn't look like there was much input on that.

Tim you've got a great product, and after programming for 42 years I don't say that to many people. Sometimes though its easy to forget that you have a great amount of grey matter in the people out here that are your clients. Utilize us as a resource. Why not start your own thread and let's have a meaningful discussion with us?

Simply saying it ain't gonna happen so drop it... leaves me with a bad taste in my mouth that you guys feel you know better and only your solutions are going to be used.
0
Tim, thanks for your response. I understand where you stand on this, but showing the password to an admin is an entirely different matter than the "security" (in terms of how easily it can be figured out) of the password itself. Just because an admin can view the password, it doesn't mean that it can be reset to a lower encryption level, or to some "obvious" character string. Forgive my ignorance, if indeed I'm being so, but aren't you conflating two different issues?
0
BTW, what this FORCES us to do is create the password WITH the user when the account is set up, and THEN store it in OUR OWN database. It "solves" the problem for those users who are not savvy enough to change their own passwords, but makes their account possibly LESS SECURE because we have a database of others' passwords sitting out there. And if we are a support team, that means we're back where we started, or even behind where we were, in terms of the overall security of users' passwords.  So there is your workaround. Perhaps it absolves ST of some responsibility, however.
0
Tim Uzzanti Replied
7/6/2016 at 12:46 PM
Employee Post
David, I appreciate the comments. But to be honest we do know the the insurance risks, compliance issues and overall industry and environment more than our customers. We know insurance companies will be voiding policies and claims in the future for software deficiencies. We know the liability of the company providing mail services to users as well as personal liabilities for executives etc. We are also aware of significant development efforts and timeline to make transitions occur that impact 15 million mailbox users. Also, this community is a small subset of our customers and the overwhelming request is that we take these steps. This isn't some wild ass ... lets make this change! We are in the process of a 16 month transition based on significant experience with thousands of customers, attorneys, compliance authorities and insurance carriers. The decision has been made!
Tim Uzzanti CEO SmarterTools Inc. www.smartertools.com
0
Tim Uzzanti Replied
7/6/2016 at 12:51 PM
Employee Post
Its so disheartening to see the efforts being made for a less secure path that will put peoples information at risk. I hope that I never use such a service. Not to mention what your company and you will go through if the information is ever compromised.
Tim Uzzanti CEO SmarterTools Inc. www.smartertools.com
0
So SM has been a really insecure product for the last decade, a company you “hope that you never use” (I am quoting you) than have been put “peoples information at risk” and changing every year for it….
0
Tim Uzzanti Replied
7/6/2016 at 12:58 PM
Employee Post
Paul, it was an analogy and realization relating to a subset of our customers. I tried to make that clear in my post.
Tim Uzzanti CEO SmarterTools Inc. www.smartertools.com
0
I agree with both David and Paul's points. For SmarterTools to tell me that they know my customer base better than I do is a tad aggressive. We're not hosting email for the FBI. If somebody else is and they need the additional security features than that's great.

Our customer base is more than OK with us being able to look up their passwords, and, in fact, it's a necessity for each of our customers' admins to be able to look up the passwords of the other users on their domain. These aren't people's personal email boxes - they are short-term volunteer members of non-profit association executive boards. The email transactions that these people do while serving on that board is the property of the association, not the individual. The association requires the ability to eavesdrop if they need to, and right now we can provide that for them.

And we're not talking about the relative strength of a person's password here. We've used all the great tools available to ensure that each user has a strong password. Our mail server is fairly locked down and it's pretty rare that we see anything unusual going on despite an average of 75K daily messages in and out.

Over 10 years and at least $25,000 of my hard-earned money has gone to SmarterTools. Based on this, I won't be spending another dime on their products nor will I spend another ounce of effort contributing to this user community. The current versions of everything we have installed work and will probably continue to work for the foreseeable future. That will give us ample time to seek out an alternative later.

I do applaud Tim for making a comment, albeit delayed, and setting the record straight about their future plans. It's good to have CEOs who are passionate about their company, although those comments (and others I've read after looking at his history) could have been seasoned with a little more tact.

You've lost one loyal customer for sure, and I'd be willing to bet that there will be others after having read this thread. I wonder how long it will take before this thread gets taken down. It's clear that this topic is not up for debate or discussion, and at this point all it's doing is creating a strong dislike for SmarterMail and SmarterTools.
0
@Tim
Thank you for this clear indications where the road will go.
However I know many cases of comprised passwords. A lot of this users have never used the web interface on our server (when I access it I first have to chose the time zone). Most of them are using cleartext protocols like POP3 or IMAP to communicate with the server. But we know also about some cases where they already switched to TLS encrypted protocols and still the passwords get stolen. We think that this happens because it's also possible to read/recover/show the password stored on the clients computer and in most of all this cases the client computer appears infected.
We're also pretty sure that it has nothing to do with "always the same passwords" used by this user (=email address) elsewhere in the net because 95+% of all comprised cases we handle has still that password we random generated at the moment of the service activation.

Regarding your point of "incredible weak password": Beside that we've implemented some complexity thresholds years ago, looking at the logs we can't see very much brute force dictionary attacks. In fact theis attempts usually become blocked by other traditional security mechanisms like "block IP after max failed logins".
Analysing this comprised password cases it's nearly always the same behaviour:
1.) the bad guy makes exactly one single auth request to test if this login will practically work. If ok he will mark it as "ok for the next campaign" At this moment it's pretty clear that it was stolen somewhere else.
2.) for a while (hours up to days) nothing happens
3.) the show begins...

In the meantime we are aware to detect and automatically block practically all of this cases. We monitor the (spamy) 4xx and 5xx responses in the outgoing delivery log. (I can't post an image here but I can say that our monitoring graphs clearly demonstrate a dramatic improvement from that month on where we've implemented and fine tuned this checks.
Additionally we watch the SMTP-connecting authenticated IPs, geo-resolve them and automatically block outgoing smtp service access for this user, if he connects from more than x countries in y minutes (there are different spam campaigns: some try to send as much and as fast as possible. Others try to hide the miss-usage and use that single comprised account only 2-3 times each hour.)

From my opinion you can keep your plans to implement a way different and improved security for the users email data. But at the same moment you could also "optionally enhance" this with a "showable" copy of the password, that is only used/stored/showed when the individual admin has some reason to use it. It looks like a lot of your paying customers, would love it. Eventually provide it only through an encrypted "master password" that is NOT stored anywhere one the server but only known by the super admin.

BTW: Just today I had a request from a customer where an ex-employee seems to have accessed mailboxes after his exit. It would be great when you could provide ActiveSync/EWS/WebInterface logfiles like that from pop3/imap/smtp. At the moment the IIS access logs are not really informative ... salt-hashed passwords in this case will still prevent nothing.
0
Look Tim, you are on the right path to increase security. Four years ago, I changed our CMS to only store passwords as salted/hashed. People didn't mind changing their passwords for access to websites, but they went nuts when they had to change their email password. I now store email passwords as encrypted strings (same encrypted as credit cards). The Smartermail user community is asking that Smartermail offer a choice of either salted/hashed or encryption for email passwords. The obtain password API would throw an error for Salted-hashed passwords, and return encrypted passwords. This options should be set on a domain basis. To support both, store the password in your xml as <password>SALT:xxxxx</password> or <password>HASH:xxxx</password>. Not to get off path, but I could really use a feature to only send TLS email or only receive TLS email. Governments want nothing sent in clear text.
0
Tim Uzzanti Replied
7/6/2016 at 1:19 PM
Employee Post
SmarterMail is 14 years old. With every major release there are areas prioritized to meet the ever evolving security standards. As I mentioned, this transition plan has been in place for some time! Prevention at every level has been worked on over the years and now we are focusing on YOUR worst case scenario... a hacker gained access to your server through a vulnerability on YOUR server! We have approached these change slow and methodical in an effort for customers to adapt and third-party products to be updated. I'm extremely proud of our approach.

We spend significant money putting SmarterTools products through security and compliance testing so that corporations, financial institutions, government organizations can use our products today and in the future...
Tim Uzzanti CEO SmarterTools Inc. www.smartertools.com
0
@Tim - it's equally disheartening to see that you are failing to understand our point of view on this. This change has created more work for us and it appears you couldn't care less about that aspect of it.
0
That's just it Tim, what you did hardly made a dent in protecting passwords and at the same time you greatly increased support costs. You left it in the API, and your hashing is rudimentary. People lose passwords on our mail systems primarily from viruses, phishing, and weak passwords. This is almost a daily issue, and yet having a whole system hacked is almost unheard of. It's nice when someone has their account hijacked to be able to look at the password and tell if it was weak, or if it was complex enough that a virus was the likely culprit so that you can advise accordingly. When people call saying that they can't connect to the system with their new phone, having them read back their password and comparing it to what it actually is solves over half those issues. As far as protecting accounts goes, SmarterMail has lagged in detecting abuse, although in the last few releases steps are being taken, and that is appreciated. More moves could be taken to better detect dictionary password hacks, allow for better granularity in abuse detection (such as being able to whitelist a gateway so that such features can be used for SMTP), and things like adding two factor authentication for system administrators. I do understand that some want these passwords hashed beyond recovery, but most others in this space value the cost of support over the increased security, and in reality removing just the Show Password feature only gives a veil of protection. So it seems like we're losing a lot for very, very little gained.
0
Tim Uzzanti Replied
7/6/2016 at 1:42 PM
Employee Post
Fred... we are working on end to end secure mail in a future release. We are now completely focused on the new interface and making SmarterMail a 100% API driven architecture (one of the first). The new web interface is absolutely incredible using the latest technologies and scales from desktop to mobile. And because the new web interface uses the API, the separation of interface and logic makes SmarterMail even more secure!
Tim Uzzanti CEO SmarterTools Inc. www.smartertools.com
0
I imagine two possible scenarios on how I have to communicate this changes nextly to our customers and partners:
scenario A:
Sorry but our Mailserver company (sorry it's not opensource) has decided what's going on and neither I nor you partner/customer has any choice or voice: The good part: your data will stay more secure: the bad part: we can't help you anymore the same way as before. As said you have no choise. Take it as it.
scenario B:
Dear partner/customer: I'm happy to announce that from now on you can freely choose if only you have knowledge of your password and all your data on our server becomes encrpyted. Please keep in mind that after you choose this recommended security enhancement we cannot tell you anymore your current password. If you can't remember it we can only give you a new one.
0
+1 for enforced TLS connections.
I would love to have it as a domain default and the domain admin (or end user) must explicitely disable this "highly recommended security feature" when for whatever reason they realy need unencrpyted connections.
0
Tim Uzzanti Replied
7/6/2016 at 1:48 PM
Employee Post
Shaun... do you really think the CEO would spend time on a community if he didn't care about his customers? Do you think we would take 16 months to transition something that we could release tomorrow? Ironically, I have another set of customers (hosting companies, corporations etc.) that are demanding certain changes now! Were getting hit from both angles. Its all good... that is our job! But don't ever accuse me of not caring!
Tim Uzzanti CEO SmarterTools Inc. www.smartertools.com
0
Tim Uzzanti Replied
7/6/2016 at 1:56 PM
Employee Post
Matthew, the removal from the web interface and not the data is to start our customers on the transition. There have been references to an application that allows you to look at passwords on the server. I would hope people not just use the tool but build new policies on how to handle such issues. Its also important that any passwords are removed from the web interface for security reasons etc. I only wish some of my vendors took similar approaches.
Tim Uzzanti CEO SmarterTools Inc. www.smartertools.com
0
@Tim Well the good news is you won't be getting it from both angles anymore as far as we're concerned - we're out. Go ahead and focus on the needs of those other larger hosting companies / corporations since I'm sure they pay you more than our measly pittance of $3K per year. It's clear that we, as a long-time and up until today loyal customer, no longer have a voice.

The overall premise of this entire thread is that the removal of the "Show Password" button has created more work for mail admins. I've re-read your comments, and Andrea's and Matt's, on this thread and not one of you have presented concern over the additional workload this is putting on us. Andrea's initial response came close by acknowledging that it might create "policy changes" but even that was rather unapologetic.

I'm sure you care about your company, your products, your employees, and (in a general sense) your customers. But your attitude on this particular matter says loud and clear that you don't care that this creates more work for us. I'm not the only one on here feeling a little hurt / betrayed / disappointed with that.
0
@Tim
Do you have already an idea of how this change will impact on our servers performance? Again I can't post an image here, but when we switched from v14 to v15 our monitoring clearly showed a step from avg 30 to 55% CPU usage. We solved this by adding a second socket with a couple of cores.
I imagine that de/encrypting the entire content of all messages (currently all messages arrived within one day and stored in one grp file) will have a way way more noticeable impact.
Maybe we have to put some geforce cards in the servers? Do you know if they will work in virtualized enviroments too?
0
Tim Uzzanti Replied
7/6/2016 at 2:41 PM
Employee Post
Yup, Shaun. I don't care and were all about the hosting companies. I guess your the type that takes everything to the extreme... except when it comes to security. Whatever product you choose... I sure hope you take your customers into account and do absolutely everything to secure their personal data.
Tim Uzzanti CEO SmarterTools Inc. www.smartertools.com
0
Tim Uzzanti Replied
7/6/2016 at 2:48 PM
Employee Post
Markus, we have side projects right now for end to end encryption.. it is not in our main code base. It will definitely take more CPU. When start to integrate in a future major we will measuring performance and offer up suggestions as we do now on hardware etc. I'm surprised you saw an increase in Mail 14 to 15. We have seen a decrease across the board on 14 and 15 installs. I would cross reference the reports against activity and connections etc. Mail servers naturally increase in activity 2 to 3% per month without additional users. It is an increase in devices, spam and amount of messages on the server.
Tim Uzzanti CEO SmarterTools Inc. www.smartertools.com
0
@Tim from my standpoint, people are not paying me for hardened email services. We don't run email on encrypted disks, we can't force SMTP by TLS for certain domains, heck, I'll bet that 80% of users don't even use TLS/SSL in their mail clients, and certainly only a handful opt to change it when it is not auto-configured. I have clients with over 1,000 accounts to clients with 1 account. Not once in over 15 years has someone asked me if passwords can be hidden from view, yet this feature comes in handy almost every single day. I'm guessing that the vast majority of users of SmarterMail are on the systems of service providers, and none of these service providers are choosing SmarterMail because it has the best security, rather they choose it because of it's usability. If you asked your clients about features in v14 and before what parts of the administrative interface they used most, Show Password would probably land second right under Spool Management. Even if you remove it from the API in v16, these passwords still will not be secure by a long-shot so long as someone has access to the system itself. Even MD-5 password hashes would mostly be reviled using one of the massive databases hackers use to decrypt them. If your server is hacked, you are screwed regardless, and everyone will need to change passwords if you are concerned about security. There is nothing that you can do to change that.
0
Tim Uzzanti Replied
7/6/2016 at 3:14 PM
Employee Post
Matt, you will not need to use end to end security. That is something that is configured at the domain level and requires effort to enable. Also, when it comes to show password. Think about Google, Microsoft, and others. Do you call them for passwords? No, you setup secondary information when you log in like a cell phone number. Some other method of authentication etc. That will be available in SmarterMail. In the end, you will be eliminating work from your support team not adding to it while securing your server. And, your users don't know what to ask. But if you asked them if they wanted their mail server and personal information to be safe. The answer would be 100% ... YES!
Tim Uzzanti CEO SmarterTools Inc. www.smartertools.com
0
@Tim, I applaud you for your efforts to increase the security. What some of us are saying is, your increasing our support costs and time by not allowing us to see the password. You all have not addressed this. I'll give an example and ask your suggest for the following.. Which, BTW, has happened. User calls in to get their password because they've gotten a new device. We can't give them new password with SM 15.x, so we reset the password and they setup their device. It works for a bit, they then call us back saying it stopped working. We trouble shoot the device a bit, and then end up checking the logs and IDS blocks only to find that their IP has been blocked. Why? Because they have other devices on the same network checking mail too, and they've attempted to login and check after we changed the password.. and after so many failed attempts, IDS kicks in, blocking the IP and then causing issues for the device we just setup correctly. What should have take 2 minutes has now escalated into a 30 minute phone call. This is a issue for ISP's, Web-hosting providers and corporate users alike. I've been System Administrator for all three. We need some sort of solution that keeps us from chasing our tails. We've had these issues with our web-hosting control panel email setups (Open Source, one-way hashed passwords) and have migrated everyone over to SM over the past few years for a more centralized administration and ability to handle password recall. Perhaps instead of doing a weak one-way hash, using some sort of encrypted password, and in order for administrators to see a password, they are prompted for some sort of MASTER password that's use for the decryption. There has to be some sort of compromise.
0
@Tim, there are organizational differences between Google, Microsoft, GoDaddy, etc. and your general customer base. If I had a lot of low level support people, I wouldn't give them access to view people's passwords, or even impersonate their accounts. But somewhere up the chain there are people who you must in fact trust because they manage the technology behind your services, and they need access, the same sort of access that you wish to keep hackers from achieving. Simply put, if someone trusts me to host their email, they have to trust me with their email, and me being able to see their password does not in fact require any greater degree of trust. As the owner of a service provider, and as an administrator, I do not need technology from protecting me from seeing passwords. If my clients are concerned about their passwords being viewable, they should make them unique to our system, in fact, I strongly recommend that people not use the same password for email as they do for other sources.
0
Tim Uzzanti Replied
7/6/2016 at 3:58 PM
Employee Post
Matt, you don't want people using the same password on any two accounts let alone mail. Every password should be unique. That is the only way to protect yourself from you entire online presence being compromised. As soon as one account is compromised then they attempt to login to the most common services such as Netflix, Banks etc.. They then take ownership of the accounts and leave credit cards. If your lucky, your account will be listed online somewhere and you will be notified by some cool people that make non profit services to tell you when this kind of crap happens. At least you then know why you can't login to anything. BTW, all this stuff is automated. Millions of accounts a day are compromised. Depending on the sites that these hackers can access they can accumulate enough information to open credit cards in peoples names etc. You just don't know what your compromising!
Tim Uzzanti CEO SmarterTools Inc. www.smartertools.com
0
I second Billy here. Unlike FTP, CMS, and hosting control panel passwords, email passwords are typically stored twice for every account on every device. Power users will have multiple devices; a desktop, a laptop, a smartphone, and a tablet. They may even have multiple accounts. So changing a single password may mean them needing to reset it multiple times on multiple devices. It is a much better solution to tell a verified client what their password is. I know most of my customers by not just name, but also their voice, or at least I know their IT people, and that allows us to tell clients what their passwords are instead of resetting them and increasing the work. Troubleshooting also benefits greatly. We verify the mail server settings along with the passwords they are using as step #1 every single time there is a connectivity issue. It's a fantastic feature to have at our disposal.
0
@Tom I do understand security quite well. My specialty is spam blocking, and I have an automated blacklist that is 100% accurate and catches more spam than every list at Spamhaus combined (not an understatement). Some around here know me and my efforts, and benefit from my data.

The fact is that the SmarterMail system admin is not an active vector for stealing passwords, and none of these hackers are spending time sifting through the administrative interface, viewing every account and pressing on the Show Password button. What hackers are doing is infecting computers, phishing their credentials, guessing weak passwords from relatively short lists, and sometimes assuming that a password hacked from one place might also be used for their email. Most weak passwords have already been guessed and the #1 way that passwords for email are exposed are through viruses.

If you were really concerned about more targeted attacks on a system, there would be configurable limits on access to the API among other things. System admins would be required to authenticate their browser on a first visit through two factor authentication, and the passwords stored in config files on the server would not be easily reversed. Heck, only in v15 were there settings to ban the most common passwords from being used, and hopefully the complexity requirements have been updates so that they are actually useful (use 3 of 4 types of characters for instance instead of an absolute requirement). There are just so many holes that are a bigger threat to all the data on these systems, and the one you closed wasn't being widely exploited if at all, and it comes at a great cost while closing the other holes come at little or no cost to us.
0
Tim thank you for answering some of these questions but some of your answers come across a little harsh. I think that's your passion coming through but you might want to understand the frustration of us that are dealing with this change daily also.

I'd remind you that everything you do as far as security goes is all fine and well except I have all the time in the world to hack the hell out of this product... password encryption aside.

If I am the admin I already have a leg up and nothing you implement can stop that. SmartTools is a decent sized company but even you're not Microsoft or Cisco and they are still being hosed on a daily basis even with their resources. Not to mention Adobe.

My point is there is no security from someone with unlimited time and access from eventually defeating anything you come up with. It's just a fact of life. I'm not asking for source code level access here just some understanding that out chosen partners listen to us.

There are plenty of examples of companies that put themselves above their customers and did it their way. All they have to show for it is a lot of source code sitting and rotting away on old hard drives with no customers.

Keeping customers you have now is always cheaper then having to troll for new ones to replace the old ones.
0
Thanks, David, for a thoughtful post. "Harsh" indeed - even to the point of telling loyal customers that what they've been doing with ST's own product FOR YEARS is somehow, suddenly, just plain wrong (Really???). I think "haughty" applies as well. Perhaps ST management will take some of your words to heart, and maybe re-read this entire thread with a more open mind. "My way or the highway" is not generally a great way to keep your customers.

Note to Tim U: You continue to conflate easily-hacked passwords with email admins VIEWING passwords that were created using proper "complexity" rules. The difference between these is HUGE. Also note that the SM admins weighing in here on the side of viewing user passwords on-demand would be out of business (or worse!) if they were caught compromising their clients' email accounts.
1
 
@Tim Uzzanti: you wrote: "This isn't about you but its about your customers".
This is exactly what we are talking about: as a Service Provider, our customers want that our Technical Service CAN see the passwords so they can be helped if they forget it without changing the actual password.
 
That's not our request, it's our customers request, and I think that many other SM customers have the same issue with the new policy.
 
In other posts I have proposed a number of different solutions to do so with a secure way and I think that many other could be found WITHOUT remove the "show password" function.
 
I understand that security is a must, but even support to curtomers.
 
I think you can find a way to do both, otherwise many of your customers will be disapponted.
 
8
Tim Uzzanti Replied
7/7/2016 at 11:02 AM
Employee Post
After having some pretty intense discussions with the other Execs and development teams the last few days, I’m going to budge. Slightly.
 
First, let me say this: Every change a software company makes to their products results in a portion of their users disliking that change. A GOOD software company realizes this and will continue to evolve their products to meet 95% of their current customers’ needs while still preparing their software for the future. That means changing features to adjust to current safety, security and privacy measures being deployed by other products and services. While this holds true for ALL software, it’s even more important for mail servers. That said…
 
We will keep the “show password” feature in place for SmarterMail 16.x, but it will be optional. System Admins can toggle it on or off, which should satisfy those of you who want to keep it and those of you who need it removed for security audit and compliancy issues.
 
In addition, we are going to introduce secondary authentication methods in SmarterMail 16.x (SMS text or email) so that people can reset and recover their accounts on their own. When logging into webmail, users will be asked to complete the necessary information to make this happen before they can log in. (I.e., add mobile phone numbers and secondary email addresses.) We will be providing more information on these changes in the near future in the Focus Group.  You can request access to the Focus Group by sending an email to sales@smartertools.com
 
The goal is to help companies by alleviating some of the support burden and workload that can come with password issues, eliminating reset requests, etc. Once this change is in place, and once you upgrade, you should email all of your customers and tell them to log into webmail to complete the process and add in an extra layer of protection for their accounts. This is a POSITIVE change, so we recommend that you announce it as such. However, getting customers to input that info is important and necessary.
 
HOWEVER, with SmarterMail 17.x, currently scheduled for a Summer 2017 release, we will be removing the option to show passwords PLUS we will remove the ability to decrypt passwords on the server. There is NO debate on this as SmarterMail 17 will offer additional privacy and security measures as well.
 
BOTTOM LINE: We will NOT sacrifice the future of SmarterMail as a secure and communications platform simply because customers do not want to change their own security policies, protocols and procedures.  The actions we propose are the bare minimum a company should take to ensure their business is safe and their users are protected.
 
We hope that these changes will make this transition easier and will result in less work than you have TODAY!  No company should be dealing with support requests that allow employees to access users’ passwords.  It is a small company mentality to do so...  
Tim Uzzanti CEO SmarterTools Inc. www.smartertools.com
0
The SMS recovery option is a great idea, I was hoping that was coming as many of our customers only have one email address.

I applaud you for offering the (optional) show password setting until the other password recovery mechanisms are finalized put into place. This should keep both camps happy.
0
Really pissed that you chose to cave in to the vocal minority on this issue. I hope SM17 comes quick as possible as these security features are why we are done with iMail.
0
Derek Curtis Replied
7/7/2016 at 12:06 PM
Employee Post
HI, Connie. I'm just curious, but how will the option to show passwords NOT meet your requirements? I only ask as I'm not entirely sure we've made a decision on how that will be implemented. (I.e., a XML change versus a button in the web interface, etc.).
Derek Curtis COO SmarterTools Inc. www.smartertools.com
0
Tim Uzzanti Replied
7/7/2016 at 12:12 PM
Employee Post
Connie, our timeline is the same. What has changed is that it is an option now in SmarterMail 16.x in the web interface. We understand that 99% of our customers realize these changes are important and utilizing the tools for customers to mange it themselves will actually result in less support.
Tim Uzzanti CEO SmarterTools Inc. www.smartertools.com
0
@Tim, I have far less objection to this feature being removed when it is paired with actual end-to-end security protecting passwords. I like the idea of it being optional in v16 as that allows us to choose whats best for our needs. I would hope that this would stay after that of course.

I want to make a note about one thing that popped out at me however. I run and operate as a small business by choice. I get customers almost exclusively by word-of-mouth because people trust me, people respect me, and I'm good at what I do. We shake hands and it means something as our businesses are an extension of our selves. My customers don't mind me having access to their passwords any more than they mind me having access to their email. They don't buy services from me because I'm cheaper, but because they trust and respect me as a person, and trust is so damn hard to find. Being a small business and thinking with a small business mentality isn't a fault, it's a feature, and one that large companies can't replicate.
0
Well it's certainly good that we've been able to reach a compromise after having a meaningful discussion - both of which is what several people have been asking for on this thread.

Although having the CEO of a company resort to personal attacks on their own public forum sure did leave some scars. Saying that I take everything to an extreme except security - excuse me? Who removed a highly useful feature without any sort of warning or discussion? And then refused to acknowledge the dozens of people who were upset about it for four months? All I wanted was the *choice* - to do things the way we'd been doing them for the past 10 years, or to adopt a new way. And then getting zero response from anybody for four months seems like we've been pretty patient about it.

I also echo Matthew Bramie's comments about "small company mentality" and still am struggling with understanding why a CEO would feel the need to constantly scold his own loyal customers.

"99% of our customers realize these changes are important and utilizing the tools for customers to manage it themselves will actually result in less support." That seems to be yet another dig at the people on this thread, but I also wonder about that 99% since I don't see or hear anyone other than Connie (several times) and Colin (back in April). Judging by this thread it's at least 90% who wanted the option of the Show Password button - and even those people are respectful enough of the Connie's and the Colin's of the world to suggest that both options can and should be possible. This thread is a small sample size and any actual numbers would be impossible to prove either way - but then why quote any sort of numbers - especially something so bold as 99%?

PLUS that doesn't mean those same people can't also realize that changes are important. I know that the Show Password button was / is a potential security risk - I would appreciate it if SmarterTools would stop trying to pretend that we don't know that and please stop scolding us about it.
0
Hi TIM, glad to see that in the near future we will had a choice. This is (for me) a great news.

BUT I have a threat when you say that 99% of your customers will be good with remove "show password".
Where did you get that statistic? I have never seen a poll where you ask thet to your customers...

I think this is your opinion, not a real request by your customers.

I hope that in the future we (your customers) will have the opportunity to voto in a public poll to get a REAL statistic that say who want who don't the "show password" function.

After that, if the real statistic is near 99% to remove "show password", I will accept it without problems...
5
Hi Tim,
 
I've only posted a few times about this issue over the past number of months since the decision was made to remove the feature. My post here doesn't really add much new to the long standing conversation. I certainly can see both sides to the argument. On one hand we want to please our customers when they contact their mail service provider, by providing the information they need, in a quick and efficient manner. In addition, from a help desk perspective, retrieving a password quickly reduces support costs and aids in quick resolution to a user problem, as I've detailed in previous posts. On the other hand, I understand the gaping security flaw exposed by this feature, albeit "impersonate user" is another security flaw (by the book) but a feature regularly used for support purposes and highly valued by SM admins as well.
 
In the end, what I appreciate is the decision to listen to the customer base and take into account the disruption in our collective support operations by at least postponing the complete feature removal until SmarterMail 17. This allows us the ability to plan accordingly with better visibility on how these changes will affect our ability to support our customers, and prepare them for a change in procedure. I suspect that right now only 20% to 30% of our users (at best) know their email passwords. I know for certain that the security weakness will just pass downstream from the SmarterMail server by keeping password lists in spreadsheets and word documents at the client level.
 
Just as a note to my fellow SmarterMail admins, although I am a bit ambivalent about the change and railed against it when announced, consider that neither Active Directory allows an option to "show password" nor does any modern Unix/Linux OS, nor any major commercial email service, nor nearly any enterprise grade software such as backup software, security suites, database systems, et al. So, to be fair, although we love the ability to retrieve passwords, we are living in the past, so to speak, to some degree. Suppose, just for a minute, that any one of our SM servers was compromised at the OS level by intruders by either a flaw in IIS, or Windows Server, or any other application on your SM server. Let's not be naive to think that it isn't possible. An intruder could run a script and retrieve all SM passwords, as it stands right now, prior to their upcoming encryption plans. Assuming your business is big enough to make the news, this would be a stunning blow to the reputation of a business, as well as to the software vendor.
 
Suppose also, just for a minute, that none of us were SM admins, or users, or IT know-it-alls in any sense, and we read a news story about an Internet services company that was hacked where all usernames and passwords were stolen fairly easily because that data wasn't encrypted to anywhere near current standards in contravention of best security practices. I think that my initial reaction would be, "Holy cow! What a bunch of rank amateurs!" Frankly, I'm fairly positive that this would be my reaction. This would classify me as a hypocrite as I love the show password feature. Therefore, I need to suck it up and realize that this painful change, on balance, is good for both my company's security and that of my customers. Please, just give us time to prepare for this adequately, as you proposed.
 
Sincerely,
 
Matthew Titley
0
Tim Uzzanti Replied
7/8/2016 at 7:41 AM
Employee Post
Well said and well written!
Tim Uzzanti CEO SmarterTools Inc. www.smartertools.com
0
What about version 15? We have not upgraded because of the show password feature... will it be restored there or should we wait until 16 comes out?
0
Tim Uzzanti Replied
7/8/2016 at 8:48 AM
Employee Post
An upcoming minor will include it.
Tim Uzzanti CEO SmarterTools Inc. www.smartertools.com
0
@Tim, we also appreciate the decision to leave this in the version 16, and hopefully version 15 as well.

I too agree security is a top priority on all platforms, including mail servers for us, and I don't believe that the option to recover a password is the issue, sure encrypt passwords on the server, but allow the admin to put in an override password to see the passwords, and also select if they want this option on or off.

The fact that end users do not always listen to the best advice given, remains one of the weak links in the security chain, if the clients are not making sure, they are adequately protected from viruses, malware, using secure passwords on all devices they use, which in turn then feeds back into the server security side of things, the security will only be as strong as the weakest link.

The fact that we can not control the clients devices and security mentality, leaves a huge gap for a hackers to obtain the password from the clients devices if not adequately protected. If the password is known the security is breached, no matter how strong the security is on the mail servers, so until this "hole" is closed there is no real end to end security, until the end users themselves ensure and protect their devices and take security seriously, the fact the admin can access the passwords is a small possible potential for misuse and abuse.

Dealing with high amounts of end users, who either have had devices stolen, hit by viruses, or just forgotten their passwords, etc leads to a high workload for us, the SMS option would be a good solution to reduce this load.

Allowing a configurable option to enable or disable this show option, should'nt make SM less secure, it allows flexibility of SM to fit into different kinds of environments, and not just fit one specific market segment. The password complexity is configurable by the admin, this could also leave a system wide open, so what the difference leaving a config option to enable or disable the show password?

One request though I almost forgot about it, when you login as the system admin and make changes to the users profiles, ie add a forwarder, it wont allow you to update the changes unless you type in the users passwords and verify it... This is one issue that needs to be addressed as you cannot save changes without the current users password..
0
"I know for certain that the security weakness will just pass downstream from the SmarterMail server by keeping password lists in spreadsheets and word documents at the client level."

Got it in one. The security outcome for the average Mom & Pop user will be worse than if they retained the status quo. All this change achieves is a bit of backside-covering by SmarterTools.

And that's fine - it's a litigious world we live in - but they need to be honest and say that, rather than dressing it up as them doing us a favor, and then treating us like empty-headed numpties when we complain.

Security is hard, and it ALWAYS ends up being a trade off between competing outcomes. All we're asking for is the ability to decide which trade-offs to make - there is no one size fits all.
2
Derek Curtis Replied
7/12/2016 at 10:52 AM
Employee Post
 
(The comments offer some good debate as well)
 
While I, personally, agree with the dissent that sharing a Netflix password is hardly a violation of CFAA, sharing -- much less having access to -- an email password is a completely different animal. Tim has remarked in the past about the liability associated with personal information leaks for tech companies, all the way to CIOs having personal liability for breaches. Access to a user's email password, and therefore their mailbox, is a huge risk, considering email is the lifeblood of just about every service in use today.
 
Having a tighter grip on this type of information, and limiting access to it, is the direction things are headed. Now is the time to get users used to it: use of password vaults (1Password, LastPass, etc.), use of strong, but common sense, password creation policies, etc. Everyone needs to keep an eye on this type of ruling and know that the Courts are taking a more active role and a hard line on access to user information. 
 
You can't prevent someone from writing their passwords on a Post-It note and attaching it to the underside of their keyboard, but you can limit your own liability. We will do our part as well to try and limit the effect of these changes, but changes are coming, industry-wide. 
Derek Curtis COO SmarterTools Inc. www.smartertools.com
0
>>I know for certain that the security weakness will just pass downstream from the SmarterMail server by keeping password lists in spreadsheets and word documents at the client level.<<

Completely agreed, Grant. I made that point earlier, and welcome your comment - keeping passwords in a separate list has the affect of taking the responsibility out of ST's hands, but it certainly can weaken overall security. I do see ST's point, but there should remain a global switch for "show password" with full user notification that this potential security issue is in effect. I do believe that ST has spoken, however, and this issue is now "resolved", like it or not.
1
@Derek Curtis - I'm not sure what that article, or its comments, have to do with this particular "Show Password in 15x" discussion.  Seems more like a case of password theft than password sharing:
 
"... an employee "acted without authorization" after he used a former co-worker's password login without their permission, in order to gain access to a collection of their data... "
 
Is this the type of evidence being used at internal discussions at SmarterTools to support the argument that removing the Show Password button for administrators was necessary?
 
The point of this thread is / was that removing the Show Password button made the SmarterMail product less *usable* for the mail administrators who were using that button - and the lack of suitable alternatives was causing additional hardships.  Sometimes "security" and "usability" can co-exist, but at some point there's a trade-off and it depends on how the product is actually being used to find the ideal balance.
 
Since not everyone uses SmarterMail for the same purpose, it's impossible to know the ideal balance for every installation.  Completely locked down will work for some, but not as well for others.  The side-topic of this thread was that it would have been good to have had a say in the decision before it was made.  The reason this thread exists is because that opportunity was not provided.
 
Perhaps the best analogy to all this is that of a house.  A house is most secure if it's made of concrete and steel - and if it doesn't have a door.   But if it's impossible to get in or out of the house then it's not very livable.  So doors are necessary.  Having 10 locks on the door is more secure than 1, but it sure takes a lot longer to get in (and out).  Depending on the neighborhood and the risk tolerance of the person living there, sometimes 1 lock is better than 10.  Most people like natural sunlight so they'll add windows - even though it allows another opportunity for an intruder.  And on and on.  Security is sacrificed for usability all the time - when it makes sense.
 
And in the real world, given the choice between the two, the average person will lean towards usability over security.  That is the world that the people "complaining" on this thread live in and the Show Password button made the world better for those people.  Philosophically those same people agree that security should be a higher priority for the average person.  But the reality is that the average person doesn't want to have the conversation and probably most wouldn't change their mind anyway.  They just want to access their email and want our help in doing so.
0
Well said and I support your efforts.
0
Speaking of password vaults, how about adding one inside SmarterMail? That would be a nice feature to set you apart from the competition. Lock it down with 2FA or a PIN (encrypted of course :-).
0
As a mail server admin you can view the passwords using SmarterMail API. But if you do not want to create your own scripts with those API calls, there is a ready-to-use SmarterMail Password Recovery utility at www.hoststools.com
0
ST has stated that it will close that "loophole" in due time, and those password view/recovery procedures will cease to work.
0
Too many eggs in one basket.
0
Please clarify one point:  Please....
 
We use SmarterTrak and we use SmarterMail.......  AND we use our own software (SAS) process.
RIght now we use "Single-Signon" process for SmarterTrak.
..AND we were looking into do something similar for SmarterMail.
Will this still work after the changes????
'----------------------
More importantly....  We still want to be able to "add" or update and a user's existing password, via the APIs.   Don't care about retrieving it... it just that one user is expecting to be able to login across the all SAS AND SmarterTrak and SmarterMail using same password.    I am hoping this is still the case <please>
 
 
0
I would love to see a strong secured base in future SM versions, having irreversible decrypted passwords and optionally (don't forget CPU-resources) encrypted mailbox data.
As an option - obviously required by a notable number of customers - in the same moment SM could introduce a new "password-support-service" that could be used or activated optionally at the same granular way as many other things already can be configured from server defaults over the activated domains down to the individual user mailbox. This subsystem - only when consciously activated - could keep an encrypted but reversible dataset of the currently used password. That will nearly almost better than post it notes, or password-list documents.
0
Tim, thanks for adding the feature back (temporarily) but I have to say, viewing a user's password is a lot less of a detriment than letting the system administrator "impersonate" a user- which is a feature of SM. I use both of these options to support my customers and have delayed upgrading because the "show password" had been temporarily removed. But what I'm trying to say is that security concerns by Smarter Tools over seeing a user's password is insignificant compared to logging directly into a customer's account and viewing the contents of that account (security AND privacy issue). I think if I was to poll my customers and ask what would be a bigger concern to them- seeing their password or seeing what's in their Inbox, they would say the latter. I'M NOT SAYING I WANT EITHER OF THESE TWO FEATURES REMOVED. I'm just saying the argument for removing the "show password" - now coming in version 17 seems, like a weak one.
3
Derek Curtis Replied
7/14/2016 at 9:06 PM
Employee Post
All,
 
With today's minor of 15.x (15.2.6039) the Show Password option is back.
 

As per the release notes, it's a setting in the mailConfig.xml file. By default, the Show Password option is disabled (set to False), but you can simply edit the XML and change the field to True to have it displayed again. You'll want to edit the <allowViewingOfPasswords></allowViewingOfPasswords> row to activate the option. (Stop the SmarterMail service before editing system files.)

UPDATE: In case you upgrade but don't see the <allowViewingOfPasswords> field in the mailConfig.xml, close the file and log in to SmarterMail as a System Admin. Go to any Settings page in SmarterMail and simply save the page. This will write out a new mailConfig.xml file that will include the new field. 
Derek Curtis COO SmarterTools Inc. www.smartertools.com
4
Thank you for giving us back this feature. Line 36 is a God send. The implementation was well thought out. The only way to instantiate it is to modify a file that only a person with full access to the server would have. That person already can attack and break the program at will if they choose.

So to the naysayers that now are bitching then suggest a solution.
 
I know this decision wasn't made casually. Now that most of us aren't being inconvenienced I'd like to recommend that you setup a thread for suggestions on how to solve this problem that is workable in the long term. Utilize us as a resource not antagonists.
 
I'm impressed that Smartertools showed some compassion and listened to us your clients. There's no way to please everyone so now let's work together and make the product even better!
0
Seph, the point is not to block access to the user's account. The point is you should not know the password that the user has more than likely used on several other websites and accounts. It's like having a lock box on your house. As long as that key can only be used on one house, you have permission to use it. But if that key also opens my bank account, my medical account, my favorite shopping site or my other three email accounts... Sure, that's on the user as they should be using a different password for each of those, but that you cannot control. And it's also about giving that access to the hacker who some day WILL steal your database or take control of your system. It's no longer if, but when.
0
Another case of the minority driving the needs and wants of the many.
0
Hi All.. recently I have came across this tool as an alternative options that could be useful until SmarterMail 16 is out with the options to turn this on/off. http://www.hoststools.com/wp-content/uploads/GUI-SmarterMailPasswordRecovery-Guide.pdf
Authorized SmarterTools Reseller. Ask Us For Your 10% SmarterTools License Purchase for entire Jan 2015. http:///www.tweakservers.com
0
Matt Petty Replied
7/19/2016 at 9:33 AM
Employee Post
SM15 has been recently updated and has included an option to turn it on and off already.
Matt Petty Senior Software Developer SmarterTools Inc. www.smartertools.com
0
Is this option still live? running 15.4.x but can't see the show password option. Even after logging in as Sys Admin and saving some settings.
 
 
0
You have to enable <allowViewingOfPasswords></allowViewingOfPasswords>in mailconfig.xml
0
Employee Replied
12/15/2016 at 3:56 PM
Employee Post
Hi Richard. The Show Password functionality was added back in 15.2 and will remain in SmarterMail 16.x. It will be completely removed in version 17.x. To enable the feature in 15.x and 16.x, here's what to do:

Stop the SmarterMail service FIRST.
Navigate to the Services folder. The default location is C:\Program Files (x86)\SmarterTools\SmarterMail\Service
Find the mailConfig.xml file and open it in an editor. (E.g., Notepad)
Find the following line:

<allowViewingOfPasswords></allowViewingOfPasswords>

Edit the value to turn ON this option.
Save the file.
Turn the SmarterMail service back on.

Once this is completed, you should have the ability to see the password for any mailbox when logged in as the Domain Admin and viewing a user's configuration settings.
0
thank you.
I have been thinking about this, but I think I won't turn this option back on. First it will be deprecated soon, secondly, I allways felt a bit shy when I could tell customers their password. I know it feels a bit hypocrit because I can see their mail too if I want.

I now tell my customers "I don't know your password, here is a new one." For support I redirect my customers to my site where all help is available with screenshots, to reset the password. But everyone has other customers.

SMTP IP blocking issue
It has been written before in this thread, what can be an issue with SMTP blockking. I do think too it can be a problem when a customer has multiple devices and his IP gets blocked because of one user not knowing his/her password.
A whole company could be blocked, so something must be invented that now well known IP numbers will not get blocked directly.
A well known IP number can be an address that has been used in the past to log in successfully. Or an IP number that is presently used to log in succesfully by others (like colleagues). Kind a like a reputation for IP numbers, so that IP numbers with a good reputation won't get blocked as easily like a strange (not known) IP number, not used before or from foreign countries.
0
Connie, go away. The consensus is that we use that FEATURE often when passwords are forgotten. I use it several times a month. WITH MY USERS PERMISSION. It should be put back. It is not a security issue. Possibly you don't hire trustworthy employees, but I do.
0
I totally agree with this. We can determine our own security policies for our installation. This is the best idea here so far.
1
I agree with the majority this is ludicrous. We host email for multiple companies - we're not responsible for password policies used by individual clients, and this has made Smatermail a very poor choice for Enterprise.
 
In order for us to administer the system effectively, we now have to keep a note of every account on a separate file, or else face resetting accounts on multiple systems (phones, PC's, Tablets) over the phone with people who aren't technically minded. This completely defeats the point of your "security" implementation.
 
Had I known this essential feature had been removed, I would never have upgraded and wasted my money. We're seriously having to consider a downgrade or spending even more money on an alternative just to prevent massive support overhead.
 
Very disappointing, we won't be back after all the hassle this has caused. 10 years of goodwill flushed down the toilet, well done ST.
1
I am so on the fence about this. Both sides on this issue have so much merit. Security vs. ease of administration - I'm not making light of it.
 
As long as email admins have scruples, showing the password is OK. It's those who've gone rogue, so to speak, that users need to be protected from. And they are certainly out there.
 
.. sigh ..
 
 
3
I understand why Smartertool want to reach this forced security. Competitors would always point on a weak security.
 
So it's good to have v16 now on a reliable stable base.
 
My suggestion: 
Customers who explicitly want this feature to recover the users password without resetting it should be able to install a (third party) tool, that is connected over a special "password-events API" to Smartermail.
When installed, configured and connected Smartermail will continue to store salted hashes and absolutely no clear text password. The only thing it does is to send every added or modified password along with it's username to this external tool. (Eventually Smartermail could enforce an automatic notification for the user that his password was stored in a recoverable way with an option to disable this for further changes)
This external tool has either an accept- or ignore-list (depending if the customer want to default ignore or accept) and keeps a record for all (accepted) passwords. 
Ideally it would store the passwords in a recoverable encrypted form, with a not locally stored master password. 
 
This way Smartermail per definition is secure. 
0
Derek Curtis Replied
7/12/2017 at 7:20 AM
Employee Post
Ross: See Andrea's post a few above yours:

To enable the feature in 15.x and 16.x, here's what to do:

Stop the SmarterMail service FIRST.
Navigate to the Services folder. The default location is C:\Program Files (x86)\SmarterTools\SmarterMail\Service
Find the mailConfig.xml file and open it in an editor. (E.g., Notepad)
Find the following line:

<allowViewingOfPasswords></allowViewingOfPasswords>

Edit the value to turn ON this option.
Save the file.
Turn the SmarterMail service back on.

Once this is completed, you should have the ability to see the password for any mailbox when logged in as the Domain Admin and viewing a user's configuration settings.

So if you need it, you CAN turn it back on, even in 16.x. The steps, above, are the same in 16.x as they are in 15.x.
Derek Curtis COO SmarterTools Inc. www.smartertools.com
0
Good suggestion Markus. I would perhaps have thought of that if I could think so deeply. Seriously, thanks!
 
Now the next thing that has to happen is there needs to be that API (or does it already exist?).
0
Hi Paul, I've switched my 'vote' from show password to no. When Yahoo was hacked, and similarly the Federal OPM employee database was hacked, the intruders got their hands on a treasure trove of unencrypted information. The collective IT response by people like us was "irresponsible!" It'll be a royal PITA to manage without retrieving passwords, but it is the right call in my estimation. I agree with your sigh for sure. How many times a week do you get a call or email saying, "What's my email password again?" Drives me crazy!
0
Matthew, see Markus's thoughtful post below! Cheers.
0
Derek,
That news article looks like it deals with someone stealing. They "acted without authorization"

As stated above like another client -most of our client organizations are non profit organizations. There is no such thing as "private" emails. The non profit and other organizations that have service with us are the sole owners of all of the content and information that is used under their domain name. They have "Acceptable Use Policies" in place that state the organization can log into the emails at any time, for any reason and retrieve data or make any other use of it they want. That the email accounts are owned by and for the exclusive use of the organization and its needs. If employees, volunteers or anyone else need to send "personal" emails, sign up for anything, etc, they are to open a PERSONAL email account with some other provider like Gmail, Yahoo or whomever.

With this, in the past we have had to open an email account of a terminated executive, retrieve their password, and then use that same password to log into another organizations device in order to retrieve files from that device.

This previous executive was recently convicted of stealing over $500,000 from the non profit and is currently service jail time. Having access to the password was critical in being able to properly conduct the investigation.
www.HawaiianHope.org - Providing technology services to non profit organizations, low income families, homeless shelters, clean and sober houses and prisoner reentry programs. Since 2015, We have refurbished over 11,000 Computers !
0
Derek Curtis Replied
7/12/2017 at 1:01 PM
Employee Post
I understand your situation, Curtis, but another option would be to implement email archiving, either within SmarterMail itself or using another service. That bypasses the need for the user's password entirely. Just a thought...
Derek Curtis COO SmarterTools Inc. www.smartertools.com
0
+1
Back to Community Threads

Reply to Thread

Enter the verification text

Related Knowledge Base Articles

Windows Mail and SmarterMailSmarterMail > Desktop and Mobile Synchronization
Set up Autodiscover for SmarterMailSmarterMail > Installation and Configuration
Upgrading SmarterMail (Domain Conversion)SmarterMail > Installation and Configuration
Deploying Rspamd For Use With SmarterMailSmarterMail > Server Configuration and Management
Configure POP for iPhone, iPad or iPod TouchSmarterMail > Desktop and Mobile Synchronization