Using encrypted dB connection string

[Alek Davis]

Charlie,

If you use passwords for user authentication only, do not use encryption,
use hashing (with salt) instead. If you need to use encryption, in your
particular scenario (Web hosting environment to which you have limited
access), the best you can do is use a tool like CipherLite.NET (see
http://www.obviex.com/cipherlite/). You will need to embed the passphrase
(to generate encryption key) in your code, so if a hacker gets hold of your
assembly, this passphrase can be easily retrieved unless you obfuscate the
assembly using a good commercial obfuscator (and even this will not
guarantee security). Unfortunately, you don't have many options. If you find
a better approach, please post it here; there may be other readers in the
same situation.

Alek

 

[Charlie@CBFC]

Hi:

My host will not allow me use a trusted connection or make registry setting,
so I'm stuck trying find a way to hide connection string which will be
stored in web.config file. If I encrypt string externally, can it be used
in it's encrypted form to connect to SQL Server? If I decrypt back to
string for use in connection string during runtime, I have to supply a key.
If I do that, hacker could use key to break encryption. How do I handle
this? I'll be storing passwords in database and don't want a hacker to get
in.

Thanks,
Charlie

 

[Rick Spiewak]

See the following article:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT07.asp.
This describes the use of the DPAPI library and the machine key (or user
key, but for your purpose stick to the machine key) to encrypt and decrypt
things like the connection string. Because the key is known by the DPAPI
library, you don't need to provide it (or even know it).

You can pretty easily follow the article, and compile the library. I've also
written a VB.NET "wrapper" which simplifies the use of this library (but
still requires it) if you're interested. You will then need to use an
ASP.NET page (I've also written that if you like) which you will temporarily
install on your web site - the encryption technique used here relies on the
machine key for the actual machine on which you are running, so you can't do
this with a Windows app, although you could also do it with a web service.

You can then encrypt the connection string, and put it into the config file,
and then decrypt it at runtime. Then, if you're using an ASP.NET page which
knows how to encrypt/decrypt using DPAPI, you should remove it from your web
site since anyone who could find their way to it could use the decryption
facility!!

The only caveat is that if your hosting service replaces the machine you're
running on and doesn't maintain the machine key, you'll have to re-do the
encryption steps above.

 

[Guest]

I wonder if there is some level at which you have to place a level of trust.
For example - taking the Salt versus 2 way encryption.
Using Salt to one time your passwords for authenticaiton and using a
generation to reset forgotten passwords
Using 2-way to Encrypt and Decrypt and email forgotten passwords

If a Hacker were to steal your code and wanted the information he would
simply either
a) Steal the Generation Key and use that to generate keys and change
everybody's password
b) Steal the Pass phrase and create some code to grab the passes.
Exzact Same amount of work with the Exact same results.

If you don't trust your own webhost with a "database connection string" and
are going to go throught he process of encrypting and decrypting the
connection string every single time you are going to connect to it.

And how do you add salt to information that you need to retrieve.
Salt is 1-way. How is a 1-way encryption useful for Something you need to
use.

And I won't even go down the performance hit one would possibly take if
one's site began getting busy using 2-way encryption every time one wanted
to connect to the database. Maybe not an issue if one is not getting alot of
hits.

 

[Rick Spiewak]

If you're worried about performance from the decryption, do it at
application startup and store the decrypted connection string in Application
state or the cache.

 

[Alek Davis]

I don't think that using DPAPI with machine key gives you any particular
advantage. After all any application running on the same server will be able
to decrypt data encrypted using DPAPI with machine key, so it is not really
secure, unless you use secondary entropy, but if you do, it is no better
than hiding encryption key (or pass phrase) in the source code (since you
need to store this entropy somewhere).

The truth is that in a Web hosting environment, all feasible options are
bad, but there is not much you can do about it. From the security
perspective, shared hosting (and I assume that we are not talking about
dedicated hosting) is probably the worst environment you can think of. You
share the server with other customers, so in addition to external hackers
there is a potential threat coming from your neighbors. And your server is
managed by people you have no control over, so there is no way you can
enforce security procedures and make sure that the system is safe. But what
can you do? I assume that there is at least some level of trust between you
and the hosting company. Suspecting the hosting company to intentionally
hack your application is probably not reasonable (although who knows?), but
they can make a mistake and unintentionally leave your application
vulnerable.

As I said, in this scenario a reasonable option would be to hide pass phrase
in the source code and obfuscate the assembly. Assuming that the application
does not give access to the FBI files or Citibank accounts, it should be a
reasonably sufficient deterrent for most hackers. Using DPAPI with machine
store (and secondary entropy + obfuscation) is another alternative, but it
is too much overhead with no additional benefits. And there is a potential
to lose data in case the application is moved to a different server, which
is not unheard of.

Alek

 

[Rick Spiewak]

Yes, but the "other application" would need access to your web.config file.
Remember, that the objective in security can never be "absolute" - it's just
to make the cost of acquiring information greater than the value. You can
never do any better than that. That plus a little diligence to detect
misuse of information is all you need.

 

[Alek Davis]

Yes, but the READ access to the web.config is quite open (it includes
Everyone, Guest, etc), so to read a value from it may not be a big problem
for any "other application" running on the same machine.

 

[mikeb]

And how do you add salt to information that you need to retrieve.
Salt is 1-way. How is a 1-way encryption useful for Something you need to
use.

A one-way hashed password is useful when all you need to know is whether
or not someone else knows the secret that hashes to the same result.
Your system does not need to know *what* the password is - only that
when you hash what the user has provided, it ends up being the same as
the hash you've stored in the database.

The salt is not a secret - it's just random bits that are concatenated
to the password before hashing so that 2 users with the same password
don't get the same hash or that an attack using a dictionary of
pre-computed password hashes will not work.

 

[Rick Spiewak]

An interesting point, which may be unique to the shared host environment! It
may lead me to favor using entropy as well. This would require more effort,
and skill, to exploit - assuming the entropy value was hidden inside the
code.

Yes, it's true that a change in hardware might disable an application which
was dependent on the machine key! That's why I have written a simple .aspx
page to encrypt/decrypt using this same technique, so an administrator could
update the encrypted string. The hosting service could also, in theory,
commit to maintaining the machine key (just as you need to in a web farm for
the same reason).

As you point out, adding entropy leads to the circular problem of having a
secret left to protect. But it's at least smaller, and perhaps not as easy
to sniff out, and could be obfuscated in the code. Decrypting the string
once into the cache at startup would alleviate the performance issue for
decrypting.

I am curious as to whether the permissions on another application's
web.config file are actually sufficient to allow one to read it. (If I get
curious enough, I have more than one app hosted at my service, and I could
try to get at another app's file).

 

[Alek Davis]

An interesting point, which may be unique to the shared host environment! It
may lead me to favor using entropy as well. This would require more effort,
and skill, to exploit - assuming the entropy value was hidden inside the
code.

This essentially eliminates the benefit of using DPAPI, which is: you do not
need to worry about protecting secrets used to derive symmetric key
(entropy, pass phrase, password, or whatever you call it). So why not use
plain vanilla symmetric key encryption (Rijndael, 3DES)?

Yes, it's true that a change in hardware might disable an application which
was dependent on the machine key! That's why I have written a simple .aspx
page to encrypt/decrypt using this same technique, so an administrator could
update the encrypted string. The hosting service could also, in theory,
commit to maintaining the machine key (just as you need to in a web farm for
the same reason).

If this happens, you will need some downtime to reset the value(s). The
problem is that you own the application, but the Web host admin owns the
server, so you may not know that they made critical changes (say, the server
crashes and they move your app to a different physical machine). Now, if you
use DPAPI, you rely on the Web host admin to inform you about the change, so
you can reset the values, and this can take a while (and they may not even
inform you about this in the first place). If extended downtime is not a
problem for you, it must be OK, but I really do not see the benefit of it.

As you point out, adding entropy leads to the circular problem of having a
secret left to protect. But it's at least smaller, and perhaps not as easy
to sniff out, and could be obfuscated in the code. Decrypting the string
once into the cache at startup would alleviate the performance issue for
decrypting.

The same is true for traditional symmetric key encryption.

Alek

 

[satuttle]

You do not need to encrypt anything if you are placing it in your web.config file. The web.config file cannot be viewed by a web browser. Store your passwords in the database in md5 checksum so that even if he gets in he cannot see the passwords.

My guess if the guy is smart enough to be able to get to your web.config file then he could probably just hack your system to get out whatever he wants. He could just as easily get your binary compiled code and hack the cli that is used in your objects that make the connections to the database.

**********************************************************************
Sent via Fuzzy Software @ http://www.fuzzysoftware.com/
Comprehensive, categorised, searchable collection of links to ASP & ASP.NET resources...

 

[Alek Davis]

Following this logic, you should not encrypt/hash passwords (credit card
numbers, etc) saved in the databases, because if "the guy is smart enough to
get to your [database] he could [also] just hack your system to get out
whatever he wants." This logic could be valid if we had perfect software and
processes, but unfortunately they are not. People who maintain servers make
mistakes, hackers release new versions of worms, Trojans, etc. faster that
software vendors deploy hot fixes to patch vulnerabilities in their
applications, so if you listen to any respected security specialist, you
will hear that sensitive data should never be stored in plain text anywhere
on the system. This recommendation is based on many real life examples when
not doing so resulted in major security breaches.

Alek

You do not need to encrypt anything if you are placing it in your

web.config file. The web.config file cannot be viewed by a web browser.
Store your passwords in the database in md5 checksum so that even if he gets
in he cannot see the passwords.

My guess if the guy is smart enough to be able to get to your web.config

file then he could probably just hack your system to get out whatever he
wants. He could just as easily get your binary compiled code and hack the
cli that is used in your objects that make the connections to the database.

**********************************************************************
Sent via Fuzzy Software @ http://www.fuzzysoftware.com/
Comprehensive, categorised, searchable collection of links to ASP &

ASP.NET resources...