1

(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?

Update

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?

Improve this question
7
  • Physical intervention.. you mean for data at rest or data in motion?
    – ndrix
    Commented Apr 13, 2017 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
    Commented Apr 13, 2017 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
    Commented Apr 13, 2017 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
    Commented Apr 13, 2017 at 19:09
  • Use co-location. Host your own hardware there, in a locked cage
    – Neil McGuigan
    Commented Apr 13, 2017 at 20:50

1 Answer 1

Reset to default
3

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
1
  • 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
    Commented Apr 14, 2017 at 12:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .