Re: Some Thoughts On Connection Strings by Angel
Angel
Thu Jan 08 12:26:42 CST 2004
Sushil is completely correct, but let me make this perfectly clear:
If you give me a winform ado.net application that connects to your server
you are giving me access to your server with the exact same privileges as
your application. Period. There is absolutely no way you can hide the
username password, and this is not necessarily a bad thing, it just means
that you must re-think how you develop your applications.
ASP.NET does not have this issue since you are not handing out the process
that accesses the database.
Intranet Winform database applications: Do not make an application that uses
User Id, Password if you have even the slightest security concerns. Instead
use integrated security and let the database accounts guarantee security for
you.
Extranet Winform database applications: Your database should never be
listening on an external port, make a webservices layer and place all of
your ado.net code there.
Using encryption, encrypting the username password, and even changing
connection permissions at runtime (which breaks pooling btw) are not enough.
There is another good point in Scorps post, we are currently protecting
against Sql injection in the command Text, but we are not offering similar
protection for the connection string. Allowing customers to type in their
user name and password would be a reasonable scenario for some applications
security model, however it is currently very dangerous to allow user input
directly into your connection string. This is something that we are looking
into, any thoughts or ideas welcome.
Thanks
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
"Sushil Chordia" <sushilc@online.microsoft.com> wrote in message
news:eUUtoSY1DHA.4032@tk2msftngp13.phx.gbl...
> William and Dina raise a good issue. One workaround would be to use
> integrated security and hence removing the use of userid and pwd and
therby
> securing your systems.
> HTH,
> Sushil Chordia.
> --
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> "William Ryan" <dotnetguru@comcast.nospam.net> wrote in message
> news:eMh1kiV1DHA.3824@TK2MSFTNGP11.phx.gbl...
> > Scorp:
> >
> > I believe it's Dino Esposito who wrote a great article on ASP.NET Pro
> > magazine about encrypting them using a special utilty which I can send
you
> > info about when I get home (I just can't remember off of the top of my
> > head). I know what you mean though (and if you think this is bad, you
> ought
> > to see how many people send around HIPAA violations not realizing what
> they
> > are doing).
> >
> > I remember a while ago someone posted a snippet here with the Server
name,
> > SA login and password ( I think Bill Vaughn pointed it out by saying
> > something like "No that i Have your username and password, let me grab
all
> > of your data and I'll get back to you.")
> >
> > I think it'd be a great paper, but there are a LOT of folks out there
who
> > relish the good old days when you didn't have to worry about security
(I'm
> > not sure such days ever existed but they tell me they did) and just deal
> > with it by pretending it's not a problem. Hopefully, raising awareness
to
> > it will help change things, and if it doesn't, a few more hacked sites
> > certainly will.
> >
> > Drop me a line at the home address, I have some code that you may find
> > helpful...
> > "scorpion53061" <Its the end of the world as we know it@here.com> wrote
in
> > message news:eWu4ZcV1DHA.2160@TK2MSFTNGP12.phx.gbl...
> > > I am seeing way too many connection strings not being properly
> protected.
> > >
> > > This morning an indiviual asked me to help him with an unrelated issue
> and
> > I
> > > was shocked to see his password/username of his SQL Server shown in a
> XML
> > > file with absolutely no protection whatsoever. Any user could have
> opened
> > > the file and had access to his entire database.
> > >
> > > Even those who have the connection in code are not safe because of
those
> > who
> > > can decompile applications.
> > >
> > > I think in the next release of ADO.NET MS has to do something about
> this.
> > I
> > > think this is a timebomb that is going to come back and bite some
> people.
> > >
> > > I am trying to write a paper on encryption and connection strings that
> is
> > > easily understandable. It is not easy to do. Hopefully will have it
done
> > > soon.
> > >
> > >
> >
> >
>
>