Jonathan, et al -- ...and then Jonathan E. Paton said... % % > So user Joe goess to https://myserver/script and fills in some values, ... % % HTTP connection better be HTTPS, this can be a VERY weak link. If, for
Well, yeah. I figured we could simplify things by establishing the precondition that the data gets to the script safely. % 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. That's a given (as you note below, this is only ;-) a perl list and hasn't really anything to do with web servers or even the semantics of safe data transfer). % % 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]. A good definition. % % 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. Yeah. The idea of tossing away data before finishing execution is new to me, but I like it. I imagine that many tasks could be structured to use the sensitive stuff and then be done with it. Interesting... % % 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. Yeah. % ... % > 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. One last question... So I have this passphrase, and I keep it in memory because we all know that writing to disk is bad (hey, I was the first to post the idea of skipping the temp file; I'm pretty happy about that :-) Given that the passphrase will have to be available in plain text form at various times through the run of the script and that we don't want to keep bugging the user (not a bad idea in such a case, but not for this example), I think I've realized that it's no different to keep the passphrase in plain form than it is to keep it encrypted in memory *and* have the ability to decrypt it running along in the script. If that realization is accurate, things get a lot clearer and holding on to an encrypted copy becomes a different matter entirely (namely that the script CANNOT decrypt what it's been given and encrypted, and that that's OK). % % 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. Perhaps so. But even beginners need to think ahead to robust, safe code ;-) % % Jonathan Paton Thanks again & HAND :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.justpickone.org/davidtg/ Shpx gur Pbzzhavpngvbaf Qrprapl Npg!
msg24958/pgp00000.pgp
Description: PGP signature
