Educause Security Discussion mailing list archives

Storing encryption strings - best practice?


From: "Mercer, Susan" <smercer () AII EDU>
Date: Tue, 7 Mar 2006 09:32:36 -0500

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

Current thread: