February 7, 2011 at 11:19 am
Thanks for the question, it is good to bring up the deprecation of features, and show the alternative.
February 7, 2011 at 11:31 am
RichB (2/7/2011)
What with them being inherently, disgracefully insecure.
Are you talking about the fact that they have to be stored in plain text in connection strings that are at the Least a read only file for all users?
Filter it for login packets... and watch in wonder as your password flies across the network in plain text! <_<
Ok, you are talking about the same limitation all network applications that use login packets to support application user logins stored in the application. SNMP, POP, SQL, FTP, NNTP, etc...
IMHO: If your network security is so lax that just anyone can install and use a packet sniffer to get this data, there is not an application security issue. :w00t:
February 7, 2011 at 11:39 am
SanDroid (2/7/2011)
RichB (2/7/2011)
What with them being inherently, disgracefully insecure.Are you talking about the fact that they have to be stored in plain text in connection strings that are at the Least a read only file for all users?
Filter it for login packets... and watch in wonder as your password flies across the network in plain text! <_<
Ok, you are talking about the same limitation all network applications that use login packets to support application user logins stored in the application. SNMP, POP, SQL, FTP, NNTP, etc...
IMHO: If your network security is so lax that just anyone can install and use a packet sniffer to get this data, there is not an application security issue. :w00t:
Yes there is. Just because you also have a network security issue doesn't mean that the application security issue can be ignored. That's why when possible you use secure versions of those protocols (usually the same protocol encrypted via SSH or SSL). Or you use alternative authentication mechanisms like Windows-based authentication with Kerberos as opposed to SQL user logins.
Yes, we use some SQL logins here, but only when the application requires it and only after evaluating other options and mitigation opportunities. It is a serious security issue, and hiding it under network security issues does nobody any good.
February 7, 2011 at 11:55 am
RichB (2/7/2011)
For anyone that hasn't I strongly recommend using your favourite packet sniffer (wireshark for instance) to trace the local network while you log in with a sql login. Filter it for login packets... and watch in wonder as your password flies across the network in plain text! <_<
Is that true even if you are using encrypted connections?
February 7, 2011 at 12:24 pm
RichB (2/7/2011)
Ah, not the missing option of 'wtf are you using sql logins in production for anyway?'What with them being inherently, disgracefully insecure.
For anyone that hasn't I strongly recommend using your favourite packet sniffer (wireshark for instance) to trace the local network while you log in with a sql login. Filter it for login packets... and watch in wonder as your password flies across the network in plain text! <_<
So what do you use when you've got an application on a standalone (non-domain) web server connecting to a DB server behind a firewall? Mirrored local accounts? I keep looking for decent ways to avoid using SQL logins in this scenario, but nothing I come up with seems to work as well or be as easy to maintain.
February 8, 2011 at 10:12 am
Regarding SQL logins, I think the point here is to use them as a last resort when no other options are available.
In a web server/db server example, you could only allow the web server to communicate with a 'data broker' https web service, and then use windows authentication to permit that broker to connect to the SQL database. You could then use a client cert to secure the data broker web service, and only load that cert into the account that runs your app pool, making sure your website is the only website in that app pool (IIS solution).
But yeah with a vendor supplied solution you can often be left with no other option.
February 8, 2011 at 11:18 am
marklegosz (2/8/2011)
Regarding SQL logins, I think the point here is to use them as a last resort when no other options are available.In a web server/db server example, you could only allow the web server to communicate with a 'data broker' https web service, and then use windows authentication to permit that broker to connect to the SQL database. You could then use a client cert to secure the data broker web service, and only load that cert into the account that runs your app pool, making sure your website is the only website in that app pool (IIS solution).
But yeah with a vendor supplied solution you can often be left with no other option.
Interesting ideas, thanks. I'd never come across anyone doing it like that before, but it does make sense.
February 8, 2011 at 12:06 pm
Thanks for the question
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
February 11, 2011 at 9:42 am
Good question - we've been hit by this problem too and it can be a right pickle to sort out!
February 11, 2011 at 10:50 am
Good question. I appreciate the update of information. I use sp_change_users_login fairly frequently. I'll miss the report option though.
Kenneth FisherI was once offered a wizards hat but it got in the way of my dunce cap.--------------------------------------------------------------------------------For better, quicker answers on T-SQL questions, click on the following... http://www.sqlservercentral.com/articles/Best+Practices/61537/[/url]For better answers on performance questions, click on the following... http://www.sqlservercentral.com/articles/SQLServerCentral/66909/[/url]Link to my Blog Post --> www.SQLStudies.com[/url]
Viewing 10 posts - 31 through 39 (of 39 total)
You must be logged in to reply to this topic. Login to reply