If you use SQL Server Authentication (2005), are the login details sent in clear text over the wire?
As secure as you want to make it...
you can configure SSL fairly easily, and if you don't have a trusted cert, if you force encryption, SQL Server can create/issue it's own self signed cert for your use...from this write-up
Credentials (in the login packet) that
are transmitted when a client
application connects to SQL Server are
always encrypted. SQL Server will use
a certificate from a trusted
certification authority if available.
If a trusted certificate is not
installed, SQL Server will generate a
self-signed certificate when the
instance is started, and use the
self-signed certificate to encrypt the
credentials. This self-signed
certificate helps increase security
but it does not provide protection
against identity spoofing by the
server. If the self-signed certificate
is used, and the value of the
ForceEncryption option is set to Yes,
all data transmitted across a network
between SQL Server and the client
application will be encrypted using
the self-signed certificate
Whether or not the login credentials are encrypted depends on the encryption capability/configuration of the client and server.
At the protocol level, completely unencrypted SQL logins are allowed, though my guess is that these are rare because I suspect most modern database drivers do not support them.
Details
Clients communicate with Microsoft SQL Server using the Tabular Data Stream (TDS) protocol.
Shortly after a client opens a TDS connection to the server, it informs the server of its encryption capability. The server compares this announcement with its own configuration/capability to determine the encryption state for the connection.
In a nutshell, the encryption state is determined as follows:
If client or server announces that they do not support encryption and the other side does not require encryption, the entire connection—including login—will be unencrypted.
If both client and server announce that they support encryption but do not require it, just the first TDS packet of the login request will be encrypted. The remainder of the connection, including any additional login request packets, will be unencrypted. A properly-designed database driver will ensure that the SQL authentication password is placed in first login packet, but this isn't required at the protocol level.
If either client or server announces that they require encryption, the entire connection will be encrypted (except for a small amount of preliminary data) unless the other side does not support encryption. In that case, the connection will be terminated.
The only way to ensure that login requests are always encrypted is to set the 'require encryption' option on either client or server. There’s no option to disallow completely unencrypted connections without requiring full encryption.
Regardless of whether or not the login or connection is encrypted, the SQL authentication password is always obfuscated but the scrambling is easily reversible.
Further Reading:
Technical details on connection encryption states - MS-TDS 2.2.6.5 PRELOGIN (under heading Encryption)
Password obfuscation formula - MS-TDS 2.2.6.4 LOGIN7 (see last paragraph)
Slightly more in-depth write-up on the topic - SQL Passwords: Encrypted Between Client and Server? (disclaimer: this is a post on my blog)
The credentials are sent in clear text.
You can probably find a number of sources for this, but here's one:
"Secure the channel between the Web server and database server because credentials are passed in an unencrypted format. For example, use SSL or IPSec."
Here's a link to some security best practices for SQL 2005. That doc states in part:
In Windows Authentication mode,
specific Windows user and group
accounts are trusted to log in to SQL
Server. Windows credentials are used
in the process; that is, either NTLM
or Kerberos credentials. Windows
accounts use a series of encrypted
messages to authenticate to SQL
Server; no passwords are passed across
the network during the authentication
process. When SQL logins are used, SQL login passwords are passed across the network for authentication. This makes SQL logins less secure than Windows logins.
Reading this thread made me even more confuse then I was!
Anyway, I did some tests with Wireshark, with or without encrypted connection I was never able to see my password (and my user name I think). What was very visible without encryption is the actual queries.
Perhaps it is the lack of knowledge with Wireshark to retrieve the login credentials, but since I was able to see everything else I'm pretty sure I was looking at the right spot and the password was ALWAYS hidden.
Apart from the fact that passwords are sent in clear text, it is also possible to replace the hash of the password.
Related
I am trying to establish a secure connection to a SQL Server database over the internet. In the link below a configuration "Encrypting Specific Connections" is described:
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html
I have read elsewhere that mutual authentication (server authenticating the client based on certificate) is not supported by SQL Server. Is the described configuration equivalent to mutual authentication or something completely else?
If it is something else, are there other security features of RDS (apart from ip whitelisting) that can increase security over username and password?
Edit: The connection will be encrypted, so when i say increase security i mean in the sense that would work as a second factor of authentication.
I wanted to read AWS Postgresql from within SQL Server, so
I created a system ODBC connection to Postgresql on the SQL Server machine, tested it, fine.
I then created a Linked Server to connect to postgresql.
In the Security tab (For a login not defined in the list above, connections will), I selected "Be made using the login's current security context".
When using this linked server while connected to SQL Server through windows authentication, it works fine.
If I connect to SQL Server using a SQL Server authenticated account, trying to access postgresql data through that same Linked Server fails authentication.
I fixed that by switching my security setting to "Be made using this security context" and giving the POSTGRESQL login/password (same that I gave at the ODBC level).
Question:
Without repeating the postgresql details at the Linked Server stage, why is it working with Window sauthentication account and not for SQL Server authenticated accounts?
Neither are relevant to Postgresql?...
I made it work but still confused...
I will have to guess a bit to help you, but I hope to give you enough context to understand what is happening so you can debug further.
When you connect to SQL Server using integrated authentication, the domain controller gives out a token to talk to SQL and this is used to authenticate your connection from your client to SQL Server's process. Underneath the covers, Windows can use either NTLM or Kerberos to do this handshake. You can read more about this here in this blog post:
NTLM vs. Kerberos Blog. This protocol choice matters when trying to use linked servers since it has to then authenticate to something else over the network.
At this point, it matters what credentials are used to run SQL Server (usually as a service in the services window to see). If you are running SQL as Local System or Network Service or something else defined by windows (instead of as a specific user on the network), it may or may not have permissions to talk out to your target remote server (whether it be postgres or something else). When you use Kerberos and enable delegation (which the domain admin needs to do), you can have the original integrated auth credentials "flow" over the linked server link to the next connection. NTLM does not do this. Therefore, the usual scenario is to create a map in the local SQL Server of what credentials to use when talking out to a remote linked server.
If you are talking to an ODBC driver, then you are likely using the msdasql (OLEDB to ODBC bridge) provider and then also having to go through its authentication stack. It has been too long for my memory as to whether it even supports integrated auth at all, much less delegation in Kerberos. However, you may be able to debug this problem further if you:
consider which account is running SQL
consider which mechanism is used to do integrated auth to sql and whether that would work with delegation
determine which credentials are used to make the outbound connection to your ODBC target. You should be able to debug much of this through the profiler mechanism as there is a distributed query/linked server set of events IIRC.
I can't speak to your postgres provider specifically, but this should give you some more tools to debug. Hope that helps you get one step further.
I am currently new to managing databases hence the question. From my lecture notes, it states that
A user logs into the network, Windows or otherwise.
The user opens a nontrusted connection to SQL Server using a username and password other than those used to gain network access. It’s called a nontrusted connection because SQL Server doesn’t trust the operating system to verify the user’s password.
SQL Server matches the username and password entered by the user to an entry in the sys.syslogins table.
My question is that how does the user open a nontrusted connection to SQL? I'm confused. What does it mean by SQL Server doesn’t trust the operating system to verify the user’s password.
Trusted connection is a legacy term and really a misnomer mostly because of how developers think of apps connecting to a database rather than how a database actually handles connection requests. SQL Server doesn't actually trusts connections. It trusts a 3rd party that you designated to authenticate a user and present the appropriate token it will then use for authorization. Just so happens Windows is the only 3rd party you can tell it to trust but it doesn't have to be.
Important things to distinguish in the process are authentication and authorization. Both SQL Server and Windows can authenticate a login attempt but only SQL Server can authorize access to objects/data. They are distinct though related parts.
When you connect using integrated authN, your security token is passed to SQL Server which then does basic checks for login mapping to establish connection. If successful, it goes on to do what it needs to for authZ(e.g. database context switch, authorization, etc...). It only cares that you have a valid token from a trusted source. In this case, it's Windows (simplifying the AD, Kerberos, etc... processes behind this). It doesn't further authenticate, it trusts that Windows has done the right checks already. Note that it doesn't have to be a network or domain user. Even local users can be setup for integrated authN but that's generally not a good idea.
If you connect with SQL Server credentials, after the pre-login handshake, your credentials are then passed to SQL Server for authorization where it'll check for login, compare password hash, policies (if any), etc... Essentially, the user authentication checks that Windows would have done when you login to a host but the security scope is SQL Server only. Until this authN is done, you are not logged in. These steps occur because the connection attempt is made with un-validated credentials rather than a secure token issued by a trusted party. Once it successfully completes authN then it goes down the same code path as before for authZ.
I have a SQL Server 2012 Standard hosted on a WIN 2008 R2 DataCenter 64 bit. I have a requirement to set the Force Encryption on the SQL Server to Yes, which is easy to do.
What I am needing help with is for the DoD Certificate requirement, where do I get the DoD Certificate from? and Do I just install it on the server where SQL Server resides?
I found this link , I wonder if I can use this:
http://dodpki.c3pki.chamb.disa.mil/rootca.html
Your hyperlink is not publicly available, however, since the name on the file is rootca.html it may contain information about how to get a root CA Certificate provisioned. When you use SQL Server Configuration Manager to set force encryption to true, you must either configure a certificate to use or the server will used a self signed certificate. The security concern with only setting this option and using a self signed certificate is that it leaves your server vulnerable to a man in the middle attack. The requirements for creating the certificate to be used for encrypting connections are on MSDN. I would recommend at least using a domain certificate generated by the domain certificate authority. You probably need to adhere to standards if this is for the DOD. Once the certificate and related private key are generated, they need to be added to the certificate store of the service account running the SQL Server database engine. After that, it can be selected for use in the configuration manager in the same dialog box as the force encryption option under a different tab. Once this is configured and the service is restarted, you can verify that the connections are encrypted by using the sql statement below:
select * from sys.dm_exec_connections
I need to connect to a secure SQL Server database using Perl DBI. I need to find a way to authenticate the user securely (without fear of eavesdropping, and without storing passwords on the client side). I'm using SQL Server 2008 on Windows Server 2008, and Perl 5.10 on XP.
SQL Server supports encrypted connections via something called the "SQL Server Native Access Client API", but I cannot tell whether this is supported by any DBD driver, or how to use it if it is.
I am reluctant to use the DBD::ODBC driver with SQL Server authentication, because ODBC transmits user IDs and passwords in cleartext.
I can't use the DBD::ODBC driver with Windows authentication (trusted connection), because the server is not on any Active Directory domain that is accessible from the client's network.
How can I secure my connections to the database? Thanks.
I am reluctant to use the DBD::ODBC driver with SQL Server authentication, because ODBC transmits user IDs and passwords in cleartext.
That is not strictly true. If you are using a recentish SQL Server and have not disabled encryption in it then the username/password and connection string are encrypted as follows:
The client contacts the server and tells it what it is capable of (e.g., it can do SSL). If the server then supports SSL it requires the client end to encrypt the connection info and falls back to unencrypted after that. You should also see the "Use Strong encryption for data" checkbox in the DSN.
Two options:
Create an IPSec tunnel between two locations. Some info here:
technet.microsoft.com/en-us/library/cc737154(WS.10).aspx
technet.microsoft.com/en-us/library/cc786385(WS.10).aspx
Enable SSL. I am not sure how well it would be protected.
technet.microsoft.com/en-us/library/ms189067.aspx
I would suggest that you use some kind of secured connection system. It might be IPSec, but it is often viewed as complicated, so you might be better (or faster) off with OpenVPN, which I use, and generally am happy with.
It can be used on virtually any operating system, is fast, and free. You can check it here: http://openvpn.net/