Best practice for "hiding" secrets

  • Thread starter Thread starter Picho
  • Start date Start date
P

Picho

Hi all,

Lets say I have a "secret" I wish to "hide", lets say a database password.
For the more detailed problem, a web application/service that uses a
connection string.

all the solutions I came up with (embedding in code, encrypting-decrypting)
involve embedding the/another secret in the code. since my problem cannot
request a user intervention, I am at a stop.

what will be the best way to avoid writing secrets in code or hiding them
anywhere else (registry, external files) while avoiding user intervention to
retrieve the secret?

Thanx,

Picho

P.S. - I am taking into consideration the axume that says that anything
embedded (hard coded) in the code can be extracted by means of debugging or
reflecting etc.
 
This approach is a radical shift for some shops, but do not allow any
applications to make connections into your database. (jaw drops on chest).
Instead, have your apps connect to a component that establishes a connection
and returns a DataSet, DataReader, etc. Then use Domain security to
determine who can access which data. We face this challenge every day at my
clients' sites. Some accept this change, some fight it. Just have to ask
yourself if security is important to you.
 
thank you Keith for your reply.

what you say is not a practical solution, we could easly be discussing the
way that 'component' connects to the database (the web-application is not so
different than any other component except for the channel it uses or being
in the DMZ)....

Picho
 
This is what aspnet_setreg was created for.

See this article:
http://msdn.microsoft.com/library/d.../en-us/cpgenref/html/gngrfidentitysection.asp

The idea is to store your credentials in a registry setting, in an encrypted
format. Even if someone gets your app, they don't get the registry. You
can set ACLs on the registry keys to prevent anyone outside the network from
getting the encrypted credentials. There is a utility already in existence
to allow system admins to encrypt the credentials and store them into the
correct spots, and your config files can pull the credentials without many
code changes on your part.

HTH
--- Nick
 
Understood, but that is why you have obfuscators and MD5, etc. It's a lot
safer in if you get the goodies out of an ASP file.

We also use the method Nick suggests with mixed results. If you go this
route, make sure you use accounts that do not expire automatically. If this
is not an option then be sure to change these passwords before they expire
(reminder in Exchange)
 
This is not an uncommon approach at all and there are several reasons why
this is a good way to go.

First, the UI could be running on a public machine and the component could
be running on a secure machine (which sits behind a firewall). This
prevents the component from the vulnerabilities of a public machine.

Second, by having your data access layer in its own component, no other part
of the application knows anything about where the data comes from or how to
obtain it. This is beneficial in case that code were to get hacked.

-Scott
 
Picho said:
Lets say I have a "secret" I wish to "hide", lets say a database password.
For the more detailed problem, a web application/service that uses a
connection string.

all the solutions I came up with (embedding in code, encrypting-decrypting)
involve embedding the/another secret in the code. since my problem cannot
request a user intervention, I am at a stop.
Click to expand...

The DPAPI stuff is pretty good for a wide variety of problems along this
line. It doesn't cover all the possible cases, but certainly many of 'em.

The ASP.NET Security guide has an excellent overview of DPAPI.
 
thank you guys for the lead, it is very helpful.

just to see if i get it right:
we use a tool (aspnet_setreg) that uses an API func (CryptProtectedData) to
encrypt the un/pwd.

2 questions:

1. assuming that this encryption is role-based and in our case the ASPNET
user account, only the same user can decrypt the information?
2. if 1 is true, do we know of a way to impersonate as ASPNET in order to
decrypt this inforamtion? i am basicly asking how safe is this method.

thank you again

Picho
 
Answers:
1. assuming that this encryption is role-based and in our case the ASPNET
user account, only the same user can decrypt the information?
Click to expand...
1) This tool (aspnet_setreg) uses the DPAPI "LocalMachine" mode so the key
material will be bind to that particular machine (not the user account of
the process)

2) Not apply because of 1).

Note: aspnet_setreg does not use the "additional" entropy value that DAPI
accepts when working on LM mode so anyone with control of your machine (and
of course access to the registry key, that's why you should set a strong ACL
to this key) will be able to decrypt the data.

--
Hernan de Lahitte
Lagash Systems S.A.
http://weblogs.asp.net/hernandl


This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top