Re: Storing encryption strings - best practice?

[Graham Toal <gtoal () UTPA EDU>]

> 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?

Conceptually there is no good solution to this problem, the
best you can do is a good engineering solution (or avoid the
problem by handling it another way such as with a public/private
key pair, which would be preferred)

Let me recap what you said, just to be sure we're on the same
page.

1) SSN is encrypted with a reversible encryption.  The 'seed'
is effectively the password for the reversible encryption.

2) Passwords are one-way hashed with a fixed hashing algorithm,
but are concatenated with a hidden seed string so that if the
hashed passwords are divulged, an attacker will also need to know
the seed before they can do a dictionary attack on the passwords.
A suitably long seed should therefore preclude a dictionary attack,
as long as the seed remains secure.

Here's the problem: if they can get access to your encrypted passwords,
do they automatically get access to the seed too?  I.e. is it on the
same machine?

The best solution I've found to this is that the encryption is done
on another system from where the data is stored.  And that system should
be sufficiently different such that an exploit which lets them into
one does not let them into the other.  That means different O/S,
different web server (assuming it is web based), and most importantly
different system passwords!

Actually the architecture I would use would be for the system with the
database to fire off requests to hash/encrypt to a second system over
command-line ssh.  The encrypting machine would *only* have ssh open,
and the ssh shell would be restricted to executing only the encryption
command. (Even better would be a custom daemon if you're up to writing
one, then the risk of breaking out of ssh goes away too, but make
sure that the TCP session to the daemon is ssl protected otherwise
your cleartext passwords will all be easily compromised on the wire)

Same architecture would apply for decrypting the SSNs, if you really
must go that way.

Here's an interesting way to look at the SSN problem: how quickly do you
need a result?  How many lookups do you do per second?  If the answer is
that this is always from a manual process, you don't mind waiting a few
seconds, and it is not happening very often, then consider this approach:

Would it work for you to encrypt the SSNs with a one-way hash, (with or
without a 'private' seed), and 'decrypt' it by looping over the space of
all SSNs trying each one of them until you get a hash match.  Let's say
that one SSN can be recovered in about a minute; is that too long to wait?
(You can tweak a concatenated random seed to make the recovery time as
long as you want)

If that would work, it buys you some time when your SSN database is exposed,
because even if the attacker has your algorithm, they're going to take
several weeks to decrypt your entire database.  If you've used a private
seed as well *and you know it was not also exposed*, weeks becomes months
or years.

my $0.02.  Take it with a pinch of salt, not everyone is likely to agree
with this :-)  Really using a public key architecture would be much
preferred, I'm just trying to think of something to help you if you're
absolutely forced to go with the architecture you described.

Anyway, the direct answer to your question is that your three solutions
are all bad, because if the machine with the database is compromised, so
is your secret key.


Graham