0

I am implementing a Credit Card processing in mobile apps for iOS (Swift) and Android (Kotlin) using native SDK (SAQ A EP compliance level)

We thought about:

  • disabling clipboard for CC field
  • disabling tracking for add CC screens
  • dereferencing object as soon as screens are closed

For iOS, we verified that as long as the class is dereferenced the memory allocated with CC info was not visible there anymore (new Object took it over)

For Android, we would not use immutable types i.e String to store CC, rather than char primitive array, but not sure how this apply to Kotlin, is this the same?

We would like to keep the CC data as short as possible in memory and drop it (make sure it is gone) as soon as we don't need it.

Anyway, any tips how to handle this securely/best practices for both platforms (iOS, Android) would be great.

As a bonus, attack scenarios, by not implementing those protection would be good, i.e loading Kernel Module to dump RAM on Android or process memory (if this is even possible), dumping RAM via ADB, gdb etc. On iOS I cannot think of any, except dumping physically RAM by opening the phone.

Thanks,

Update 1:

I will try to get response from vendors why they use Objects instead of primitives and maybe zeroing them after use.

Few random vendors:

Braintree

https://github.com/braintree/braintree_android/blob/cb401acd503c8cf818e3fed5f2dcf9ab252ebaa8/Braintree/src/main/java/com/braintreepayments/api/models/CardBuilder.java

PayU and they also use objects - Hashmap.

Another one mpay24 Integer class

https://github.com/mpay24/mpay24-java/blob/master/src/main/java/com/mpay24/payment/data/PaymentType.java

Maybe there is no way to get away without object in this OOP environment at the end, so makes no sense to use primitives along the way? Or they do it all wrong. Would also need to debug it/research it more.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.