(Copied from Software Engineering as suggested)

If I have written a privacy tool as a .NET web application which is to be hosted on a commercial hosting site, other than hosting it in a privacy friendly country, how can I assure users that the application has not been compromised by a third party at the host?

Obviously SSL will be used, retained data will be strongly encrypted and the assemblies will be as obfuscated as possible, but these can only go so far.

I'm not concerned with hacking or legal challenges here, I'm specifically talking about physical intervention at the server location relating to modification of the site to capture user info.

For example, is there a way I can ensure that my assemblies haven't been wrapped to intercept plain-text credentials passed to an API?


I could maybe give an option for the user to supply their credentials already encrypted using my public key. This then opens the door to other options, like a 2-way handshaking type thing.

Are there any more elegant options?

  • Physical intervention.. you mean for data at rest or data in motion? – ndrix Apr 13 '17 at 18:36
  • Data in motion. The data at rest I can reasonably protect, I'm just worried about the initial user credentials supplied to the site which can be read by what is effectively a "man-in-the-middle" attack. – CompanyDroneFromSector7G Apr 13 '17 at 18:41
  • Wouldn't SSL provide an end-to-end encryption? Or would you be worried that the hosting provider could also issue fake certificates (i.e: in your name)? – ndrix Apr 13 '17 at 19:04
  • SSL is not completely end-to-end as it stops at IIS, which passes values in plain text to the site's main assembly. Whoever has access to the server could in theory wrapper the main assembly, and thereby read any plain text data passing through. This is not normally a problem if the server is secured, which it may not be in my case. – CompanyDroneFromSector7G Apr 13 '17 at 19:09
  • Use co-location. Host your own hardware there, in a locked cage – Neil McGuigan Apr 13 '17 at 20:50

If you cannot guarantee you are the only one who has access to the server itself you cannot ensure privacy to your users.

Wrapping an assembly is not necessary if someone who has access to the server wants to steal plain text credentials. They already have access to the server and thus access to the private key of the certificate. They could create a "legitimate" (to the end user at least) reverse proxy where they will terminate SSL and inspect plain text traffic. Using asymmetric encryption will not help either. Access to the server will grant access to the private key too.

One thing to consider if you have web hosting platform you can't (or don't want to) trust is to use client side encryption. But you can't do it in browser (JavaScript). Please see this for detailed explanation of problems related to browser encryption. In a nutshell, you can't trust JavaScript code that is served from a non trusted web host.

One possible solution is to use browser extensions. You can sign the extension with your own code signing certificate and thus users can verify the code came from you and it is not tampered with.

| improve this answer | |
  • The browser extension thing is similar to where I was going with the update; although my thoughts don't require a plugin, just a hard-coded private key in the dll and the users' own installation of gpg or similar. Thanks. – CompanyDroneFromSector7G Apr 14 '17 at 12:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.