|
database
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
-- 'password' was found in the text of this event.-- 'password' was found in the text of this event.
-- The text has been replaced with this comment for security reasons. Where can I find more info on this? Particularly, how to turn it off on our development machines. -- Jonathan Allen AFAIK, Its a security feature added in SP4 and its not configurable, ie, you
cannot turn it off. Show quote "Jonathan Allen" <x@x.x> wrote in message news:ON5rgxTpFHA.1044@tk2msftngp13.phx.gbl... > -- 'password' was found in the text of this event. > -- The text has been replaced with this comment for security reasons. > > Where can I find more info on this? Particularly, how to turn it off on > our development machines. > > -- > Jonathan Allen > > > Does MS at least have a KB article explaining this "feature" and exactly
when it comes into play? (Seems rather dubious to me, as you have to be an administrator to run the profiler anyways.) -- Show quoteJonathan Allen "Roji. P. Thomas" <thomasr***@gmail.com> wrote in message news:ejz9X4UpFHA.2504@tk2msftngp13.phx.gbl... > AFAIK, Its a security feature added in SP4 and its not configurable, ie, > you cannot turn it off. > > > > -- > Roji. P. Thomas > Net Asset Management > http://toponewithties.blogspot.com > > > "Jonathan Allen" <x@x.x> wrote in message > news:ON5rgxTpFHA.1044@tk2msftngp13.phx.gbl... >> -- 'password' was found in the text of this event. >> -- The text has been replaced with this comment for security reasons. >> >> Where can I find more info on this? Particularly, how to turn it off on >> our development machines. >> >> -- >> Jonathan Allen >> >> >> > > > But it does stop people seeing the password when they copy a trace file and > (Seems rather dubious to me, as you have to be an administrator to run the > profiler anyways.) load into profiler on a machine where they do have admin rights. John If they have access to the trace file, then I have a lot more worries than
just the user passwords. And what of my DBA calls the column passphrase instead of password? If they gave us a editable list of words to block, then I could see value in this. As it stands, I'm losing my ability to debug code and all I'm getting is a false sense of security. No wait, I'm also losing my ability to audit my servers. All a hacker has to do is add /*password*/ to every command and I have no way to know what he is doing. -- Show quoteJonathan Allen "John Bell" <jbellnewspo***@hotmail.com> wrote in message news:%23FhnogcpFHA.2904@tk2msftngp13.phx.gbl... > > >> (Seems rather dubious to me, as you have to be an administrator to run >> the profiler anyways.) > > But it does stop people seeing the password when they copy a trace file > and load into profiler on a machine where they do have admin rights. > > John > As you can never be 100% sure that you will never be hacked or abused by
someone with ligitimate access it is still the safest option. John Show quote "Jonathan Allen" <x@x.x> wrote in message news:esprGogpFHA.3656@TK2MSFTNGP09.phx.gbl... > If they have access to the trace file, then I have a lot more worries than > just the user passwords. And what of my DBA calls the column passphrase > instead of password? If they gave us a editable list of words to block, > then I could see value in this. As it stands, I'm losing my ability to > debug code and all I'm getting is a false sense of security. > > No wait, I'm also losing my ability to audit my servers. All a hacker has > to do is add /*password*/ to every command and I have no way to know what > he is doing. > > -- > Jonathan Allen > > > "John Bell" <jbellnewspo***@hotmail.com> wrote in message > news:%23FhnogcpFHA.2904@tk2msftngp13.phx.gbl... >> > >>> (Seems rather dubious to me, as you have to be an administrator to run >>> the profiler anyways.) >> >> But it does stop people seeing the password when they copy a trace file >> and load into profiler on a machine where they do have admin rights. >> >> John >> > > "Jonathan Allen" <x@x.x> wrote in message <snip> No wait, I'm also losing my ability to audit my servers. All a hacker news:esprGogpFHA.3656@TK2MSFTNGP09.phx.gbl... has to > do is add /*password*/ to every command and I have no way to know what he </snip>> is doing. I'd be more worried that your SQL Server is accessable at all from foreign networks. I'd suggest that you tighten up the security of the server for peace of mind. First add a firewall to the server itself, and only open the ports that you're actually using. Make sure that the machine is places so that it uses a private IP address i.e. 192.168.1.1 or something like that. In an n-tier environment you can lock things up even better by allowing only the next tier access to the machine, accomplished use of a DMZ. Of course, these are only a few ideas to think about I'm sure that the experts on this newsgroup will be able to suggest about a billion more security measures, and correct anything that I've said that is completely wrong. The point is that you need to lock up access to the production machine so tight that no one can access it without express permission. Regards Colin Dawson www.cjdawson.com I'm thinking about the "I think someone has gotten access and need to know
what is happening" situation. I trust our DBA and IT departments have already made a reasonable attempt to lock-down the server. Anyways, if anyone comes across MS's official reasoning behind this please let me know. -- Show quoteJonathan Allen "Colin Dawson" <newsgro***@cjdawson.com> wrote in message news:D%XNe.93164$G8.33225@text.news.blueyonder.co.uk... > > "Jonathan Allen" <x@x.x> wrote in message > news:esprGogpFHA.3656@TK2MSFTNGP09.phx.gbl... > <snip> No wait, I'm also losing my ability to audit my servers. All a > hacker has to >> do is add /*password*/ to every command and I have no way to know what he >> is doing. > </snip> > > I'd be more worried that your SQL Server is accessable at all from foreign > networks. I'd suggest that you tighten up the security of the server for > peace of mind. First add a firewall to the server itself, and only open > the ports that you're actually using. Make sure that the machine is > places so that it uses a private IP address i.e. 192.168.1.1 or something > like that. In an n-tier environment you can lock things up even better > by allowing only the next tier access to the machine, accomplished use of > a DMZ. > > Of course, these are only a few ideas to think about I'm sure that the > experts on this newsgroup will be able to suggest about a billion more > security measures, and correct anything that I've said that is completely > wrong. > > The point is that you need to lock up access to the production machine so > tight that no one can access it without express permission. > > Regards > > Colin Dawson > www.cjdawson.com > Hi,
I'm very interested in any answer about this myself. I am profiling an application that uses the string 'password' a couple dozen times in schema identifiers. This "feature" is annoying enough to make me miss helpful little Clippy. This should be configurable. Though I understand that making it configurable reduces the effectiveness as a security measure, I still feel that this goes too far. Basically, I now have to spend significant time researching/instrumenting code to capture the statements that are being hid from me. Not happy about that. Sorry to pile on and beat the dead horse, but this is hurting me right this second, and I can't really roll back SPs on this server. Thanks for reading, Eric Show quote "Jonathan Allen" wrote: > I'm thinking about the "I think someone has gotten access and need to know > what is happening" situation. I trust our DBA and IT departments have > already made a reasonable attempt to lock-down the server. > > > Anyways, if anyone comes across MS's official reasoning behind this please > let me know. > > -- > Jonathan Allen > > > "Colin Dawson" <newsgro***@cjdawson.com> wrote in message > news:D%XNe.93164$G8.33225@text.news.blueyonder.co.uk... > > > > "Jonathan Allen" <x@x.x> wrote in message > > news:esprGogpFHA.3656@TK2MSFTNGP09.phx.gbl... > > <snip> No wait, I'm also losing my ability to audit my servers. All a > > hacker has to > >> do is add /*password*/ to every command and I have no way to know what he > >> is doing. > > </snip> > > > > I'd be more worried that your SQL Server is accessable at all from foreign > > networks. I'd suggest that you tighten up the security of the server for > > peace of mind. First add a firewall to the server itself, and only open > > the ports that you're actually using. Make sure that the machine is > > places so that it uses a private IP address i.e. 192.168.1.1 or something > > like that. In an n-tier environment you can lock things up even better > > by allowing only the next tier access to the machine, accomplished use of > > a DMZ. > > > > Of course, these are only a few ideas to think about I'm sure that the > > experts on this newsgroup will be able to suggest about a billion more > > security measures, and correct anything that I've said that is completely > > wrong. > > > > The point is that you need to lock up access to the production machine so > > tight that no one can access it without express permission. > > > > Regards > > > > Colin Dawson > > www.cjdawson.com > > > > >  
Other interesting topics
|
|||||||||||||||||||||||
