Re: Locking down database accounts

From: BP Margolin (bpmargo@attglobal.net)
Date: 01/14/03 

From: "BP Margolin" <bpmargo@attglobal.net>
Date: Mon, 13 Jan 2003 20:56:43 -0500

Coby,

Thanks for the additional information.

Personally it sounds to me that your company has established a policy and is
not willing to accept the consequences of that policy ... and that's really
a political issue rather than a technical one.

But bottom line if you have to use SQL Server logins and passwords, and you
don't want the users to be supplying them ... i.e., the application is
supposed to connect "invisibly" to SQL Server, then you have the very
problem you've outlined. The login and password either have to be hard-coded
into the application or stored someone accessible to all users. Encryption
is just about the only thing I can think of to "hide" the login and
password. Whether it's an encrypted flat file or an encrypted XML file, to
my mind at least, really doesn't make a difference.

> So we are
> wondering what our options would be - preferring a simple,
> but safe solution. thanks.

Goes back to using Windows Authentication rather than Mixed Authentication
... not trying to be funny or annoying ... just really pointing out that the
problem is not a technical one ... it is a political one. It's like, in
order to save money we're turning off all electricity at 5 PM, but we need
you to use your workstation after 5 PM ... how do we address this ... Easy
... change the frigging policy ... it's just not really a technical issue.
One of my cardinal rules of thumb is just because an executive makes a
decree does not mean that the decree makes sense. If the executive is
unwilling to change the policy, then have him accept the consequences of the
policy. BTW, there's a real good story about Steve Jobs and this very
concept ... without going into the details, the punch line is something
like, "Even Steve Jobs can't change the laws of physics" ;-)

-------------------------------------------
BP Margolin
Please reply only to the newsgroups.
When posting, inclusion of SQL (CREATE TABLE ..., INSERT ..., etc.) which
can be cut and pasted into Query Analyzer is appreciated.

"Coby" <Coby_Hamilton@administaff.com> wrote in message
news:3ce801c2bb3a$c3f81d30$d6f82ecf@TK2MSFTNGXA13...
> BP,
> Sorry I wasn't too clear initially. From what I've been
> told, our company's policy is to use SQL security instead
> of Windows authentication. What's been done in the past is
> to put the SQL server accounts and passwords in an .XML
> file somewhere where the applications can access it and
> use that security information to access particular
> databases - relying on security by obscurity. There's been
> talk about encrypting the .XML file to protect the
> passwords, but then decryption information and setup would
> need to be loaded on each client using the application. No
> one knows yet if you can give an NT process (application
> executable) some level of security to access the file that
> contains the database accounts and passwords. So we are
> wondering what our options would be - preferring a simple,
> but safe solution. thanks.
>
>
>
>
> >-----Original Message-----
> >Coby,
> >
> >Not real sure that I understand your post, but taking a
> stab at it ... use
> >Windows Authentication rather than SQL Server user
> accounts and passwords.
> >Section "Authentication Modes"
> (adminsql.chm::/ad_security_47u6.htm) in the
> >SQL Server 2000 Books Online has arguments for choosing
> Windows
> >Authentication over SQL Server user accounts and
> passwords.
> >
> >-------------------------------------------
> >BP Margolin
> >Please reply only to the newsgroups.
> >When posting, inclusion of SQL (CREATE TABLE ...,
> INSERT ..., etc.) which
> >can be cut and pasted into Query Analyzer is appreciated.
> >
> >"Coby" <Coby_Hamilton@administaff.com> wrote in message
> >news:4e7b01c2bb33$d86f1540$8af82ecf@TK2MSFTNGXA03...
> >> What's the easiest way to lock down database user
> accounts
> >> and passwords for applications to access? We don't want
> >> them sitting around in an .xml file and we would rather
> >> avoid encrypting them because then clients would require
> >> additional configuration. Is there a happy, safe medium?
> >> Thanks.
> >>
> >
> >
> >.
> >

Relevant Pages

  • [NT] SQL Server Installation Process May Leave Passwords on System
    ... service pack for SQL Server 7.0 or SQL Server 2000, ... without having to actually perform an installation. ... to SQL Server 7.0 Service Pack 4, the passwords were stored in clear text. ... information in the setup.iss and log files would not allow any access. ...
    (Securiteam)
  • Re: Powerful login script??
    ... Do you really need SQL Server to house your company policy and user state info ... 3000 client computers will need to have SQL Server ODBC/OLEDB drivers installed IF you want the login script to run on each computer ... The login script will be triggered by a GPO and will always run. ...
    (microsoft.public.windows.server.scripting)
  • RE: policy-based password cracker
    ... that required at least one upper, one lower and one number in all passwords. ... password checks can be eliminated due to the policy. ... Since the vast majority of the time for a brute-force attack is ... most brute-force attacks are very fast. ...
    (Pen-Test)
  • RE: New Paper: Microsoft SQL Server Passwords
    ... > Subject: New Paper: Microsoft SQL Server Passwords ... are stored in Microsoft's SQL Server. ... If you select a case-insensitive collation for your SQL Server ... Drop all of the user databases. ...
    (Bugtraq)
  • Re: Password is "too recent to change"
    ... The lockout policy is set at 3 attempts in some period of time. ... and it will stop checking the OS or domain password policy for SQL Server. ... Since these are policy settings, I'm concerned it cannot be changed ... with a generic SA password using a command line install. ...
    (microsoft.public.sqlserver.security)