none
Persist Security Info

    Question

  • Hi,

    Can someone explain to me the use of Persist Security Info = 'TRUE' on the SQL connection string from a DOT NET application. All microsoft documentation and best practices say that this should always be set to 'FALSE', but we have a publicly available Web application where the with SQL connections from the DOT NET applications installed on IIS. The SQL server itself has a CERT configured so I assume the connections are going to over a Secure channel.

    So, should I set Persist Security Info = 'FALSE'? What are recomended practices? Why do we have Persist Security Info = 'TRUE' when it is recomended to keep it to 'FALSE'?

    Thanks,

    Venky

    Friday, February 17, 2012 5:19 PM

Answers

  • This is a precautionary security measure. Having this setting set to True will allow the source access to user and password info once you open the connection. Setting it to False is just one more way to secure your installation. Even if your Web app is publically available I am sure you don't want people messing with your DB in ways that might be annoying or destructive.

    I am sure setting Persist Security Info to True makes sense in certain scenarios, but the overall trend and recommendation for production environments is to set it to False. I should note that False is the default setting, so you can leave out the explicit setting from your connection string. Regards, Saga


    Insanity is the prelude to discovery

    Friday, February 17, 2012 6:04 PM

All replies

  • This is a precautionary security measure. Having this setting set to True will allow the source access to user and password info once you open the connection. Setting it to False is just one more way to secure your installation. Even if your Web app is publically available I am sure you don't want people messing with your DB in ways that might be annoying or destructive.

    I am sure setting Persist Security Info to True makes sense in certain scenarios, but the overall trend and recommendation for production environments is to set it to False. I should note that False is the default setting, so you can leave out the explicit setting from your connection string. Regards, Saga


    Insanity is the prelude to discovery

    Friday, February 17, 2012 6:04 PM
  • Hi,

    Thanks for the reply. In terms to the application design / performance does it make any difference between keeping this parameter TRUE / FALSE? I mean if I change the parameter to FALSE, can I assume that there won't be any side affects because of this? Why I ask this question is because I puzzled why in first place we have this parameter with a option to TRUE (as you say "Persist Security Info to True makes sense in certain scenarios" ... what scenarios?? Have you come across one??) when everywhere I see people saying it should be set to FALSE in a production environment?

    Thanks,

    Venky

    Friday, February 17, 2012 7:43 PM
  • The only scenario that comes to mind where Persist Security Info=True can be useful is during development. I hope others chime in since I think it is a valid question that should be discussed more so that we can see what others are doing when they set this parameter to True.

    As far as I know, aside from security, setting this to either True or False does not affect anything. Saga


    Insanity is the prelude to discovery

    Friday, February 17, 2012 8:14 PM
  • Hello,

    I am using only the System.Data.Sqlclient namespace but i have checked that if you are using the SqlConnectionStringBuilder class ( a similar class exists for other protocols ) , the connection string you can create and pass as parameter to the SqlConnection does not permit to see the password as soon as the connection is open ( with False or True as value for Persist Info ).The property "Password" is not returned.... It is true since SQL Server 2008 ( but before i have no older version of SQL Server to check )

    I know only one way to get the password : it is thru The ConnectionManager class of the SMO namespaces, but, in theory, nearly nobody is using them except DBAs to modify or explore SQL Server instances or databases.

    Have a nice day


    Mark Post as helpful if it provides any help.Otherwise,leave it as it is.

    Sunday, February 19, 2012 11:12 AM
    Moderator
  • Hi,

    So basically this parameter doesn't have any significance. We're on SQL server 2008 R2 release. So, I can safely remove them and not worry about them causing any issues. I was just worried about why we're having then on the connection strings when everyone seems to say that it should always be set to FALSE in a production deployment.

    Thanks,

    Venky

    Sunday, February 19, 2012 11:32 AM
  • I suggest you specify FALSE or omit the keyword entirely since it is the default, even during development.  The only time you need to specify TRUE is if the application uses SQL authentication and subsequently retrieves the password from the connection object, which in my experience is rarely done or needed.  Performance is not a concern.


    Dan Guzman, SQL Server MVP, http://weblogs.sqlteam.com/dang/

    Sunday, February 19, 2012 1:34 PM
    Moderator