By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,313 Members | 2,725 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,313 IT Pros & Developers. It's quick & easy.

Using encrypted dB connection string

P: n/a
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

Nov 18 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a
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" <ch*****@comcast.net> wrote in message
news:O8**************@TK2MSFTNGP11.phx.gbl...
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

Nov 18 '05 #2

P: n/a
See the following article:
http://msdn.microsoft.com/library/de...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.

"Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in message
news:ei*************@TK2MSFTNGP09.phx.gbl...
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" <ch*****@comcast.net> wrote in message
news:O8**************@TK2MSFTNGP11.phx.gbl...
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


Nov 18 '05 #3

P: n/a
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" <ri*********@mindspring.com> wrote in message
news:uQ*************@tk2msftngp13.phx.gbl...
See the following article:
http://msdn.microsoft.com/library/de...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.

"Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in message
news:ei*************@TK2MSFTNGP09.phx.gbl...
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" <ch*****@comcast.net> wrote in message
news:O8**************@TK2MSFTNGP11.phx.gbl...
> 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
>
>
>



Nov 18 '05 #4

P: n/a
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.

<jo*****@driver.net> wrote in message
news:ez**************@TK2MSFTNGP12.phx.gbl...
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" <ri*********@mindspring.com> wrote in message
news:uQ*************@tk2msftngp13.phx.gbl...
See the following article:
http://msdn.microsoft.com/library/de...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.

"Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in message
news:ei*************@TK2MSFTNGP09.phx.gbl...
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" <ch*****@comcast.net> wrote in message
news:O8**************@TK2MSFTNGP11.phx.gbl...
> 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
>
>
>



Nov 18 '05 #5

P: n/a
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" <ri*********@mindspring.com> wrote in message
news:uQ*************@tk2msftngp13.phx.gbl...
See the following article:
http://msdn.microsoft.com/library/de...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.

"Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in message
news:ei*************@TK2MSFTNGP09.phx.gbl...
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" <ch*****@comcast.net> wrote in message
news:O8**************@TK2MSFTNGP11.phx.gbl...
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



Nov 18 '05 #6

P: n/a
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" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in message
news:u8**************@TK2MSFTNGP10.phx.gbl...
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" <ri*********@mindspring.com> wrote in message
news:uQ*************@tk2msftngp13.phx.gbl...
See the following article:

http://msdn.microsoft.com/library/de...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.

"Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in message
news:ei*************@TK2MSFTNGP09.phx.gbl...
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" <ch*****@comcast.net> wrote in message
news:O8**************@TK2MSFTNGP11.phx.gbl...
> 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
>
>
>



Nov 18 '05 #7

P: n/a
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.

"Rick Spiewak" <ri*********@mindspring.com> wrote in message
news:u5**************@TK2MSFTNGP12.phx.gbl...
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" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in message
news:u8**************@TK2MSFTNGP10.phx.gbl...
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" <ri*********@mindspring.com> wrote in message
news:uQ*************@tk2msftngp13.phx.gbl...
See the following article:

http://msdn.microsoft.com/library/de...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.

"Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in message
news:ei*************@TK2MSFTNGP09.phx.gbl...
> 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" <ch*****@comcast.net> wrote in message
> news:O8**************@TK2MSFTNGP11.phx.gbl...
> > 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
> >
> >
> >
>
>



Nov 18 '05 #8

P: n/a
jo*****@driver.net wrote:

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.

--
mikeb
Nov 18 '05 #9

P: n/a
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" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in message
news:%2******************@tk2msftngp13.phx.gbl...
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.

"Rick Spiewak" <ri*********@mindspring.com> wrote in message
news:u5**************@TK2MSFTNGP12.phx.gbl...
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" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in message
news:u8**************@TK2MSFTNGP10.phx.gbl...
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" <ri*********@mindspring.com> wrote in message
news:uQ*************@tk2msftngp13.phx.gbl...
> See the following article:
>

http://msdn.microsoft.com/library/de...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.
>
> "Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in
message > news:ei*************@TK2MSFTNGP09.phx.gbl...
> > 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" <ch*****@comcast.net> wrote in message
> > news:O8**************@TK2MSFTNGP11.phx.gbl...
> > > 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
> > >
> > >
> > >
> >
> >
>
>



Nov 18 '05 #10

P: n/a
"Rick Spiewak" wrote:
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
Nov 18 '05 #11

P: n/a
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...
Nov 18 '05 #12

P: n/a
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

"Scott Tuttle" <sa******@yahoo.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
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...
Nov 18 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.