F
Frank O'Hara
I was hoping to open something up for a simple discussion.
We all subscribe to the idea of increasing security at any and all
points - including but not limited to network security, application
security, etc, etc. And of course we all know that a system is only
as strong as its weakest point so in the case of security a weakness
can and will probably be exploited eventually.
I've recently been exploring the options availble to securing database
connection strings, specifically in web.config files (or more
accurately, in ASP.NET applications). After some quick research it
seemed like there were no shortage of possbile solutions, each one
with distinct pros and cons. Based on my requirements it looks as
though DPAPI is the road I'm going to go down but it got me thinking a
little (please bear with me here) as it is used by another area of our
application.
As I mentioned, with every possible solution there is always an
underlying weakness that can be exploited, for example, encrypting the
data with the strongest encryption algorithms is great, however, key
management becomes the achillies heel and so on and so on.
Let me propose something unconventional. Let's leave the web.config
file data unencrypted. Yes you heard me correctly. I know, I know Am
I joking...well consider this. Surely you're thinking that if someone
(hacker, disgrunted employee, nosey Fred from Accounting) happens
across the web.config file either deliberately or accidentally then
they have access to potentially sensitive data and information.
Absolutely, but let's consider how they were able to get the
information in the first place. The casual user who accidentally
stumbled upon the information should NEVER have had access to the file
in the first place. There is no reason it should be available to
anyone other than the Administrator's group, ASP.NET and possibly
developers (although in a production environment they shouldn't have
access). So the problem is not that web.config data is unencrypted
the problem is that the security settings on the file system are not
set correctly.
Ok, let's get past that. What about the malicous user who has
circumvented your network and file level security and gained
unauthorized access. This is clearly a reality and most often occurs
from an internal source rather than an external one. So again the
arguement holds that this person has access to potentially sensitive
information that can be used to exploit other areas of the system.
Clearly this is not ideal! However, let's consider the situation with
encrypted data. If the data is encrypted it will at some point (to be
used) have to be unencrypted. And viola, we have our entry point. If
the person has gained system access to the point where they are
reading the contents of a file that they have no business reading and
have circumvented some security in order to do so then it stands to
reason that they probably have the ability to do something simple like
disassemble a .dll (especially a .NET managed code .dll(s)). With the
disassembled code our malicous person now has access to the decryption
algorithm, they're set.
Even something secured with DPAPI can be decrypted by using the actual
libraries the application code uses (they're all in the *bin* folder
just waiting to be used). The same can be done with a key (stored in
the registry, or in a file, etc, etc). At first I didn't think it
could be that easily but I was surprised at how easy it was to create
a really quick .aspx page that loaded the assembly responsible for
encryting/decrypting data (using DPAPI) and simply send in the
encrypted string to reveal the original text.
Now please, before I receive a ton of flames and other posts telling
me how using layers of security makes things more difficult and is
always the better solution because potential 'would be hackers' (for
lack of a better name) may move onto an easier target, etc, etc, let
me just say YES, I KNOW. I couldn't agree more and tiered security is
[obviously] the method we employ, however, this post was simply meant
to envoke a discussion. It really stemmed from the fact that it was
so easy to decrypt the data (granted I had administrator access and
with that access there are a lot of *bad* things I could do - but
getting administrator access to a system is not necessarily always a
problem).
Anyway, give it some thought. I am interested in people's thoughts on
the subject especially from security experts, etc. I am by no means a
security person but am very much intrigued by security and how some
people are able to circumventing it - usually very easily.
Frank.
PS If your inclination is to just flame then don't bother responding
as I won't give you the satisfaction of a retort - sorry.
We all subscribe to the idea of increasing security at any and all
points - including but not limited to network security, application
security, etc, etc. And of course we all know that a system is only
as strong as its weakest point so in the case of security a weakness
can and will probably be exploited eventually.
I've recently been exploring the options availble to securing database
connection strings, specifically in web.config files (or more
accurately, in ASP.NET applications). After some quick research it
seemed like there were no shortage of possbile solutions, each one
with distinct pros and cons. Based on my requirements it looks as
though DPAPI is the road I'm going to go down but it got me thinking a
little (please bear with me here) as it is used by another area of our
application.
As I mentioned, with every possible solution there is always an
underlying weakness that can be exploited, for example, encrypting the
data with the strongest encryption algorithms is great, however, key
management becomes the achillies heel and so on and so on.
Let me propose something unconventional. Let's leave the web.config
file data unencrypted. Yes you heard me correctly. I know, I know Am
I joking...well consider this. Surely you're thinking that if someone
(hacker, disgrunted employee, nosey Fred from Accounting) happens
across the web.config file either deliberately or accidentally then
they have access to potentially sensitive data and information.
Absolutely, but let's consider how they were able to get the
information in the first place. The casual user who accidentally
stumbled upon the information should NEVER have had access to the file
in the first place. There is no reason it should be available to
anyone other than the Administrator's group, ASP.NET and possibly
developers (although in a production environment they shouldn't have
access). So the problem is not that web.config data is unencrypted
the problem is that the security settings on the file system are not
set correctly.
Ok, let's get past that. What about the malicous user who has
circumvented your network and file level security and gained
unauthorized access. This is clearly a reality and most often occurs
from an internal source rather than an external one. So again the
arguement holds that this person has access to potentially sensitive
information that can be used to exploit other areas of the system.
Clearly this is not ideal! However, let's consider the situation with
encrypted data. If the data is encrypted it will at some point (to be
used) have to be unencrypted. And viola, we have our entry point. If
the person has gained system access to the point where they are
reading the contents of a file that they have no business reading and
have circumvented some security in order to do so then it stands to
reason that they probably have the ability to do something simple like
disassemble a .dll (especially a .NET managed code .dll(s)). With the
disassembled code our malicous person now has access to the decryption
algorithm, they're set.
Even something secured with DPAPI can be decrypted by using the actual
libraries the application code uses (they're all in the *bin* folder
just waiting to be used). The same can be done with a key (stored in
the registry, or in a file, etc, etc). At first I didn't think it
could be that easily but I was surprised at how easy it was to create
a really quick .aspx page that loaded the assembly responsible for
encryting/decrypting data (using DPAPI) and simply send in the
encrypted string to reveal the original text.
Now please, before I receive a ton of flames and other posts telling
me how using layers of security makes things more difficult and is
always the better solution because potential 'would be hackers' (for
lack of a better name) may move onto an easier target, etc, etc, let
me just say YES, I KNOW. I couldn't agree more and tiered security is
[obviously] the method we employ, however, this post was simply meant
to envoke a discussion. It really stemmed from the fact that it was
so easy to decrypt the data (granted I had administrator access and
with that access there are a lot of *bad* things I could do - but
getting administrator access to a system is not necessarily always a
problem).
Anyway, give it some thought. I am interested in people's thoughts on
the subject especially from security experts, etc. I am by no means a
security person but am very much intrigued by security and how some
people are able to circumventing it - usually very easily.
Frank.
PS If your inclination is to just flame then don't bother responding
as I won't give you the satisfaction of a retort - sorry.