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?

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?