Re: Best practice for "hiding" secrets

From: Hernan de Lahitte (hernan_at_lagash.com)
Date: 08/09/04 

Date: Mon, 9 Aug 2004 16:28:20 -0300

Agree with Nick. If you want to further customize aspnet_setreg for your own
configuration settings, you have a sample here:

http://weblogs.asp.net/hernandl/archive/2004/07/30/SensitiveDataInConfigs.aspx 

-- 
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.
"Nick Malik" <nickmalik@hotmail.nospam.com> wrote in message
news:JtMRc.274437$Oq2.260080@attbi_s52...
> This is what aspnet_setreg was created for.
>
> See this article:
>
http://msdn.microsoft.com/library/default.asp?url=/library/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
>
>
> "Picho" <SPAM_picho@telhai.ac.il> wrote in message
> news:uKCxAshfEHA.3520@TK2MSFTNGP10.phx.gbl...
> > 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.
> >
> >
>
>

Relevant Pages

  • Re: Best practice for "hiding" secrets
    ... The idea is to store your credentials in a registry setting, ... Even if someone gets your app, they don't get the registry. ... to allow system admins to encrypt the credentials and store them into the ...
    (microsoft.public.dotnet.framework)
  • Re: Best practice for "hiding" secrets
    ... The idea is to store your credentials in a registry setting, ... Even if someone gets your app, they don't get the registry. ... to allow system admins to encrypt the credentials and store them into the ...
    (microsoft.public.dotnet.general)
  • Re: Best practice for "hiding" secrets
    ... The idea is to store your credentials in a registry setting, ... Even if someone gets your app, they don't get the registry. ... to allow system admins to encrypt the credentials and store them into the ...
    (microsoft.public.dotnet.security)
  • Re: Best practice for "hiding" secrets
    ... Agree with Nick. ... 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 ...
    (microsoft.public.dotnet.general)
  • Re: Best practice for "hiding" secrets
    ... Agree with Nick. ... 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 ...
    (microsoft.public.dotnet.framework)
Loading