B4J Question Encryption method to store sensitive information

[prajinpraveen]

Hello all, Happy New year

I am designing an application that has a need to store sensitive information ( CC with CVV ) for recurring payments. ( Yes, I know we should avoid this where possible )

I have looked at various methods of doing this.

1. Encrypt data in B4J and store it in the DB. The downside, the encryption password is stored in the code. Hackers could get hold of this.
2. Encrypt data in B4J and store part data on the database and others in Firebase. again if the code has the password to access firebase, we are exposed.
3. Use the Encryption password as an argument to the app and use it only when required. How will i then encrypt the password to store the information
4. Use MySQL AES_ENCRYPT() and AES_DECRYPT() methods. this has its own disadvantages.
5. Use the Payment gateway provider who will store the information. will work when the business rules are simple. we have complex recurring payment rules.
6. Use Windows DPAPI, Same issue as 1
7. Fetch the encryption password hosted on another server and use it as and when required? Same as 1

May be someone could point me in the right direction

many thanks

 

[Erel]

Use MySQL AES_ENCRYPT() and AES_DECRYPT() methods. this has its own disadvantages.

Where will the password come from?

I'm not an expert in this regards, but as far as I know, there is a complete set of rules that you need to meet in order to legally store credit cards information (google PCI compliance).

Any solution that doesn't require the user to securely sign in, will not be safe.

 

[Andrew (Digitwell)]

PCI compliance is very onerous for a small business to comply with and you should NOT be storing credit card information without being compliant and approved. In a past life I have worked on this sort of thing for UK banks. The introduction of SCA in the EU makes this even more compicated.

NOTE: You should NEVER store CVV at any time.

Who is going to be your payment processor?
RazorPay, STRIPE, PayPal etc all provide mechanism which will handle this for you in a compliant manner, including making repeat payments from stored card details.

A useful read I plucked from GOOGLE.

The Dos and Don'ts of Storing Credit Card Information

Storing credit card information: what you can and can't do.

www.securitymetrics.com

 

[prajinpraveen]

Where will the password come from?

I'm not an expert in this regards, but as far as I know, there is a complete set of rules that you need to meet in order to legally store credit cards information (google PCI compliance).

Any solution that doesn't require the user to securely sign in, will not be safe.

Thanks Erel,

Please see below

SELECT HEX(AES_ENCRYPT('text to encrypt', SHA2('safepassword_or_encryptionkey', 512), RANDOM_BYTES(16))) as encrypted;

The user will use a secure sign in

 

[prajinpraveen]

PCI compliance is very onerous for a small business to comply with and you should NOT be storing credit card information without being compliant and approved. In a past life I have worked on this sort of thing for UK banks. The introduction of SCA in the EU makes this even more compicated.

NOTE: You should NEVER store CVV at any time.

Who is going to be your payment processor?
RazorPay, STRIPE, PayPal etc all provide mechanism which will handle this for you in a compliant manner, including making repeat payments from stored card details.

A useful read I plucked from GOOGLE.

The Dos and Don'ts of Storing Credit Card Information

Storing credit card information: what you can and can't do.

www.securitymetrics.com

Thank you Andrew. I have read/reading a few articles PCI policies and measures to safeguard customer's information.
I am seeking some technical guidance in this regard. I am keen to know from the forum members their experience in dealing with storing sensitive information. Your response is highly appreciated.

 

[Andrew (Digitwell)]

No Problem. Happy to help.

5. Use the Payment gateway provider who will store the information. will work when the business rules are simple. we have complex recurring payment rules.

For complex recurring payments, the business logic can live within your app (server or other system) and the payment can be taken using stored details that the Payment processor holds.