PBA Posted March 9, 2021 Share Posted March 9, 2021 Hello, Is there any chance we can get the Self destruct Message function like the "old" situation? (without the app server part). In the context of security is the "new" situation not secure for us. We had everything configured so Passwordstate can be reached internal only. And the Self Destruct Message site as a DMZ so external systems are able to reach the Self Destruct Message site only and NOT Passwordstate which is for internal use only. This is not possible in the new siuation which requires constant connection to Passwordstate and we are not happy about it. Can you provide us a solution, please? Link to comment Share on other sites More sharing options...
support Posted March 9, 2021 Share Posted March 9, 2021 Hello PBA, Unfortunately we can no longer provide this - for various reasons, customers had many issues getting the old installation working i.e. load balancers, reverse proxies, etc, so we had to change the architecture for this feature. You can encrypt settings in your web.config file if you like, and this is documented in the installation guide - https://www.clickstudios.com.au/downloads/version9/Passwordstate_App_Server_Install_And_Administration_Guide.pdf Regards Click Studios Link to comment Share on other sites More sharing options...
RobMiller Posted March 10, 2021 Share Posted March 10, 2021 We were just about to migrate to a separate self destruct portal and VPN only access to the passwords via mobile. I just upgraded to V9 in prep and was reading about the changes and see that is apparently no longer possible in V9. What a huge disappointment. So now if we want to use self destruct, and if we want mobile access, we have no choices. Open it up to the internet and don't use a VPN. I sure would like to understand the rationale behind greatly limiting our ability to secure this sensitive data. This forces us to simply trust that Click Studios won't have any vulnerabilities in their code. Not sure I even understand the point of a self destruct portal anymore since it also handles mobile access to Passwordstate. Link to comment Share on other sites More sharing options...
support Posted March 10, 2021 Share Posted March 10, 2021 Hi Rob, You can still place your Passwordstate App Server behind your VPN - have you found some documentation which states otherwise? You can also have multiple installs of the App Server if you like i.e. one for mobile access, and one for Self Destruct. And you do not need to use the Mobile App functionality that comes with the App Server. By default, you cannot use it unless you configure some System Settings to enable it. And you can also prevent all users from using it on the screen Administration -> Feature Access -> Mobile. With our installation guide, it also recommends encrypting settings in your web.config file - for improved security. During the beta phase of version 9, we partnered with an external security penetration testing company, and they spent two weeks thoroughly testing the new App Server, and native Apps, and found no issues at all. In fact, we had to remove two layers of security from the Apps, just so they could do any testing. So we can assure you, that we have taken every care to ensure the new App Server is secure. Regards Click Studios Link to comment Share on other sites More sharing options...
RobMiller Posted March 10, 2021 Share Posted March 10, 2021 So I can have one app server that only works for mobile access, and nothing else. And then I can have another one for self destruct and nothing else? The self destruct portal will be unable to be exploited and then used to access passwords? My goal is to have self destruct for clients without a VPN, and then no ability to access passwords without a VPN. Meaning that self destruct portal simply cannot be used in any way, even if breached, to attack the passwordstate server. That's still possible? The post above leads me to believe it's not possible. To be clear, we want mobile access, but we want to require a VPN for it, and we want the self destruct portal to have no ability to access passwords that aren't currently on it waiting to self destruct. Link to comment Share on other sites More sharing options...
support Posted March 10, 2021 Share Posted March 10, 2021 Hi Rob, Yes, you can have separate installs for this purpose. The only people who can access the Mobile portion of it, is your internal staff who can scan the QR Code on the mobile phones, from the Preferences screen. And this is linked back to the URL you specify for the App Server, on the system settings screen. As mentioned, we have done everything possible to make the new App Server as secure as possible. Ultimatley it will be up to you to perform your own security assessment, if you need this reassurance. Regards Click Studios Link to comment Share on other sites More sharing options...
RobMiller Posted March 10, 2021 Share Posted March 10, 2021 I understand that I can enable or disable mobile access. I am still concerned that the app server is not isolated like the previous self destruct portal and if compromised, has full access to passwordstate. Specifying different URLs in the config doesn't actually disable the app servers ability to access password state if it's compromised via a vulnerability. Our requirements: 1. An App Server for Self Destruct open to the internet. This server should have zero ability to access passwordstate, even if compromised and an attacker has bypassed authentication in some way. We would like to block this servers ability to even initiate connections to passwordstate at the network level. 2. A Mobile Access App server behind a VPN that does allow access to passwords via passwordstate Can you provide guidance on how we achieve #1 so that if an attacker somehow bypassed auth and fully compromised the app server for self destruct that they wouldn't have access to passwords in passwordstate? Can the App Server still work for Self Destruct if it's firewalled off from the passwordstate server like was previously possible with self destruct portal? Link to comment Share on other sites More sharing options...
support Posted March 10, 2021 Share Posted March 10, 2021 Hi Rob, Unfortunately what you are asking in Number 1 is no longer possible in version 9 - the App Server needs to communicate to your Passwordstate database - for which, the contents are encrypted, and can only be decrypted via our assemblies. As you are an MSP, is there an option to limit access to your Self Destruct URL to your customer's firewalls i.e. IP Address restrictions - just a suggestion. Regards Click Studios Link to comment Share on other sites More sharing options...
RobMiller Posted March 10, 2021 Share Posted March 10, 2021 That would be far too difficult to use an IP based ACL on the self destruct portal for us. MSPs are getting hit left and right. We have to do all we can to plan for a breach via a compromised system and one with open inbound access from the internet is certainly a candidate to be compromised. I'll have to carefully consider our options here since there is no way to disallow communication from the self destruct portal. Link to comment Share on other sites More sharing options...
support Posted March 10, 2021 Share Posted March 10, 2021 Sure, we understand Rob. Thanks very much. Regards Click Studios Link to comment Share on other sites More sharing options...
PBA Posted March 11, 2021 Author Share Posted March 11, 2021 Hello, Sorry for the delayed reaction. Thank you Rob, this is exactly what I mean. It was one of the major reasons we are using Passwordstate. Maybe you guys can consider bringing the function back, I think many of your customers are thinking the same way. Link to comment Share on other sites More sharing options...
RobMiller Posted March 11, 2021 Share Posted March 11, 2021 I just completed our migration to V9 with an App Server for self destruct and mobile access. Passwordstate itself is now blocked from offsite access. I guess we are going to setup a 2nd Passwordstate server and move our own critical infrastructure creds to this 2nd one and it will not have mobile access, self destruct, or external access. It seems we aren't allowed however to setup a 2nd instance per the licensing so we will be limited to 5 free user accounts on this second deployment. But in the end, the risk was too great for us to have both client passes, as well as our own infrastructure passes for our private cloud services in the same basket. I wish Passwordstate would allow us to deploy a second instance for the same users we already pay for. Link to comment Share on other sites More sharing options...
Moiz V Posted March 16, 2021 Share Posted March 16, 2021 Hey guys, I would just like to echo the OP; it seems like a serious security regression. Are you guys willing to provide details of the pentesting that was done along with who did it? For a security product I think that'd be pretty important. Also, is there any capability to use a read-only SQL account from Self Destruct to the passwordstate database and\or limit permissions in SQL in any other way? Link to comment Share on other sites More sharing options...
support Posted March 16, 2021 Share Posted March 16, 2021 Hello Moiz, We are under an NDA for the penetration tests we arrange, meaning we are unable to share results of this. In theory, you could use an account which only has read access to the database, but there are a couple of tables which would require separate 'UPDATE' permissions to those tables only i.e. SelfDestruct and QueuedEmail. Is that acceptable, because in theory the other tables could still be read? We'll try and have a look to see if access can be removed from all other tables, but it might take us some time to look into that. We have spent months re-developing this feature, and we do not have any plans to revert back to the old method. Ultimately you will need to decide whether you wish to use this feature or not. Regards Click Studios Link to comment Share on other sites More sharing options...
Martin W. Posted March 18, 2021 Share Posted March 18, 2021 We are also very upset about this change. This function (and especially the way it works) was one of the main reasons why we chose this product. In our data center we are bound to strict IT security compliances. So if that is the final statement from clickstudios, we are forced to look at other products, too bad. Fortunately, this change came before we were buying additional instances for our customers. Amazing that nobody from clickstudios sees that the new architecture building a bridge between the Internet and the Passwordstate database and that these are for some customers a security issue. Link to comment Share on other sites More sharing options...
Moiz V Posted March 18, 2021 Share Posted March 18, 2021 On 3/16/2021 at 4:55 PM, support said: In theory, you could use an account which only has read access to the database, but there are a couple of tables which would require separate 'UPDATE' permissions to those tables only i.e. SelfDestruct and QueuedEmail. Is that acceptable, because in theory the other tables could still be read? We'll try and have a look to see if access can be removed from all other tables, but it might take us some time to look into that. I think this would be reasonable if we can lock down access only to the specific tables required. Link to comment Share on other sites More sharing options...
support Posted March 19, 2021 Share Posted March 19, 2021 Hi Guys, We appreciate the feedback. The Pen Testing company do not believe this architecture is insecure, but if there is enough interest, we can consider other options. So we can take this feedback to management, can you please outline why you believe this is a security regression? Is your concern you may have an elevated administrative breach on your web server where this is being hosted? Regards Click Studios Link to comment Share on other sites More sharing options...
Moiz V Posted March 19, 2021 Share Posted March 19, 2021 Honestly, the main reason is that we now have to secure access to the SQL database server. If the Passwordstate database is co-located with other databases (typically to make maximum use of Microsoft's expensive per-core SQL licensing) this now expands the potential attack surface of the environment to "everything that uses SQL" instead of just Passwordstate. Also ideally you want one-way communication from PasswordState web server (trusted) to Self-Destruct server (untrusted) only. I get that this still means there's an SQLite database sitting on the Self-Destruct server in some form (ideally only containing the SelfDestruct and QueuedEmail tables), but at least a compromise means 0 access to the rest of the PasswordState database, as well as potentially other databases. Just my $0.02. Link to comment Share on other sites More sharing options...
support Posted March 19, 2021 Share Posted March 19, 2021 Thanks Moiz. It seems we have about 3 votes for this feature request, so we will continue to monitor. We will also move this to the feature request section, so other customers see it. Regards Click Studios Link to comment Share on other sites More sharing options...
jtstuedle Posted March 20, 2021 Share Posted March 20, 2021 What if you never had to expose any portion of your PasswordState infrastructure directly? Any layer 7 load balancer should be able to add a layer of security here (I'd suggest the open source version of HAProxy if you don't have an existing load balancer for your external network). You can also use URL rewrite rules in IIS (look near the bottom of the MS page below) to restrict or allow specific IP addresses from accessing portions of the Passwordstate instance (the selfdestruct portal is self contained wholly to /selfdestruct/*). You can get pretty creative and only allow specific vlans to access the /selfdestruct/* portion of the site, while letting your IT vlan hit the entire site. Useful if you have sections of your network that you'd like to use the selfdestruct portal with, but don't want those same devices accessing the whole instance. https://docs.microsoft.com/en-us/iis/extensions/url-rewrite-module/creating-rewrite-rules-for-the-url-rewrite-module Maybe Passwordstate support could publish details on the exact tables in the database that the App Server needs read/write access to. You could use a separate SQL user that had explicit read/write permissions for this functionality only as an additional layer of security. IMHO, there are ways you can architect and securely design the service that make it no more risky than having your VPN endpoints exposed to the internet. Link to comment Share on other sites More sharing options...
Greg B Posted March 21, 2021 Share Posted March 21, 2021 The current Passwordstate Security Administrators Manual makes this confusing. I think it is describing the old setup. 2.31.19 Self Destruct Messages Quote There is a specific Self Destruct Message web site that recipients access via a link for their email,and this web site is embedded by default in your main Passwordstate web site i.e.with /selfdestruct at the end of your URL, or we provide a separate installer for the site so it can be installed in your DMZ. The Self Destruct Message web site does not need any access back to your main Passwordstate web site, as it is your instance of Passwordstate which pushes and pulls all data to the Self Destruct site. Link to comment Share on other sites More sharing options...
support Posted March 22, 2021 Share Posted March 22, 2021 Thanks Greg, and it looks like we've overlooked updating that in the Manual - we will do that right now. The wording on the screenshot in the manual is correct, but we overlooked updating the text. Regards Click Studios Link to comment Share on other sites More sharing options...
support Posted March 22, 2021 Share Posted March 22, 2021 Hi jtstuedle, Thanks very much for your support - we appreciate it. From where the Self Destruct Web site is installed, it requires the following access back to the SQL database: SelfDestruct - Read/Update/Delete DebugInfo - Insert SystemSettings - Read Auditing - Add QueuedEmail - Insert Regards Click Studios Link to comment Share on other sites More sharing options...
SZU Posted March 22, 2021 Share Posted March 22, 2021 Supporting all opinions(PBA, RobMiller, Moiz V, Martin W.). Voting for bringing back option Self Destruct Message function without the app server part. Link to comment Share on other sites More sharing options...
Dan Gerhart Posted March 26, 2021 Share Posted March 26, 2021 I too am voting to bring back the Self Destruct Message function without the app server part. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.