Re: Re: Re: Re: 'Restricted' data, an additional security mechanism for Perl.

Encryption can form part of a secure system, but regardless of how good your encryption is you still need to manage your data safely, and if you don't manage your data safely your encryption becomes irrelevant. Consider that you need to decrypt your data if you are to use it. You now have plain text, in a variable, in memory, which you are going to pass around a few method/function calls. Plus you have your key, as plain text, in a variable, in memory. You're probably going to pass the data to some code that you didn't write. At this point, you wish that you could somehow set a flag on your data to prevent it being written to a file, for instance - even if you audit all the code, including all its dependencies, are you sufficiently sure you didn't miss anything? Security audits are Hard.

Three years ago there was a tax evasion case in Denmark where the police "broke" the encryption on some files on computers they'd seized. Turns out that they didn't break the encryption at all, they retrieved the data and keys from plain text left on the disks.

Comment on Re: Re: Re: Re: 'Restricted' data, an additional security mechanism for Perl.

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: 'Restricted' data, an additional security mechanism for Perl. by zentara (Cardinal) on Feb 10, 2004 at 16:23 UTC
I agree with what you say, but you may have missed the point I made in my original reply. My point was: If ssl is being used to transfer the data over the net securely, why not take it one step further, and use the same techique to encrypt the form data, with another separate public key, which can only be decoded by the receiver with his private key. Now you have a situation where if the "store" is on a shared server, the decoded param data is still encrypted with the store owner's public key. Now, if the store owner can trust the physical and administrative security of the shared server, he can decode his param data and do what he wants. But if the store wants to be secure, the actual cc verification and data storage would be done on another machine. The encrypted cc data would never be decrypted completely on the shared server. Now this would allow for you to "farm out" the verification to a third party (who would have possesion of your store's private key, and be held legally liable for it's security), or you could do it on a "secure compter" at your place of business, if you knew how to setup the network. So all that would be passed around on the network, would be pgp encrypted data, or "transaction number approved" or "transaction number disapproved". The only thing preventing this type of security is that the main browsers (IE and Mozilla) don't support pgp encrption of form data. It has ssl, but not encryption of the form data itself. It would not be hard to implement at all.	[reply]

Replies are listed 'Best First'.

Re: Re: Re: Re: Re: 'Restricted' data, an additional security mechanism for Perl.
by zentara (Cardinal) on Feb 10, 2004 at 16:23 UTC

If ssl is being used to transfer the data over the net securely, why not take it one step further, and use the same techique to encrypt the form data, with another separate public key, which can only be decoded by the receiver with his private key.

Now you have a situation where if the "store" is on a shared server, the decoded param data is still encrypted with the store owner's public key. Now, if the store owner can trust the physical and administrative security of the shared server, he can decode his param data and do what he wants.

But if the store wants to be secure, the actual cc verification and data storage would be done on another machine. The encrypted cc data would never be decrypted completely on the shared server. Now this would allow for you to "farm out" the verification to a third party (who would have possesion of your store's private key, and be held legally liable for it's security), or you could do it on a "secure compter" at your place of business, if you knew how to setup the network.

So all that would be passed around on the network, would be pgp encrypted data, or "transaction number approved" or "transaction number disapproved".

The only thing preventing this type of security is that the main browsers (IE and Mozilla) don't support pgp encrption of form data. It has ssl, but not encryption of the form data itself. It would not be hard to implement at all.

[reply]