On 2003.09.07, Jerry Asher <[EMAIL PROTECTED]> wrote:
> But the relevant snippet is:
>
> set plainfilename [ns_mktemp /tmp/cc-XXXXXX]
> set plainfd [open $plainfilename w]
> puts -nonewline $plainfd $plaintext
> close $plainfd
>
> set cryptfilename ${plainfilename}.crypt
> exec openssl bf -pass pass:${passphrase} -in $plainfilename
> -out $cryptfilename
> file delete $plainfilename
>
> set cryptfd [open $cryptfilename r]
> fconfigure $cryptfd -translation binary
> set crypt [read $cryptfd]
> close $cryptfd
>
> file delete $cryptfilename
>
>
>
> Question one: What's a good cipher to use? blowfish, des3, ...?
If the information is sensitive (like credit card data), shared secret
encryption is a bad idea. This is, IMHO, the one place that's a sweet
spot for public-key encryption.
In shared-secret encryption, the encryption key is the decryption key,
so in order to encrypt out on your operational system, you need the
password (the decryption key) out in the open for people to steal or
otherwise access. In this case, encryption only protects the data as
it's in-flight, travelling between systems, or is stored in some
persistent store (like a database). This might be "good enough" ...
In public-key encryption, you generate a public and private key-pair on
a "very secure" system - perhaps, one that's not network accessible and
physical security is good, too. Then, you freely put the public key out
in higher-risk environments, like your operational systems -- we don't
care if anyone accesses the public key. We encrypt the data with the
public key, and it can only be decrypted by the (very well protected)
private key. So, theft of the public key just means people can encrypt
data and send it to us -- they can't use it to decrypt data they snag
in-flight or out of our database or wherever.
We can then safely transport this data to the system that finally has
the copy of the private key. If this machine is very secure (a lot more
secure than those front-end operational systems, such as webservers) ...
we're at least in better shape and it's a LOT harder for someone to
decrypt all that sensitive data.
Of course, as long as that data is in unencrypted form at some point
(like, say, in RAM on the operational system before it's public-key
encrypted) ... it's like closing your car windows when it's raining but
leaving the sunroof open. Your car is still going to get wet. ;-)
> Question two:
>
> So this encrypts the database but now I have this $password floating
> around. The password can be set with an environment variable, a string as
> I show here, or a file somewhere in the filesystem. Is there a reasonable
> secure and easy to implement way to manage this password?
Not really. Not if you're being honest about what "security" really
means. Of course, "enough security" is always defined as a very
subjective measure relative to your risk profile. So, in general you
can always make things "secure enough" if your risk profile is "low
enough".
> Question three:
>
> I have gotten this working using the temp file approach, but I would like
> to get rid of the temporary files both for file hygiene and privacy
> concerns.
>
> The problem is that openssl creates binary strings, and I can't figure out
> how to make a binary process pipeline (to use the Welch terminology (p110
> of PPiTaT) out of exec, or out of |open.
>
> Can anyone help? What magical incantation can I use to get rid of the temp
> files?
set fd [open "| yadda yadda" r+]
fconfigure $fd -encoding binary -translation binary
Give that a whack.
> Question four: assuming the password can be managed, and that I can get
> rid of the temp files, what are the security implications of this?
Re-read the answer to Question #1.
-- Dossy
--
Dossy Shiobara mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of
your email blank.
