Re: Storing encryption strings - best practice?

[David Gillett <gillettdavid () FHDA EDU>]

  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.
 ===========================================================================
=======