The only way to do this is by using the original database encryption. Even so, the entire infrastructure is expected to be well protected because if there is an invasion in lower layers it will open doors for security to be circumvented even in this condition. If this is hard enough to do right imagine trying something manual on your own, don’t even try.
If the database does not support anything ready and that is known as something good then it will have to find a solution of its own according to the bank in question and assume the risk. Obviously this involves cryptography as well.
But understand that a lot of the attempts to steal this data won’t even be in the database but the moment you decrypt this information to use it, it’s much easier and it’s where people make the most mistakes.
I mean, if you don’t have security experts you better not do this, it’s too risky.
I would try not to store really sensitive data and especially without the data owner knowing that this is happening. Consult a specialist lawyer to see what he thinks about you holding someone’s data that can be used to create fraud or even violate privacy.
It’s one thing to save data that is actually public (CPF) or data that you have control over, like passwords, it’s another to save complete credit card data.
Depends, will you need to read the data back? For example, with passwords the indicated is to store a hash, which is not reversible, as this is enough to implement a login process. If you need the data back, you’ll need to use something like asymmetric encryption. It all depends on usage. CPF do not even know if it would be worth encrypting...
– bfavaretto