avoiding the hardcoding of passwords

Discussion in 'Databases' started by rmvanduyn, Sep 14, 2006.

Thread Status:
Threads that have been inactive for 5 years or longer are closed to further replies. Please start a new thread.
  1. rmvanduyn

    rmvanduyn

    Bruce,

    Thanks for info, it does make me feel a bit more comfortable.

    But the one problem would seem that if someone got ahold of the ftp password, then all would be lost.

    The reason this in particular concerns me is that apparently the ftp password is shipped around the universe in plain text during operations in Visual Studio or even when simply browsing the site using internet explorer.

    Mitch
     
    rmvanduyn, Sep 14, 2006
    #1
  2. wisemx

    wisemx

    Bruce,we could create a support ticket and request a SQL password that differs from our account password, correct? [​IMG]
     
    wisemx, Sep 14, 2006
    #2
  3. rmvanduyn

    rmvanduyn

    Does anybody know of a technique where I can avoid hard coding the SQL server password in my web.config file (or any other unencrypted file for that matter?)

    I can't figure out any way to do this, that wouldn't leave a password lying around somewhere in a file. And this seems very risky.

    I guess there is some technique using registry entries... would that be available to a discountASP user?

    Thanks
    Mitch
     
    rmvanduyn, Sep 14, 2006
    #3
  4. Bruce

    Bruce DiscountASP.NET Staff

    putting your connection string and password in the web.config is relatively safe.

    Why?

    1) Youcannot download web.config off the web. IIS is configured to block web.config download

    2) Other user on the server cannot access your web.config through file system. Our servers are configured to run each site with unique permission and it is not possible for you to do crosssite access. (with the exception of when you have FrontPage installed because the crappy FrontPage extension always mess up NTFS permssion and the extension will add Interactive / Network Read permission to your site)

    Bruce

    DiscountASP.NET
    www.DiscountASP.NET
     
    Bruce, Sep 14, 2006
    #4
  5. Bruce

    Bruce DiscountASP.NET Staff

    Mitch: you are absolutely correct but in the same token, it someone get a hold of your SQL password (which is equally possible), they can still access your DB.


    In truth, hosting on a shared server, though relatively secure, is not always the most secure option. If you want absolute security, both the web / SQL server need to be dedicated and put behind a firewall where you can't even get FTP access.


    wisemx: actually, you can change your SQL account password in the SQL manager in the control panel.


    Bruce

    DiscountASP.NET
    www.DiscountASP.NET
     
    Bruce, Sep 14, 2006
    #5
  6. wisemx

    wisemx

    ...Cool bro. [​IMG]
     
    wisemx, Sep 14, 2006
    #6
  7. rmvanduyn

    rmvanduyn

    I just found this article:

    http://msdn2.microsoft.com/en-US/library/dtkwfdky.aspx

    Which talks about using encrypted sections in the web.config.

    That's sounds like a great solution to the problem (and the one recommended by Microsoft in several places.)

    Will discountASP support this?

    Cheers
    Mitch

    Post Edited By Moderator (Joel Thoms) : 9/15/2006 10:36:46 PM GMT
     
    rmvanduyn, Sep 15, 2006
    #7
  8. wisemx

    wisemx

    They had mentioned before that we aren't allowed to encrypt our configs.
    Prior to that I had planned on using Scotts little encrypting trick too.
     
    wisemx, Sep 15, 2006
    #8
  9. joelnet

    joelnet

    I think someone said you aren't able to, not you're not allowed.


    I believe someone has been able to do this (in a hosted environment). Though I believe the method still wasn't very secure, if someone had access to your web.config, they'll have access to decrypt your web.config also.


    I haven't tested this, so I don't know if it works.



    Joel Thoms
    DiscountASP.NET
    http://www.DiscountASP.NET
     
    joelnet, Sep 15, 2006
    #9
Thread Status:
Threads that have been inactive for 5 years or longer are closed to further replies. Please start a new thread.

Share This Page