Best Practice for storing keys

[tshad]

I am trying to find the best procedure for storing keys used for encryption.

This would also be a question for the connection string to the database. At
the moment, this is kept in the web.info file.

This seems to be norm from all the books on building your Web Apps. Isn't
this a problem as the web.info is cleartext? I would suppose that having
keys (which you would to store/encrypt and get/decrypt from your database)
in this manner would be dangerous.

I am trying to find out how others deal with this. Also, I would need the
same information for my Apps on the same machine.

Thanks,

Tom

[Han]

Hello

Sounds like RSA encription.

http://msdn2.microsoft.com/en-us/library/2w117ede.aspx

Note there is one mistake in the example.

<configProtecte dData>
<providers>
<add name="MyProvide r"
type="System.Co nfiguration.Rsa ProtectedConfig urationProvider ,
System.Configur ation, Version=2.0. 0.0,
Culture=neutral , PublicKeyToken= b03f5f7f11d50a3 a,
processorArchit ecture=MSIL"
keyContainerNam e="MyKeys"
useMachineConta iner="true" />
</providers>
</configProtected Data>

2.0. 0.0 should be 2.0.0.0.

If you are successful encripting some part of your configuration, the key is
secured with NTFS Access Control Lists. Good luck.

"tshad" <ts**********@f tsolutions.comw rote in message
news:%2******** ********@TK2MSF TNGP03.phx.gbl. ..

>I am trying to find the best procedure for storing keys used for
encryption.

This would also be a question for the connection string to the database.
At
the moment, this is kept in the web.info file.

This seems to be norm from all the books on building your Web Apps. Isn't
this a problem as the web.info is cleartext? I would suppose that having
keys (which you would to store/encrypt and get/decrypt from your database)
in this manner would be dangerous.

I am trying to find out how others deal with this. Also, I would need the
same information for my Apps on the same machine.

Thanks,

Tom

[Mark Rae]

"tshad" <ts**********@f tsolutions.comw rote in message
news:%2******** ********@TK2MSF TNGP03.phx.gbl. ..

>I am trying to find the best procedure for storing keys used for
encryption.

Generally speaking, don't store them at all - devise a mechanism for
generating the same key whenever you need it...
http://msdn.microsoft.com/msdnmag/is...efault.aspx#S9

This seems to be norm from all the books on building your Web Apps. Isn't
this a problem as the web.info is cleartext? I would suppose that having
keys (which you would to store/encrypt and get/decrypt from your database)
in this manner would be dangerous.

I think there's a lot of FUD (fear, uncertainty and doubt) surrounding
this...

Firstly, ask yourself who are you hiding this key from...? Your
colleagues...? Your boss...? The office cleaner...? If you are worried about
whether your fellow employees are trustworthy or not, then you have a much
bigger problem then key encryption...

Secondly, is your website's security so lax that your web.config is visible
to the outside world...? Again, if that is the case, then you have a much
more fundamental problem than key encryption...

Are you perhaps worried about "profession al" hackers...? Again, if a hacker
is clever enough to bypass all your security protection and is able to gain
access to your webserver, it probably won't matter much whether your key is
encrypted or not - they'll crack it...

I am trying to find out how others deal with this. Also, I would need the
same information for my Apps on the same machine.

I have an encryption base class which does TripleDES encrpytion. It has two
methods: Encrypt() and Decrypt(). This class, like all my other base
classes, is shared across all projects and clients.

I also have a key generation class which has one method: GenerateKey(). This
generates the key required for the symmetric encryption, and is different
for every client - sometimes different on a project by project basis for the
same client, if that's what they want.

In this way the actual key is not "stored" anywhere. You might say that the
key could be found by disassembly - or, at least, the mechanism for
generating the key could be found by disassenbly - but I take the view that
if a hacker is determined enough to have disassembled my code, they would
have found the key soon enough anyway...

There has to come a point where it's "secure enough", otherwise you'll never
get anything done...:-)

E.g. can you decrypt this:

HgyxhIIBwBb7zY7 GBH4xlQ==

?

[tshad]

"Mark Rae" <ma**@markNOSPA Mrae.comwrote in message
news:ut******** ******@TK2MSFTN GP03.phx.gbl...

"tshad" <ts**********@f tsolutions.comw rote in message
news:%2******** ********@TK2MSF TNGP03.phx.gbl. ..

>>I am trying to find the best procedure for storing keys used for
encryption.

Generally speaking, don't store them at all - devise a mechanism for
generating the same key whenever you need it...
http://msdn.microsoft.com/msdnmag/is...efault.aspx#S9

>This seems to be norm from all the books on building your Web Apps.
Isn't
this a problem as the web.info is cleartext? I would suppose that having
keys (which you would to store/encrypt and get/decrypt from your
database)
in this manner would be dangerous.

I think there's a lot of FUD (fear, uncertainty and doubt) surrounding
this...

Yes.

But if you store information such as Credit Card or Social Security
information - you want that.

>
Firstly, ask yourself who are you hiding this key from...? Your
colleagues...? Your boss...? The office cleaner...?

Yes.

>If you are worried about whether your fellow employees are trustworthy or
not, then you have a much bigger problem then key encryption...

Secondly, is your website's security so lax that your web.config is
visible to the outside world...? Again, if that is the case, then you have
a much more fundamental problem than key encryption...

Even if your security is good - people do get in. Ours is pretty secure but
as you mention below the Professional Hackers may find a way in.

>
Are you perhaps worried about "profession al" hackers...? Again, if a
hacker is clever enough to bypass all your security protection and is able
to gain access to your webserver, it probably won't matter much whether
your key is encrypted or not - they'll crack it...

>I am trying to find out how others deal with this. Also, I would need
the
same information for my Apps on the same machine.

I have an encryption base class which does TripleDES encrpytion. It has
two methods: Encrypt() and Decrypt(). This class, like all my other base
classes, is shared across all projects and clients.

This is what I do.

I also have a key generation class which has one method: GenerateKey().
This generates the key required for the symmetric encryption, and is
different for every client - sometimes different on a project by project
basis for the same client, if that's what they want.

At the moment, I am creating one key for all clients. Just a random set of
letters, numbers and special characters. This is passed to both the Encrypt
and Decrypt functions.

I would only be Generating the Key once (or else I would never be able to
decrypt the data). You would have to store something somewhere for the
program to use it (either the data to Generate the Key from or the Key
itself).

In this way the actual key is not "stored" anywhere. You might say that
the key could be found by disassembly - or, at least, the mechanism for
generating the key could be found by disassenbly - but I take the view
that if a hacker is determined enough to have disassembled my code, they
would have found the key soon enough anyway...

There has to come a point where it's "secure enough", otherwise you'll
never get anything done...:-)

I agree here.

I just want to find a pretty reasonable solution.

Thanks,

Tom

>
E.g. can you decrypt this:

HgyxhIIBwBb7zY7 GBH4xlQ==

?

[Mark Rae]

"tshad" <ts**********@f tsolutions.comw rote in message
news:uK******** *****@TK2MSFTNG P03.phx.gbl...

Even if your security is good - people do get in. Ours is pretty secure
but as you mention below the Professional Hackers may find a way in.

And you will never eliminate that threat 100%...

I would only be Generating the Key once (or else I would never be able to
decrypt the data). You would have to store something somewhere for the
program to use it (either the data to Generate the Key from or the Key
itself).

NO! And that's the whole point! You don't "store" anything anywhere - you
just devise a routine / algorithm / whatever which always generates the same
key...

>There has to come a point where it's "secure enough", otherwise you'll
never get anything done...:-)

I agree here.

I just want to find a pretty reasonable solution.

Well, there's an argument which says that there comes a point where your
data is *so* sensitive that access to it over the (public) Internet is
always going to be the wrong solution, irrespective of the technology you
use... That's why e.g. hashes are salted, otherwise I could simply steal
your database, get myself a copy of the Oxford English and use every word in
it as the key until I found a match in your encrypted data. You might think
that's an extreme example (and you'd be right!), but with the power of
computers these days, that might be only a few hours' work...

[tshad]

"Mark Rae" <ma**@markNOSPA Mrae.comwrote in message
news:u5******** ******@TK2MSFTN GP04.phx.gbl...

"tshad" <ts**********@f tsolutions.comw rote in message
news:uK******** *****@TK2MSFTNG P03.phx.gbl...

>Even if your security is good - people do get in. Ours is pretty secure
but as you mention below the Professional Hackers may find a way in.

And you will never eliminate that threat 100%...

I'm not trying to do that. Just don't want to do something simple like
base64 :)

>

>I would only be Generating the Key once (or else I would never be able to
decrypt the data). You would have to store something somewhere for the
program to use it (either the data to Generate the Key from or the Key
itself).

NO! And that's the whole point! You don't "store" anything anywhere - you
just devise a routine / algorithm / whatever which always generates the
same key...

But then what are you using to Generate the Key? It needs to come from
somewhere, doesn't it? You need to use the same key to decrypt the data.
In your GenerateKey() don't you pass it something? That would have to be
stored somewhere.

Tom

>>There has to come a point where it's "secure enough", otherwise you'll
never get anything done...:-)

I agree here.

I just want to find a pretty reasonable solution.

Well, there's an argument which says that there comes a point where your
data is *so* sensitive that access to it over the (public) Internet is
always going to be the wrong solution, irrespective of the technology you
use... That's why e.g. hashes are salted, otherwise I could simply steal
your database, get myself a copy of the Oxford English and use every word
in it as the key until I found a match in your encrypted data. You might
think that's an extreme example (and you'd be right!), but with the power
of computers these days, that might be only a few hours' work...

[Mark Rae]

"tshad" <ts**********@f tsolutions.comw rote in message
news:%2******** **********@TK2M SFTNGP06.phx.gb l...

>NO! And that's the whole point! You don't "store" anything anywhere - you
just devise a routine / algorithm / whatever which always generates the
same key...

But then what are you using to Generate the Key?

An algorithm which always generates the same string.

It needs to come from somewhere, doesn't it?

Yes - itself.

You need to use the same key to decrypt the data.

That's right.

In your GenerateKey() don't you pass it something?

No.

That would have to be stored somewhere.

I guess it would - if that's actually what I was doing... :-)

E.g.

private string GenerateKey()
{
return (2 + 2).ToString();
}

[tshad]

"Mark Rae" <ma**@markNOSPA Mrae.comwrote in message
news:eB******** ********@TK2MSF TNGP06.phx.gbl. ..

"tshad" <ts**********@f tsolutions.comw rote in message
news:%2******** **********@TK2M SFTNGP06.phx.gb l...

>>NO! And that's the whole point! You don't "store" anything anywhere -
you just devise a routine / algorithm / whatever which always generates
the same key...

But then what are you using to Generate the Key?

An algorithm which always generates the same string.

>It needs to come from somewhere, doesn't it?

Yes - itself.

>You need to use the same key to decrypt the data.

That's right.

>In your GenerateKey() don't you pass it something?

No.

>That would have to be stored somewhere.

I guess it would - if that's actually what I was doing... :-)

E.g.

private string GenerateKey()
{
return (2 + 2).ToString();
}

But this wouldn't work for each customer if each customer had to have a
different key, would it?

Tom

[Mark Rae]

"tshad" <ts**********@f tsolutions.comw rote in message
news:un******** *****@TK2MSFTNG P02.phx.gbl...

>private string GenerateKey()
{
return (2 + 2).ToString();
}

But this wouldn't work for each customer if each customer had to have a
different key, would it?

???

The encryption base class is constant across all clients and projects.

The key generation class is specific to each client and/or each project.

[tshad]

"Mark Rae" <ma**@markNOSPA Mrae.comwrote in message
news:%2******** ********@TK2MSF TNGP06.phx.gbl. ..

"tshad" <ts**********@f tsolutions.comw rote in message
news:un******** *****@TK2MSFTNG P02.phx.gbl...

>>private string GenerateKey()
{
return (2 + 2).ToString();
}

But this wouldn't work for each customer if each customer had to have a
different key, would it?

???

The encryption base class is constant across all clients and projects.

The key generation class is specific to each client and/or each project.

So you have a different class for each client/project? Where do you get the
value that you are returning for each client? Is it just some random
number?

Tom