Some Thoughts On Connection Strings

  • Thread starter Thread starter scorpion53061
  • Start date Start date
S

scorpion53061

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.
 
There are a lot of white papers on this, not only that, but if you have SQL
Server then you can use Integrated Security.

Which I like a lot more...
 
There are a lot of white papers on this , not only that, >but if you have
SQL
Server then you can use Integrated Security.

I think my biggest argument with some "white papers" that I see written, not
just those written about encryption is it assumes all users are experts and
well rounded in all aspects of the framework.

What I try to do is break it down and make it as simple and as
straightforward as possible explaining what is happening in each step. It
annoys some but others are greatful.

Integrated Security as I am sure you know has its own problems and benefits.
 
There are a lot of white papers on this , not only that, >but if you
have
SQL

I think my biggest argument with some "white papers" that I see written, not
just those written about encryption is it assumes all users are experts and
well rounded in all aspects of the framework.

Fair enough, I suppose that is a really good point about all users being
experts too, becuase I've read a lot of white papers that can be a little
diffucult to understand. And there are a lot of users that claim they know
what there doing and really don't. I "fluff-bunny" if you will. =)

What I try to do is break it down and make it as simple and as
straightforward as possible explaining what is happening in each step. It
annoys some but others are greatful.

Hey, I would love to see it. Post it up on DevX as well or WindowsForms so
it can get some exposure, if you want some feedback on it at all I'll be
happy to read it for you before you post.
Integrated Security as I am sure you know has its own problems and benefits.
Everything does. =0
 
Fair enough, I suppose that is a really good point about all users being
experts too, becuase I've read a lot of white papers that can be a little
diffucult to understand. Hey, I would love to see it. Post it up on DevX as well or WindowsForms so
it can get some exposure, if you want some feedback on it at all I'll be
happy to read it for you before you post.


Thanks for the offer CJ.

I am probably not a good enough writer for the "big time" like that (see the
little horrid thing I did on the excel and datasets at
http://www.kjmsolutions.com/datasetarray.htm).

But when the only readers are among us we are all family and love each other
unconditionally right? :) Even Herfried...(Just kidding dont get upset
::)))))

If I write horrid, noone will hold it against me. :).

The biggest reason I write is it drills the concepts into my head as well.
If I understand it well enough to write it I will never lose that skill know
what I mean?

But that was something else today watching that guy put his application out
there with that information (username and password) on each users machine.

His reaction when I asked him what he was doing:

"Everybody does it this way. You are just paranoid. Noone is going to know
to look in the folder(the application directory) for my username/password."

He is not alone. I have seen it several times myself and have heard about it
way too often lately.

Well maybe I am but that is still scary in my opinion.
 
scorpion53061 said:
DevX
as well or WindowsForms so


Thanks for the offer CJ.

I am probably not a good enough writer for the "big time" like that (see the
little horrid thing I did on the excel and datasets at
http://www.kjmsolutions.com/datasetarray.htm).

Ahh yes... the imfamous datasetarray article. And why isn't it good, because
that punk bitch said something about it earlier? I read it, I understood
it, and applaud the fact that you took the time to write an article on it.
You dind't get paid, you didn't get credit, you just did it to help people
understand, and it was correct, so who cares about the writing style, you
did something you didn't have to. Much like all of us that post here.
But when the only readers are among us we are all family and love each other
unconditionally right? :) Even Herfried...(Just kidding dont get upset
::)))))

Herfried gets upset at nothing. But I wonder today since he's been so damn
quiet. As I said, if you take the time to do it, awesome. I just offered
my help bewcause I do that too, I have someone read over my stuff after I'm
done so it sounds good. And yes, everyone here appriecates the fact your
trying to learn.
If I write horrid, noone will hold it against me. :).

The biggest reason I write is it drills the concepts into my head as well.
If I understand it well enough to write it I will never lose that skill know
what I mean?

Not uncommon. I do it too, usually just within code comments, but everyone
is different, if it helps you understand the concept and then give to
someone to make sure, awesome, once again, your doing what you can to learn.
But that was something else today watching that guy put his application out
there with that information (username and password) on each users machine.

His reaction when I asked him what he was doing:

"Everybody does it this way. You are just paranoid. Noone is going to know
to look in the folder(the application directory) for my username/password."

We call them "fluff-bunnies"

and yes... anyone with any intelligence (even minimal) of computers and .NET
can figure out an app.config file.
He is not alone. I have seen it several times myself and have heard about it
way too often lately.
I see tons of developers do it. Some do it because they restrict the SQL
access, but we all know those people and they dont say stupid things like
above.

Anyways, look forward to reading your article.

-CJ
 
His reaction when I asked him what he was doing:

"Everybody does it this way. You are just paranoid. Noone is going to know
to look in the folder(the application directory) for my username/password."

He is not alone. I have seen it several times myself and have heard about it
way too often lately.

Well maybe I am but that is still scary in my opinion.


You're right, that is scary. And no, not everyone does it that way.
Only people that *don't*care* do it that way. Any passwords used
should *always* be encrypted, even if it's a simple homegrown
encryption scheme. Anything is better than nothing!

// CHRIS
 
scorpion53061 said:
I am seeing way too many connection strings not being properly protected.

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.

scorpion53061,

You have touched upon a serious issue that I have been looking into as
well. I would be very interested in reading your paper when you have
it ready, I know it is not a simple issue.

Charlie
 
Hi Scorpion,

I think you are right to find a password encrypting method on msdn is a hell
of a job.

On the other hand, when you publish a encryption method, decrypting it will
be much easier for the one who want to do that.

Some people are taken often direct the sample.

A rather difficult circel.

Cor
 
On the other hand, when you publish a encryption method, decrypting it
will
be much easier for the one who want to do that.

The one I will be pushing uses a unique key.

It isn't hard. But explaining it , taking the mystery out of the
cryptography namespace I think can be a challenge. As soon as the word
"encryption" people throw up a wall because they fear it will be difficult.
At least that was the case iwth my friend yesterday.
 
Cor said:
On the other hand, when you publish a encryption method, decrypting it will
be much easier for the one who want to do that.

Cor: I thought you would like to know... that the reality is almost the
exact opposite.

Any modern encryption algorithm is "secure" by virtue of it's internal
mechanism being known to everybody. It is mathematically secure. You can
find/license source code for DES and RSA I'm certain. PGP (Pretty Good
Privacy) is used all over the net.

An estimate given (in the following book) is based upon the speed and power
that special-purpose chips will attain (or have attained) concludes "with an
array of four thousand chips, each capable of checking 265 million keys per
second, all possible 56-bit keys can be tested within 24 hours."

See: "Applied Cryptography" by Bruce Schneier

The questions are who would have access to such a machine and why would they
spend the day trying to hack your database?

Tom
 
Hi Tom,

But what if Scorpion publish his methode and a fool who works in a large
bank takes it, while Scorpion tells that the sample key has to be changee,
but he does not.

And then someone hacks the bank.

Than there can be another kind of Ironman, who have no right, but can make a
lot of problems for Scorpion.

That was more or less what I did want to say to Scorpion.

But maybe I am to prudent.

On the other hand, from this messages between us Scorpion knows now that
when he does it, the mimimum that he has to do is to put a lot of
disclaimers around it.

:-)

Cor
 
You can't inflict liability based on learning material. Especially that
which isn't published/proofed or provide any warranty.

Since the documentation does state the key MUST be changed, and implies
there is no warrenties with the documentation (were not RSA here, no
guaruntees are being made) therefore, scorpion is not liable for the
document.

At least this is the way it would apply in the U.S. (be sure to put a
disclaimer at the bottom of your document nonetheless though, just for good
measure).

And ironman is a twit...
 
Hi Cor,

Thanks for the reasoned response...

The "bank" won't be hacked because Scorpion's document didn't have the words
"you should change the key" in bold letters :-) Banks use well-defined
mechanisms for protecting their assets. They may be using DES but may have
gone to triple-DES or the equivalent. Large institutions have security
advisors and specialists who understand the algorithms and trade-offs. They
have policies and no single programmer is going to substitute some code they
copied from Scorpion's document for the things they have in place already.

My only point was that publishing the algorithm turns out to be the way to
make certain it works. Keeping it secret turns out to be the least secure
methodology. If it can stand up to the fastest machines poking at it for
100 years it can be deemed worthy of securing a database that can be
compromised by simply paying the programmer US $1 million for the password.
There are ways in besides the front door...

If he reads the book I mentioned he can find all sorts of code along with
their mathematical ability to be hacked. Not every problem warrants the
effort to provide absolute unbreakability. But such a method does exist,
it's called a one-time pad, but you only get to use the key once so there is
a downside there too.

Ironman-types would have to get "close" before they could even attempt the
hack and 10 failures in a row can disable the account... 20 failures can
fire off an e-mail to the security administrator. There are lots of ways to
stop an attack. The question that remains is who is going to try? And what
would they get for finally getting access to the company file? Can they
change their salary to $10 million a year? I doubt the check would go
through unnoticed :-)

Seriously... "they could trash the database" and so of course could a disk
failure, that's what backups are for. I have an example of a software bug
that trashed the primary drive and the mirrored backup at the same time...
how's that for circumventing the security :-)

Everything is a trade-off. Take care,
Tom
 
I use a class I found on the Net, clsCryptoAPI, to encrypt and decrypt
connection string to the registry. It is from Sam Patterson's COMponent
builder Article in Visual Basic
Programmers Journal, "Secure Your Apps with CryptoAPI". It is in VB6 but
could be translated to DotNet. The same pattern could be applied to
app.config files, I suppose. I'm somewhat new to this DotNet thing though.
Here is a link to the code if anyone is interested.

http://www.fawcette.com/archives/listissue.asp?pubID=1&MagIssueId=121
 
I used a great wrapper (I think the one your talking about) for the
CryptoAPI in VB6, its awesome.

My two cents...
 
that's the one.. The version I have has been modified by Kenneth Ives. I
cant seem to find that version on the net anymore.
 
Back
Top