Overwrite then set to null

Question

I am working on a legacy ecommerce platform and have noticed a convention when dealing with credit card numbers. C#

cardnumber = "11111111111111111111";
cardnumber = null;

or in sql

update cards set cardnumber = '11111111111111111111' where customerid = @CustomerID
update cards set cardnumber = null where customerid = @CustomerID

I presume the reasoning is to remove it from memory before setting it to null which may not remove the value. But that reasoning would seem to suggest that SQL Server and/or the .NET VM had vulnerabilities in where just setting it to null would not remove the data completely just say that it is available.

1. Is my understanding of it correct?
2. Does it still need to be performed today?

Alliterative

FYI the SecureString class exists now. Might be of interest. – Lilongwe

There is a trigger on that table? – Negligible

@Negligible no trigger on the table. – Alliterative

@Alliterative That's voodoo programming, for sure. The bytes will still remain in memory somewhere until they get overwritten (presumably only when GC runs and that memory block is reused rather than just being placed on the free memory list). The SecureString that George mentioned is of course the correct solution (in .Net at least). – Hypoxanthine

I was under the impression, that simply overwriting data with 0 or 1 did not imply, that the data would become unrecoverable, and that some paranoid people would prefer deleting their data by overwriting it with random sequences multiple times. Maybe that's what it was all about? – Claus

As an alternative You could use a byte[] which is mutable, pin it via gchandle then .clear when your done – Fetter

Answer 1

I don't know for SQL, but in C#, it doesn't make sense. Since the string is immutable, you cannot override the data, even if you try as hard as you can.

When you write

cardnumber = "11111111111111111111";

This just creates another string in memory, but the old card number is still here, somewhere in the memory.

And when you write

cardnumber = null;

It dereference the previously created string, and now you have a reference cardnumber pointing on nothing. But your string containing real card number is still here.
So this code is not only wrong, it is dangerous because it gives you a false sense of security.

Take a look at what the MSDN said on the SecureString page shared by George Duckett in the comments:

An instance of the System.String class is both immutable and, when no longer needed, cannot be programmatically scheduled for garbage collection; that is, the instance is read-only after it is created and it is not possible to predict when the instance will be deleted from computer memory. Consequently, if a String object contains sensitive information such as a password, credit card number, or personal data, there is a risk the information could be revealed after it is used because your application cannot delete the data from computer memory.

Further readings:

• Payment Processors - What do I need to know if I want to accept credit cards on my website?

Alum