You use Microsoft Visual Studio 2010 and Microsoft .NET Framework 4 to create an application.The application connects to a Microsoft SQL Server 2008 database.
The application uses a Microsoft ADO.NET SQL Server managed provider.When a connection fails, the application logs connection information, including the full connection string.The information is stored as plain text in a .config file.
You need to ensure that the database credentials are secure.
Which connection string should you add to the .config file?
A.Data Source=myServerAddress; Initial Catalog=myDataBase; Integrated Security=SSPI; Persist Security Info=false;
B.Data Source=myServerAddress; Initial Catalog=myDataBase; Integrated Security=SSPI; Persist Security Info=true;
C.Data Source=myServerAddress; Initial Catalog=myDataBase; User Id = myUsername; Password = myPassword; Persist Security Info=false;
D.Data Source=myServerAddress; Initial Catalog=myDataBase; User Id = myUsername; Password = myPassword; Persist Security Info=true;
According to the guide, the answer is 'A'. But in my opinion, the Answer is 'C'. If we are using Integrated Security = SSPI, we don't need to supply UserID and Password. So, Persist Security Info=false has no effect.
As far as I know, Persist Security Info only takes effect if the connection string has User Credentials.
Could you please advise me which one is correct? Thanks.
You are right. Persist Security Info=false has effect only if user name and password provided in connection string. But question is "What should you store in .config file" and considering that "information is stored as plain text" you should not store UID and PWD in config file.
If you store C, PWD and UID can be extracted from .config file. But if you store A, there is no credentials to extract.
I'm not sure, why A has "Persist Security Info=false", but looks like it is a good practice.
See MSDN examples:
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring(v=vs.71).aspx
http://msdn.microsoft.com/en-us/library/ff647552.aspx
Related
For the properties:
Persist Security Info=true
and
Persist Security Info=false
Can you tell me what is the difference between them, and if I don't put it in my connection what will happen?
connect.ConnectionString = "Provider=Microsoft.ACE.OLEDB.12.0;
Data Source=C:/Users/Nourah/Downloads
/Phase3/Salary.accdb;
Persist Security Info=False;";
Even if you set Persist Security Info=true OR Persist Security Info=false
it won't show a difference up front. The difference is happening in the background.
When Persist Security Info=False, security-sensitive
information, such as the password, is not returned as part of the
connection if the connection is open or has ever been in an open
state.
If you set Persist Security Info=True, Windows will remember the password specified in the connection string.
That's the difference.
MSDN Explanation
Setting Persist Security Info true or false will come into effect only if you mention username and password in the connection string. If you mention username and password in the connection string and set Persist Security Info as false then the credentials cannot be extracted, but if you set Persist Security Info as true while giving credentials in the connection string, windows will remember the credentials, and it can be extracted programmatically.
I found this answer here from Dan Guzman, SQL Server MVP:
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.
I am running Microsoft SQL Server 2014.
I try to connect to SQL Server using ADO.NET in a C# application.
My connection string is:
var myConnection = new SqlConnection("Data
Source=VIRTUAL-ADMIN\\SQLEXPRESS;" +
"Integrated Security=SSPI;" +
"Initial Catalog=StudentManagement;"+
"User id=...;"+
"Password=...");
My Initial Catalog is a right and existed database.
But my username is a wrong username!
The Password I have inserted is also wrong already.
But ADO.NET still connected to my database and I can execute query and do everything with my database.
How can I fix it?
You have provided both Integrated Security=SSPI; as well as username & password so it by default takes integrated Security i.e. windows authentication and thus you are able to connect with wrong credentials as well.
So, either user Integrated Security or your credentials as you do when connecting to SSMS, when it asks for either Windows authentication or SQL Server authentication
From MSDN:-
Integrated Security When false, User ID and Password are specified in
the connection. When true, the current Windows account credentials are
used for authentication.
i have one ASP application and i want to use that for 2(or more) place and each of them has their Database , now is there a way to change connection string when user log in?
or anyway to change database for each user?
i saw this question before
How to setup single-code multiple-database ASP.NET SaaS application
but i couldn't figure out how it works!
please help me
EDITED:
I found a way for this problem
I saved my connection strings on database for each user, after identification i will figure out which connection string is for this user, and then assign that to my data sources an etc ...
saved connection string
"Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=DB;Data Source=."
ASP
<asp:SqlDataSource ID="DataSource" runat="server" ProviderName="System.Data.SqlClient </asp:SqlDataSource>
C#
DataSource.ConnectionString = "Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=DB;Data Source=.";
For Linq to SQL
DataClasses1DataContext m = new DataClasses1DataContext("Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=DB;Data Source=.");
i hope useful for other which has this issue
In multi-tenant SaaS solutions it's very common to have multiple connection strings depending on the user tenancy or account.
You simply need to stop storing the connection string in the web.config file and start building them dynamically at runtime, preferably through a helper class, based on your criteria (logged user, account, tenancy...).
I have been trying to understand what using trusted_connection=true in a SQL Server connection string (from within C#) means. I understand that it uses the current Windows user credentials to connect to the database. But does it mean the database server and the current user can be in different domains, same domain or in different but trusted domains ?
trusted_connection=true means Integrated Security=SSPI;
If this is not present in connection string then you need to specify userid and password in connection string as:
server=yourservername;database=yourdatabase;user id=YourUserID;password=password
If any of two (Trusted_Connection=true or Integrated Security=true/SSPI) is present , then the Windows credentials of the current user are used to authenticate against SQL Server and any useriD=userid and password=password text will be ignored.
Whichever number of users may present and fromwhichever user you may have logged in, it will ignore the stuff if:
Trusted_Connection=true
I changed my project connection string through Code, as a result, Connection strings in all Config files changed. but problem is here that in datasets, some tables have different connection strings:
app.config connection string: "Datasource=USERPC; initial Catalog=MYDataBase; integrated security=False; User ID=sa; Password=user"
tablAdapter Connection string: "Datasource=USERPC; initial Catalog=MYDataBase; integrated security=False; User ID=sa"
what is my problem and How can i do solve it?
Go to Project Properties -> Settings Tab set there Connection String Value to application level instead of app.config. If you are using typed dataset the connectionstring defined by them itself so better do not alter them. For using conenctionstring in you code. Go directed as above. Then create a property or function that will access the value using Settings CLass.
In vb we use My.Settings.Default.ConnStringName
Are you sure, that your connection strings won't work. Cause all what is missing is the password and if i remember correctly if you fill in a password and read the connection string afterwards back you won't see the password anymore. But that's not a bug, it's a security feature.
To override this behavior you should take a look into the Remarks section of the SqlConnection