Re: Storing encryption strings - best practice?

[Joel Rosenblatt <joel () COLUMBIA EDU>]

This may be an obvious point, but the various disclosure laws state that if the data is encrypted AND the key is not on the 
same server (the law doesn't
actually use these words, but that is what it means), then you do not have to disclose a break in on your server as 
long as the key was not also (possibly)
compromised.

This means that you should try really hard not to have the key on the same server that the data is on.  You may want to 
look into implementing a KEY server of
some type, this will limit your exposure, but it will complicate your programming ... like they say, nothing in life is 
free :-)

My 2 cents,
Joel Rosenblatt

Joel Rosenblatt, Senior Security Officer & Windows Specialist, CUIT
Columbia University, 612 W 115th Street, NY, NY 10025 / 212 854 3033
http://www.columbia.edu/~joel - You can't spell seCUrITy without CUIT


--On Tuesday, March 07, 2006 9:07 AM -0800 David Gillett <gillettdavid () fhda edu> wrote:

>   I'd recommend NOT putting it in the code itself.  We have an application
> here (not
> developed here) that has it in the code, and that means that the same string
> is used
> at every site that has this application -- we can get compromised by a
> failure at some
> other site we don't even know about!  That's BAD.
>   So that leaves a config file or the database.  Either is bound to a
> specific installation,
> so from that perspective it doesn't matter much.
>
>   My preference is the config file, for two reasons:
>
> 1.  An attacker who gets the database may not get the config file.
>
> 2.  Anything in the database that isn't a data table is going to attract
> scrutiny; config
> files routinely contain miscellaneous crufties.
>
>   I do agree that obfuscation is a very good idea.
>
> David Gillett
>
>
>
>   _____
>
> From: Mercer, Susan [mailto:smercer () AII EDU]
> Sent: Tuesday, March 07, 2006 6:33 AM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: [SECURITY] Storing encryption strings - best practice?
>
>
>
> Hi all -
>
>
>
> We are building a custom admissions application using .NET.  We will be
> encrypting the applicant's self-selected passwords and social security
> numbers before storing them in the database.  We're having the application
> hosted by a third party, and are quite comfortable with the security of the
> infrastructure, but we have a question I'd like to pose to the group.
>
>
>
> The encryption algorithm requires a string to "seed" it.  That string is
> used to encrypt the data to store it, and also to unencrypt it to display it
> (SSN only.passwords are 1-way encrypted).  Our question is: where should we
> store this string?
>
>
>
> Our choices are:
>
> *         In a configuration file (least secure should someone get access to
> the machine)
>
> *         In the code itself (more secure.but could be reverse-engineered if
> someone wanted it)
>
> *         In the database (somewhat secure.but could be accessed if someone
> gets access to the database)
>
>
>
> We are also thinking about obfuscation.putting it somewhere with a
> filename/tablename/fieldname that seems quite innocuous and somewhere you
> would never think to look for this type of information.
>
>
>
> I'm sure that others have encountered this issue before.  Any
> recommendations or best practices out there?
>
>
>
> Thanks,
> Susan
>
>
>
> Susan Mercer | EDMC Online Higher Education
>
> Web Producer - Student Services
>
> 1400 Penn Avenue| Pittsburgh, PA 15222-4332
>
> Office: 412-995-2937 | Cell: 412-327-9423
>
> ============================================================================
> =======
> CONFIDENTIALITY NOTICE: This email and any files transmitted with it are
> confidential and intended solely for the use of the individual or entity to
> which they are addressed. If you are not the intended recipient, you may not
> review, copy or distribute this message. If you have received this email in
> error, please notify the sender immediately and delete the original message.
> Neither the sender nor the company for which he or she works accepts any
> liability for any damage caused by any virus transmitted by this email.
> ============================================================================
> =======



Joel Rosenblatt, Senior Security Officer & Windows Specialist, CUIT
Columbia University, 612 W 115th Street, NY, NY 10025 / 212 854 3033
http://www.columbia.edu/~joel - You can't spell seCUrITy without CUIT