* Andrew MacKenzie wrote on Wed, Jan 08, 2003 at 14:15 -0500: > > - Data that must be evaluated in clear text (such as name) > Unfortunately all of the data concerned falls into this group. > We have credit card info (which you mention *may* be treated > like passwords), but we need to validate the account numbers > and perform other processing on them (send to a merchant > processor for billing). Well, but maybe you can store it encrypted in the DBMS with an own public key - and only the order processor has the secret key. Things as name you need in the front end could be encrypted by some different key set (and the front end controlling thing has this secret key). I assume the processing is done on a different, secured system also. This was already meantioned in the thread as "moving the problem to a different server", but in fact, often you cannot do more. I assume you have a secured channel to the processing back end (for instance, the credit card aquirers). So maybe you need some "re-encrypting". Here you could build some box (a secured PC or some dedicated crypto hardware such as security modules) that just offers the complete re-encryption as functionality. So you could decrypt your date securely (since the crypto box knows the key), but without any chance to get out clear text, since it's re-encrypted for the aquirer immediatly. This data is again unreadble and secured - now the problem is moved again to a different server - to some aquirer authorization or processing system, which is out of your scope and responsibility - you're done. This has the big disadvantage that you cannot track what happens. When fraud or such occures, you don't even know what kind of transaction data was used. But you can work-around this a little maybe, when you add some secured transation logging which can be decrypted interactively (when you make it to have a small number of such cases, this could be possible, when someone needs to enter some passphrase daily for decrypting (or again, re-encrypting) and transfer the transaction log to some people (such people ususally have to be trusted anyway). If you need the possibility for each "not-so-secured" system to decrypt the data automatically, I don't think it helps much to store the data encrypted (well, except for billig, encrypted storage is of course an expensive software feature :)). But it would be really strange if this is true - maybe a design problem of the business process :) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
This archive was generated by hypermail 2b30 : Thu Jan 09 2003 - 04:33:50 PST