Using encrypted dB connection string

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

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" <charle1@comcast.net> wrote in message
news:O80gzh3PEHA.3232@TK2MSFTNGP11.phx.gbl...[color=blue]
> Hi:
>
> My host will not allow me use a trusted connection or make registry[/color]
setting,[color=blue]
> 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[/color]
key.[color=blue]
> 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[/color]
get[color=blue]
> in.
>
> Thanks,
> Charlie
>
>
>[/color]

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:ei79Ws3PEHA.832@TK2MSFTNGP09.phx.gbl...[color=blue]
> 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[/color]
your[color=blue]
> 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[/color]
find[color=blue]
> a better approach, please post it here; there may be other readers in the
> same situation.
>
> Alek
>
> "Charlie@CBFC" <charle1@comcast.net> wrote in message
> news:O80gzh3PEHA.3232@TK2MSFTNGP11.phx.gbl...[color=green]
> > Hi:
> >
> > My host will not allow me use a trusted connection or make registry[/color]
> setting,[color=green]
> > 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[/color][/color]
used[color=blue][color=green]
> > 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[/color]
> key.[color=green]
> > 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[/color]
> get[color=green]
> > in.
> >
> > Thanks,
> > Charlie
> >
> >
> >[/color]
>
>[/color]

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" <rickspiewak@mindspring.com> wrote in message
news:uQS3Yw6PEHA.644@tk2msftngp13.phx.gbl...[color=blue]
> 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:ei79Ws3PEHA.832@TK2MSFTNGP09.phx.gbl...[color=green]
>> 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[/color]
> your[color=green]
>> 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[/color]
> find[color=green]
>> a better approach, please post it here; there may be other readers in the
>> same situation.
>>
>> Alek
>>
>> "Charlie@CBFC" <charle1@comcast.net> wrote in message
>> news:O80gzh3PEHA.3232@TK2MSFTNGP11.phx.gbl...[color=darkred]
>> > Hi:
>> >
>> > My host will not allow me use a trusted connection or make registry[/color]
>> setting,[color=darkred]
>> > 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[/color][/color]
> used[color=green][color=darkred]
>> > 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[/color]
>> key.[color=darkred]
>> > 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[/color]
>> get[color=darkred]
>> > in.
>> >
>> > Thanks,
>> > Charlie
>> >
>> >
>> >[/color]
>>
>>[/color]
>
>[/color]

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.

<johndoe@driver.net> wrote in message
news:ezCNuX9PEHA.3304@TK2MSFTNGP12.phx.gbl...[color=blue]
> I wonder if there is some level at which you have to place a level of[/color]
trust.[color=blue]
> 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"[/color]
and[color=blue]
> 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[/color]
of[color=blue]
> hits.
>
>
> "Rick Spiewak" <rickspiewak@mindspring.com> wrote in message
> news:uQS3Yw6PEHA.644@tk2msftngp13.phx.gbl...[color=green]
> > See the following article:
> >[/color][/color]
http://msdn.microsoft.com/library/de...SecNetHT07.asp.[color=blue][color=green]
> > 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[/color][/color]
decrypt[color=blue][color=green]
> > 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[/color][/color]
can't[color=blue][color=green]
> > do
> > this with a Windows app, although you could also do it with a web[/color][/color]
service.[color=blue][color=green]
> >
> > 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[/color][/color]
decryption[color=blue][color=green]
> > 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[/color][/color]
the[color=blue][color=green]
> > encryption steps above.
> >
> > "Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in message
> > news:ei79Ws3PEHA.832@TK2MSFTNGP09.phx.gbl...[color=darkred]
> >> Charlie,
> >>
> >> If you use passwords for user authentication only, do not use[/color][/color][/color]
encryption,[color=blue][color=green][color=darkred]
> >> 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[/color][/color][/color]
passphrase[color=blue][color=green][color=darkred]
> >> (to generate encryption key) in your code, so if a hacker gets hold of[/color]
> > your[color=darkred]
> >> 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[/color]
> > find[color=darkred]
> >> a better approach, please post it here; there may be other readers in[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> >> same situation.
> >>
> >> Alek
> >>
> >> "Charlie@CBFC" <charle1@comcast.net> wrote in message
> >> news:O80gzh3PEHA.3232@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[/color][/color][/color]
be[color=blue][color=green][color=darkred]
> >> > stored in web.config file. If I encrypt string externally, can it be[/color]
> > used[color=darkred]
> >> > in it's encrypted form to connect to SQL Server? If I decrypt back[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> >> > string for use in connection string during runtime, I have to supply[/color][/color][/color]
a[color=blue][color=green][color=darkred]
> >> 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[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> >> get
> >> > in.
> >> >
> >> > Thanks,
> >> > Charlie
> >> >
> >> >
> >> >
> >>
> >>[/color]
> >
> >[/color]
>
>[/color]

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" <rickspiewak@mindspring.com> wrote in message
news:uQS3Yw6PEHA.644@tk2msftngp13.phx.gbl...[color=blue]
> See the following article:
>[/color]
http://msdn.microsoft.com/library/de...SecNetHT07.asp.[color=blue]
> 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[/color]
also[color=blue]
> 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[/color]
temporarily[color=blue]
> install on your web site - the encryption technique used here relies on[/color]
the[color=blue]
> machine key for the actual machine on which you are running, so you can't[/color]
do[color=blue]
> 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[/color]
file,[color=blue]
> and then decrypt it at runtime. Then, if you're using an ASP.NET page[/color]
which[color=blue]
> knows how to encrypt/decrypt using DPAPI, you should remove it from your[/color]
web[color=blue]
> 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[/color]
you're[color=blue]
> 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:ei79Ws3PEHA.832@TK2MSFTNGP09.phx.gbl...[color=green]
> > Charlie,
> >
> > If you use passwords for user authentication only, do not use[/color][/color]
encryption,[color=blue][color=green]
> > 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[/color][/color]
passphrase[color=blue][color=green]
> > (to generate encryption key) in your code, so if a hacker gets hold of[/color]
> your[color=green]
> > assembly, this passphrase can be easily retrieved unless you obfuscate[/color][/color]
the[color=blue][color=green]
> > assembly using a good commercial obfuscator (and even this will not
> > guarantee security). Unfortunately, you don't have many options. If you[/color]
> find[color=green]
> > a better approach, please post it here; there may be other readers in[/color][/color]
the[color=blue][color=green]
> > same situation.
> >
> > Alek
> >
> > "Charlie@CBFC" <charle1@comcast.net> wrote in message
> > news:O80gzh3PEHA.3232@TK2MSFTNGP11.phx.gbl...[color=darkred]
> > > Hi:
> > >
> > > My host will not allow me use a trusted connection or make registry[/color]
> > setting,[color=darkred]
> > > 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[/color][/color]
> used[color=green][color=darkred]
> > > 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[/color]
> > key.[color=darkred]
> > > If I do that, hacker could use key to break encryption. How do I[/color][/color][/color]
handle[color=blue][color=green][color=darkred]
> > > this? I'll be storing passwords in database and don't want a hacker[/color][/color][/color]
to[color=blue][color=green]
> > get[color=darkred]
> > > in.
> > >
> > > Thanks,
> > > Charlie
> > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

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:u809F4HQEHA.3708@TK2MSFTNGP10.phx.gbl...[color=blue]
> 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[/color]
able[color=blue]
> to decrypt data encrypted using DPAPI with machine key, so it is not[/color]
really[color=blue]
> 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[/color]
what[color=blue]
> can you do? I assume that there is at least some level of trust between[/color]
you[color=blue]
> and the hosting company. Suspecting the hosting company to intentionally
> hack your application is probably not reasonable (although who knows?),[/color]
but[color=blue]
> 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[/color]
phrase[color=blue]
> in the source code and obfuscate the assembly. Assuming that the[/color]
application[color=blue]
> 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" <rickspiewak@mindspring.com> wrote in message
> news:uQS3Yw6PEHA.644@tk2msftngp13.phx.gbl...[color=green]
> > See the following article:
> >[/color]
>[/color]
http://msdn.microsoft.com/library/de...SecNetHT07.asp.[color=blue][color=green]
> > 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[/color][/color]
decrypt[color=blue][color=green]
> > 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[/color]
> also[color=green]
> > 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[/color]
> temporarily[color=green]
> > install on your web site - the encryption technique used here relies on[/color]
> the[color=green]
> > machine key for the actual machine on which you are running, so you[/color][/color]
can't[color=blue]
> do[color=green]
> > this with a Windows app, although you could also do it with a web[/color][/color]
service.[color=blue][color=green]
> >
> > You can then encrypt the connection string, and put it into the config[/color]
> file,[color=green]
> > and then decrypt it at runtime. Then, if you're using an ASP.NET page[/color]
> which[color=green]
> > knows how to encrypt/decrypt using DPAPI, you should remove it from your[/color]
> web[color=green]
> > site since anyone who could find their way to it could use the[/color][/color]
decryption[color=blue][color=green]
> > facility!!
> >
> > The only caveat is that if your hosting service replaces the machine[/color]
> you're[color=green]
> > running on and doesn't maintain the machine key, you'll have to re-do[/color][/color]
the[color=blue][color=green]
> > encryption steps above.
> >
> > "Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in message
> > news:ei79Ws3PEHA.832@TK2MSFTNGP09.phx.gbl...[color=darkred]
> > > Charlie,
> > >
> > > If you use passwords for user authentication only, do not use[/color][/color]
> encryption,[color=green][color=darkred]
> > > use hashing (with salt) instead. If you need to use encryption, in[/color][/color][/color]
your[color=blue][color=green][color=darkred]
> > > 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[/color][/color]
> passphrase[color=green][color=darkred]
> > > (to generate encryption key) in your code, so if a hacker gets hold of[/color]
> > your[color=darkred]
> > > assembly, this passphrase can be easily retrieved unless you obfuscate[/color][/color]
> the[color=green][color=darkred]
> > > assembly using a good commercial obfuscator (and even this will not
> > > guarantee security). Unfortunately, you don't have many options. If[/color][/color][/color]
you[color=blue][color=green]
> > find[color=darkred]
> > > a better approach, please post it here; there may be other readers in[/color][/color]
> the[color=green][color=darkred]
> > > same situation.
> > >
> > > Alek
> > >
> > > "Charlie@CBFC" <charle1@comcast.net> wrote in message
> > > news:O80gzh3PEHA.3232@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[/color][/color][/color]
be[color=blue][color=green][color=darkred]
> > > > stored in web.config file. If I encrypt string externally, can it[/color][/color][/color]
be[color=blue][color=green]
> > used[color=darkred]
> > > > in it's encrypted form to connect to SQL Server? If I decrypt back[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> > > > string for use in connection string during runtime, I have to supply[/color][/color][/color]
a[color=blue][color=green][color=darkred]
> > > key.
> > > > If I do that, hacker could use key to break encryption. How do I[/color][/color]
> handle[color=green][color=darkred]
> > > > this? I'll be storing passwords in database and don't want a hacker[/color][/color]
> to[color=green][color=darkred]
> > > get
> > > > in.
> > > >
> > > > Thanks,
> > > > Charlie
> > > >
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

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" <rickspiewak@mindspring.com> wrote in message
news:u5r7U3eQEHA.2936@TK2MSFTNGP12.phx.gbl...[color=blue]
> Yes, but the "other application" would need access to your web.config[/color]
file.[color=blue]
> Remember, that the objective in security can never be "absolute" - it's[/color]
just[color=blue]
> 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:u809F4HQEHA.3708@TK2MSFTNGP10.phx.gbl...[color=green]
> > 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[/color]
> able[color=green]
> > to decrypt data encrypted using DPAPI with machine key, so it is not[/color]
> really[color=green]
> > 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[/color][/color]
you[color=blue][color=green]
> > 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.[/color][/color]
You[color=blue][color=green]
> > share the server with other customers, so in addition to external[/color][/color]
hackers[color=blue][color=green]
> > there is a potential threat coming from your neighbors. And your server[/color][/color]
is[color=blue][color=green]
> > 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[/color]
> what[color=green]
> > can you do? I assume that there is at least some level of trust between[/color]
> you[color=green]
> > and the hosting company. Suspecting the hosting company to intentionally
> > hack your application is probably not reasonable (although who knows?),[/color]
> but[color=green]
> > 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[/color]
> phrase[color=green]
> > in the source code and obfuscate the assembly. Assuming that the[/color]
> application[color=green]
> > does not give access to the FBI files or Citibank accounts, it should be[/color][/color]
a[color=blue][color=green]
> > reasonably sufficient deterrent for most hackers. Using DPAPI with[/color][/color]
machine[color=blue][color=green]
> > store (and secondary entropy + obfuscation) is another alternative, but[/color][/color]
it[color=blue][color=green]
> > is too much overhead with no additional benefits. And there is a[/color][/color]
potential[color=blue][color=green]
> > to lose data in case the application is moved to a different server,[/color][/color]
which[color=blue][color=green]
> > is not unheard of.
> >
> > Alek
> >
> > "Rick Spiewak" <rickspiewak@mindspring.com> wrote in message
> > news:uQS3Yw6PEHA.644@tk2msftngp13.phx.gbl...[color=darkred]
> > > See the following article:
> > >[/color]
> >[/color]
>[/color]
http://msdn.microsoft.com/library/de...SecNetHT07.asp.[color=blue][color=green][color=darkred]
> > > This describes the use of the DPAPI library and the machine key (or[/color][/color][/color]
user[color=blue][color=green][color=darkred]
> > > key, but for your purpose stick to the machine key) to encrypt and[/color][/color]
> decrypt[color=green][color=darkred]
> > > things like the connection string. Because the key is known by the[/color][/color][/color]
DPAPI[color=blue][color=green][color=darkred]
> > > library, you don't need to provide it (or even know it).
> > >
> > > You can pretty easily follow the article, and compile the library.[/color][/color][/color]
I've[color=blue][color=green]
> > also[color=darkred]
> > > written a VB.NET "wrapper" which simplifies the use of this library[/color][/color][/color]
(but[color=blue][color=green][color=darkred]
> > > 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[/color]
> > temporarily[color=darkred]
> > > install on your web site - the encryption technique used here relies[/color][/color][/color]
on[color=blue][color=green]
> > the[color=darkred]
> > > machine key for the actual machine on which you are running, so you[/color][/color]
> can't[color=green]
> > do[color=darkred]
> > > this with a Windows app, although you could also do it with a web[/color][/color]
> service.[color=green][color=darkred]
> > >
> > > You can then encrypt the connection string, and put it into the config[/color]
> > file,[color=darkred]
> > > and then decrypt it at runtime. Then, if you're using an ASP.NET page[/color]
> > which[color=darkred]
> > > knows how to encrypt/decrypt using DPAPI, you should remove it from[/color][/color][/color]
your[color=blue][color=green]
> > web[color=darkred]
> > > site since anyone who could find their way to it could use the[/color][/color]
> decryption[color=green][color=darkred]
> > > facility!!
> > >
> > > The only caveat is that if your hosting service replaces the machine[/color]
> > you're[color=darkred]
> > > running on and doesn't maintain the machine key, you'll have to re-do[/color][/color]
> the[color=green][color=darkred]
> > > encryption steps above.
> > >
> > > "Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in message
> > > news:ei79Ws3PEHA.832@TK2MSFTNGP09.phx.gbl...
> > > > Charlie,
> > > >
> > > > If you use passwords for user authentication only, do not use[/color]
> > encryption,[color=darkred]
> > > > use hashing (with salt) instead. If you need to use encryption, in[/color][/color]
> your[color=green][color=darkred]
> > > > particular scenario (Web hosting environment to which you have[/color][/color][/color]
limited[color=blue][color=green][color=darkred]
> > > > 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[/color]
> > passphrase[color=darkred]
> > > > (to generate encryption key) in your code, so if a hacker gets hold[/color][/color][/color]
of[color=blue][color=green][color=darkred]
> > > your
> > > > assembly, this passphrase can be easily retrieved unless you[/color][/color][/color]
obfuscate[color=blue][color=green]
> > the[color=darkred]
> > > > assembly using a good commercial obfuscator (and even this will not
> > > > guarantee security). Unfortunately, you don't have many options. If[/color][/color]
> you[color=green][color=darkred]
> > > find
> > > > a better approach, please post it here; there may be other readers[/color][/color][/color]
in[color=blue][color=green]
> > the[color=darkred]
> > > > same situation.
> > > >
> > > > Alek
> > > >
> > > > "Charlie@CBFC" <charle1@comcast.net> wrote in message
> > > > news:O80gzh3PEHA.3232@TK2MSFTNGP11.phx.gbl...
> > > > > Hi:
> > > > >
> > > > > My host will not allow me use a trusted connection or make[/color][/color][/color]
registry[color=blue][color=green][color=darkred]
> > > > setting,
> > > > > so I'm stuck trying find a way to hide connection string which[/color][/color][/color]
will[color=blue]
> be[color=green][color=darkred]
> > > > > stored in web.config file. If I encrypt string externally, can it[/color][/color]
> be[color=green][color=darkred]
> > > used
> > > > > in it's encrypted form to connect to SQL Server? If I decrypt[/color][/color][/color]
back[color=blue]
> to[color=green][color=darkred]
> > > > > string for use in connection string during runtime, I have to[/color][/color][/color]
supply[color=blue]
> a[color=green][color=darkred]
> > > > key.
> > > > > If I do that, hacker could use key to break encryption. How do I[/color]
> > handle[color=darkred]
> > > > > this? I'll be storing passwords in database and don't want a[/color][/color][/color]
hacker[color=blue][color=green]
> > to[color=darkred]
> > > > get
> > > > > in.
> > > > >
> > > > > Thanks,
> > > > > Charlie
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

johndoe@driver.net wrote:
[color=blue]
>
> 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.
>[/color]

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

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:%23B%239b9eQEHA.2716@tk2msftngp13.phx.gbl...[color=blue]
> 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" <rickspiewak@mindspring.com> wrote in message
> news:u5r7U3eQEHA.2936@TK2MSFTNGP12.phx.gbl...[color=green]
> > Yes, but the "other application" would need access to your web.config[/color]
> file.[color=green]
> > Remember, that the objective in security can never be "absolute" - it's[/color]
> just[color=green]
> > to make the cost of acquiring information greater than the value. You[/color][/color]
can[color=blue][color=green]
> > 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:u809F4HQEHA.3708@TK2MSFTNGP10.phx.gbl...[color=darkred]
> > > I don't think that using DPAPI with machine key gives you any[/color][/color][/color]
particular[color=blue][color=green][color=darkred]
> > > advantage. After all any application running on the same server will[/color][/color][/color]
be[color=blue][color=green]
> > able[color=darkred]
> > > to decrypt data encrypted using DPAPI with machine key, so it is not[/color]
> > really[color=darkred]
> > > secure, unless you use secondary entropy, but if you do, it is no[/color][/color][/color]
better[color=blue][color=green][color=darkred]
> > > than hiding encryption key (or pass phrase) in the source code (since[/color][/color]
> you[color=green][color=darkred]
> > > need to store this entropy somewhere).
> > >
> > > The truth is that in a Web hosting environment, all feasible options[/color][/color][/color]
are[color=blue][color=green][color=darkred]
> > > 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[/color][/color][/color]
about[color=blue][color=green][color=darkred]
> > > dedicated hosting) is probably the worst environment you can think of.[/color][/color]
> You[color=green][color=darkred]
> > > share the server with other customers, so in addition to external[/color][/color]
> hackers[color=green][color=darkred]
> > > there is a potential threat coming from your neighbors. And your[/color][/color][/color]
server[color=blue]
> is[color=green][color=darkred]
> > > 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[/color]
> > what[color=darkred]
> > > can you do? I assume that there is at least some level of trust[/color][/color][/color]
between[color=blue][color=green]
> > you[color=darkred]
> > > and the hosting company. Suspecting the hosting company to[/color][/color][/color]
intentionally[color=blue][color=green][color=darkred]
> > > hack your application is probably not reasonable (although who[/color][/color][/color]
knows?),[color=blue][color=green]
> > but[color=darkred]
> > > 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[/color]
> > phrase[color=darkred]
> > > in the source code and obfuscate the assembly. Assuming that the[/color]
> > application[color=darkred]
> > > does not give access to the FBI files or Citibank accounts, it should[/color][/color][/color]
be[color=blue]
> a[color=green][color=darkred]
> > > reasonably sufficient deterrent for most hackers. Using DPAPI with[/color][/color]
> machine[color=green][color=darkred]
> > > store (and secondary entropy + obfuscation) is another alternative,[/color][/color][/color]
but[color=blue]
> it[color=green][color=darkred]
> > > is too much overhead with no additional benefits. And there is a[/color][/color]
> potential[color=green][color=darkred]
> > > to lose data in case the application is moved to a different server,[/color][/color]
> which[color=green][color=darkred]
> > > is not unheard of.
> > >
> > > Alek
> > >
> > > "Rick Spiewak" <rickspiewak@mindspring.com> wrote in message
> > > news:uQS3Yw6PEHA.644@tk2msftngp13.phx.gbl...
> > > > See the following article:
> > > >
> > >[/color]
> >[/color]
>[/color]
http://msdn.microsoft.com/library/de...SecNetHT07.asp.[color=blue][color=green][color=darkred]
> > > > This describes the use of the DPAPI library and the machine key (or[/color][/color]
> user[color=green][color=darkred]
> > > > key, but for your purpose stick to the machine key) to encrypt and[/color]
> > decrypt[color=darkred]
> > > > things like the connection string. Because the key is known by the[/color][/color]
> DPAPI[color=green][color=darkred]
> > > > library, you don't need to provide it (or even know it).
> > > >
> > > > You can pretty easily follow the article, and compile the library.[/color][/color]
> I've[color=green][color=darkred]
> > > also
> > > > written a VB.NET "wrapper" which simplifies the use of this library[/color][/color]
> (but[color=green][color=darkred]
> > > > still requires it) if you're interested. You will then need to use[/color][/color][/color]
an[color=blue][color=green][color=darkred]
> > > > 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[/color][/color]
> on[color=green][color=darkred]
> > > the
> > > > machine key for the actual machine on which you are running, so you[/color]
> > can't[color=darkred]
> > > do
> > > > this with a Windows app, although you could also do it with a web[/color]
> > service.[color=darkred]
> > > >
> > > > You can then encrypt the connection string, and put it into the[/color][/color][/color]
config[color=blue][color=green][color=darkred]
> > > file,
> > > > and then decrypt it at runtime. Then, if you're using an ASP.NET[/color][/color][/color]
page[color=blue][color=green][color=darkred]
> > > which
> > > > knows how to encrypt/decrypt using DPAPI, you should remove it from[/color][/color]
> your[color=green][color=darkred]
> > > web
> > > > site since anyone who could find their way to it could use the[/color]
> > decryption[color=darkred]
> > > > 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[/color][/color][/color]
re-do[color=blue][color=green]
> > the[color=darkred]
> > > > encryption steps above.
> > > >
> > > > "Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in[/color][/color][/color]
message[color=blue][color=green][color=darkred]
> > > > news:ei79Ws3PEHA.832@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[/color]
> > your[color=darkred]
> > > > > particular scenario (Web hosting environment to which you have[/color][/color]
> limited[color=green][color=darkred]
> > > > > access), the best you can do is use a tool like CipherLite.NET[/color][/color][/color]
(see[color=blue][color=green][color=darkred]
> > > > > http://www.obviex.com/cipherlite/). You will need to embed the
> > > passphrase
> > > > > (to generate encryption key) in your code, so if a hacker gets[/color][/color][/color]
hold[color=blue]
> of[color=green][color=darkred]
> > > > your
> > > > > assembly, this passphrase can be easily retrieved unless you[/color][/color]
> obfuscate[color=green][color=darkred]
> > > the
> > > > > assembly using a good commercial obfuscator (and even this will[/color][/color][/color]
not[color=blue][color=green][color=darkred]
> > > > > guarantee security). Unfortunately, you don't have many options.[/color][/color][/color]
If[color=blue][color=green]
> > you[color=darkred]
> > > > find
> > > > > a better approach, please post it here; there may be other readers[/color][/color]
> in[color=green][color=darkred]
> > > the
> > > > > same situation.
> > > > >
> > > > > Alek
> > > > >
> > > > > "Charlie@CBFC" <charle1@comcast.net> wrote in message
> > > > > news:O80gzh3PEHA.3232@TK2MSFTNGP11.phx.gbl...
> > > > > > Hi:
> > > > > >
> > > > > > My host will not allow me use a trusted connection or make[/color][/color]
> registry[color=green][color=darkred]
> > > > > setting,
> > > > > > so I'm stuck trying find a way to hide connection string which[/color][/color]
> will[color=green]
> > be[color=darkred]
> > > > > > stored in web.config file. If I encrypt string externally, can[/color][/color][/color]
it[color=blue][color=green]
> > be[color=darkred]
> > > > used
> > > > > > in it's encrypted form to connect to SQL Server? If I decrypt[/color][/color]
> back[color=green]
> > to[color=darkred]
> > > > > > string for use in connection string during runtime, I have to[/color][/color]
> supply[color=green]
> > a[color=darkred]
> > > > > key.
> > > > > > If I do that, hacker could use key to break encryption. How do[/color][/color][/color]
I[color=blue][color=green][color=darkred]
> > > handle
> > > > > > this? I'll be storing passwords in database and don't want a[/color][/color]
> hacker[color=green][color=darkred]
> > > to
> > > > > get
> > > > > > in.
> > > > > >
> > > > > > Thanks,
> > > > > > Charlie
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

"Rick Spiewak" wrote:
[color=blue]
> An interesting point, which may be unique to the shared host environment![/color]
It[color=blue]
> may lead me to favor using entropy as well. This would require more[/color]
effort,[color=blue]
> and skill, to exploit - assuming the entropy value was hidden inside the
> code.[/color]

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)?
[color=blue]
> Yes, it's true that a change in hardware might disable an application[/color]
which[color=blue]
> 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[/color]
could[color=blue]
> 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[/color]
for[color=blue]
> the same reason).[/color]

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.
[color=blue]
> 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.[/color]

The same is true for traditional symmetric key encryption.

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...

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" <satuttle@yahoo.com> wrote in message
news:%238LLh2YSEHA.3224@TK2MSFTNGP10.phx.gbl...[color=blue]
> You do not need to encrypt anything if you are placing it in your[/color]
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.[color=blue]
>
> My guess if the guy is smart enough to be able to get to your web.config[/color]
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.[color=blue]
>
> ************************************************** ********************
> Sent via Fuzzy Software @ http://www.fuzzysoftware.com/
> Comprehensive, categorised, searchable collection of links to ASP &[/color]
ASP.NET resources...