encrypt the actual connection string in your web.config file

Discussion in 'Suggestions' started by MarkBrend, Aug 5, 2013.

  1. Hello,

    Unfortunately, you cannot encrypt the actual connection string in your web.config file, but you can encrypt the data itself.....

    REPLY ------------------


    I am very surprised :(

    Please add this functionality to your road map asap and please let me know when it is available.

    It would be great if all sensitive sections of the key configuration files ie webconfig were encrypted by default.
    This process is / could by transparent to anyone using the website and thus no reason not to do it.
    you could always give an option to turn encryption off for people that had special requirements.

    Of course sensitive data in the database should be encrypted but that would not stop someone who has gained access to the webconfig file connecting to the database and destroying tables or inserting code to trap information.

  2. I understand that from your perspective you see "no reason not to do it," but our perspective is not necessarily quite the same. From a security standpoint it may be, but from an operational, performance and support standpoint, we have a multitude of things to consider.

    Security is something we consider in every aspect of the service. But we have to balance security with usability. Adding another layer or step to working with configuration adds another layer of frustration for many users. I can certainly forsee a number of problems supporting/explaining it if it was done by default.

    So it would have to be an option. And we evaluate options according to whether the investment of resources on our end is justified by demand. In this case I'm afraid it isn't.

    At least so far anyway. Things could always change and we could be flooded with hundreds of requests a week for connection string encryption, in which case we would certainly offer it (honestly, if we had five or ten requests a week we'd probably offer it). But as of today, unfortunately, the demand just isn't there.
  3. Dude,

    All I see here is you using a whole load of words trying to justify why you don't want to do the correct thing.
    You are now aware of a security flaw in your service and you have a duty to fix it.

  4. Mark, it sounds like you have researched this, so I can only assume that you are aware that IIS prevents your web.config from being read or accessed via http. The only scenario in which it could be read is if someone had FTP access to your files (in which case I would respectfully suggest that you'd have a bigger problem than your web.config being exposed).

    That being said, I think your desire to have as much security wherever you can get it is reasonable, so I'll bring your request to the table and get some input from the development team here on the feasibility of making connection string encryption an option.

    If they see this first, they may reply directly. But if not, I'll get back to you on it.
  5. Great thanks for that...

    I am currently studying a security course on Pluralsight which has many seasoned developers creating the videos.
    So far they have all said encrypt.

    Plus the research I have done on the web says encrypt. http://hugoware.net/blog/is-encrypting-a-web-config-useful

  6. I am with Micheal on that one. I work at the National Defence and last year they asked us to encrypt all sensitive data. Since it is in effect, it is a nightmare for the developers. Like Micheal said, if someone is able to access your web.config via FTP you are in trouble. The web.config encryption is done from a Windows service command prompt and if you get access to that service any hacker with your account information can as well and run the command prompt to decrypt the file. Another thing to consider if you are also running a staging environment. The encryption is based on MachineKey wich you will have to synchronize with the Production and developers MachineKey. You could do it on your local if you could synchronize your local MachineKey with the hosting server MachineKey, but as a hosting provider, this is something I would not share with any one.

    My 2cents.
    ComputerMan and Michael like this.
  7. I would be very keen to see this functionality added to your services! Yes the risk of exploitation is low, but it is there. I wish to cover every security hole in my power, having my sql auth details in clear text just makes me feel uneasy. This would be one of the few reasons to setup a dedicated host instead.

    I obviously do not know your user demographics, but a one time setup hit for an ongoing commitment to security that you can market can only be a positive thing.

Share This Page