On 05/28, David T-G said something like:
> % sort of secure form in memory (encrypted or something).
>
> Now that's an interesting one... Suppose someone feeds this script a
> password or a credit card number or such (that is, something manageable,
> even if only for me since perl could suck the OED into $oed and not
> care :-) and you want to work with it. When you get it you have to
> process it somehow. When you get the data, it will probably be in
> plaintext (a form field over an https connection, say) and you get to
> encrypt it from there. That I can follow, but:
>
> 1) Can the suggested "secure form in memory" help you at that early stage,
> when it arrives in plaintext?
>
> 2) How do you then work with it when it's sitting encrypted in memory (in
> order to, say, hand it off to your merchant account processor for billing)
> without thereby having it in plaintext (either in memory or somewhere else)?
Well, if the merchant has his own cipher key, it can all be encrypted
with the owner's cipher key. That make sense?
This protects the data from customer to customer, and there is no need
at all for plaintext if wherever the data goes understands ciphers.
--
Shawn Leas
[EMAIL PROTECTED]
I had a friend who was a clown... when he died, all his friends went to the
funeral in one car...
-- Stephen Wright
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
