1

In Requirement 3.2 of PCIDSS is the first sentence: "Do not store sensitive authentication data after authorization". Should I this apply also to the operation memory(RAM)? Because my security officer understands it this way, so he prohibits us from using java.lang.String in Java language. His point of view is, that because JAVA String is immutable, so it's impossible to delete it immediately after authorization and is necessary to wait to a garbage collector to remove it from RAM. The garbage collector isn't under our control, so we can't force to remove sensitive data from RAM immediately after the authorization. Because of this, we aren't compliant with Requirement 3.2. My point is, that Requirement 3.2, isn't about the RAM, but about the persistent storage (filesystem, DB and so on). This is not only about replacing some central representation of PAN from String to Char array, but it'll also blocking us from use lots of standard JAVA libs for IO. For example REST controllers in case of payment gateway. Now we are at a stage of designing the new application, so decide this will really help us. Is there any official explanation from trusted source?

Tomas Jacko
  • 345
  • 3
  • 11
  • 1
    if someone can tamper with your RAM memory to find a Java String, you have indeed worse security problems, however you may use a simple char array to store the PAN and manually blank it after usage, Be sure every time you convert it to String (for whavever scope you have), to mask it (like 5255***********2) or to get just last few bytes. I don't get the REST part thou, if you receive the call, it's up to the Merchant to have a SAQ-D (he acquires the sensitive data), any REST call is considered S2S. – BigMike May 26 '17 at 13:30
  • The requirement can be extrapolated to 'not use RAM at all'. However, you can use `char[]` and immediately null out its elements after use, since arrays are mutable. – Miha_x64 May 26 '17 at 13:36
  • See [here](https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Should-cardholder-data-be-encrypted-while-in-memory) - for a rebuff of your security officer. It all depends on the interpretation of *at rest*. – OldCurmudgeon May 26 '17 at 13:40
  • By the REST example, I think, that all input already come in String, so the conversion to the char[] already lost the point, because there already are sensitive data in memory waiting for the GC. And I know, I could handle this with processing byte stream and convert them to the char[], but this seems to me as inventing the wheel. – Tomas Jacko May 26 '17 at 13:52

1 Answers1

0

Immutable objects stay in memory the same way normal objects are. The efficiency it brings to table is if two variables are assigned same value it won’t create a new copy but assign reference of same object in memory to both. A normal mutable object also stays in memory after it is de referenced until GC picks it up for cleanup. If you use languages like Scala and few others that by default use immutable objects then I understand from your CISO argument your software is never compliant

Sriram
  • 1
  • 1