> % Well, if the merchant has his own cipher key, it can all be encrypted
> % with the owner's cipher key. That make sense?
>
> OK, I think so. I like examples, though.
>
> So user Joe goess to https://myserver/script and fills in some values,
> including his ccard no, and they get handed back to my script for it to
> process. The http connection is protected, but I get the data in
> plaintext, so I encrypt it somehow such that I can either decrypt it
> (would I ever need to? ==> I guess it depends on the application) or hand
> the encrypted version right off to the bank as they expect it already.
HTTP connection better be HTTPS, this can be a VERY weak link. If, for
example, I install my server in a co-located facility alongside other
users. Since I had my mind on cost, I choose a cheap facility which used
hubs instead of switches. Now, that means I can SEE traffic for all the
other servers installed onto that hub. If you ain't got that bit right,
you are in trouble.
There may be a way to get data from the web-server into your script
without reverting to "plaintext". Even if there isn't, this data should
be transient [which I'll define as: we aren't going to stick it onto disk
at this point].
If possible, don't hold onto the evidence. Imagine you mug someone, striking
them with a 0.22m banana [for the kids, fruit variety] causing some injury to
the victom. Later, the police raid your house, and you've still got the
weopon in your hand. Oops, busted. Don't keep unless you have to.
Assume the worst, don't trust your webserver to keep information but to
pass onto other systems in a write-only fashion. If your webserver is
comprised you might loose some information, but not your entire customer
credit card list. Apply systems design principles.
> So that takes care of that example, and maybe it was a bad one. I can't
> come up with one that's better, either, but I have in mind something to
> which I must refer more than once (hmmm... perhaps a gpg passphrase as a
> script works with encrypted files or such) and thus must decrypt to use
> (or must I after all?).
For temporaries that need encrypting you'd do this, but you wouldn't write
the "passphrase" to disk. Persistance might be harder to do, and you'll
need to rack your brain to think of secure ways.
Complexity *could* be your downfall, unless you carefully manage the flow
of critical information. Also, most of these systems have to have N + 1
or better [N+1 means as much as you need, and one more in case something
breaks].
I think we are off-topic, this was a '[EMAIL PROTECTED]' mailinglist.
Jonathan Paton
=====
$_=q|.,&@$$. ,.@$&@$. .&$$@. ,,$ ....!$_=$p.'&$@.',y'&$@' .,';for(/\S+/g){
!|.q| .$ .,@, ,$, .,.. @, ,$ ,,@ .,,.!++$.<22?${'y'.$_}=chr$.+64:[$$=${'y'
!|.q| ,@$@&.,. $$$&, ..@&&$,,, $., ..!.$_},$y.=($.=~/22\|26\|3(3\|7)/x?' '
!|.q|. @ ., ,.&,,, , .$..&. .,$ .,,!.$$:"\l$$")]};$y=~/ (.*)/;warn"$1\n"
!|.q|. $ .,. .,$$&&$...&., @.,.&@$@ .|,map{-$|--?$r:$p.=$_}split'!';eval$r
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
