NSString remains in Memory

I have been converting the entered password into NSString.


NSString * tempStr = [[NSString alloc] initWithData: [[DummyEnc sharedInstance] decDummy] encoding: NSUTF8StringEncoding];


NSString is required because tempStr handles other logic.

But there is a problem that tempStr remains in memory, how do I fix it?


Is there a way I would like to use it as an NSString?

Accepted Reply

Try using NSMutableString and setting it to some other value when you are done with it. Perhaps that will overwrite the memory space that was originally used for the pasword.


You can (and should) never use the original password but rather immediately create and store a salted hash with the contents of the .text property of some UITextField. Perhaps that approach is the better one.

Replies

What do you mean by “remains in memory”? That someone is holding a reference to it, and thus the object is never deallocated? Or that once the object is deallocated the bytes representing the string are left in memory? [1] Or something else?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

[1] Folks complain about this from time to time because they have security-critical data in the string.

I have removed variables from memory by assigning nil to tempStr.

But, The value of tempStr is exposed when memory dump is done on the jailbroken iPhone.

It is assumed that a memory problem occurs when converting the NSData returned by the decDummy() method to NSString.

When initializing a variable in NSString,I wonder if tempStr can not be freed due to some characteristics (literal string, nstaggedpointer,?)

Try using NSMutableString and setting it to some other value when you are done with it. Perhaps that will overwrite the memory space that was originally used for the pasword.


You can (and should) never use the original password but rather immediately create and store a salted hash with the contents of the .text property of some UITextField. Perhaps that approach is the better one.

As you say, I think that important data such as passwords should be well managed.

I want to test it right now, but I jailbreaked to test my old, unused phone (4s), but unfortunately the phone became a brick.


The existing code is tempStr = @ "000000" and tempStr = nil.

I wonder how tempStr (NSString) is different if it is an NSMutableString.


I want to know why. Thank you.

tempStr=nil and tempStr=@“something else” will not affect the memory location originally pointed to by the variable tempStr. I am wondering whether [tempStr setString:@“something else”] will leave the pointer tempStr pointing to the same memory location and change the content of that location. I do not know how the mutable property is implemented.

>> but unfortunately the phone became a brick


So it protected the password pretty well without any code, yes? 😉


You can't actually solve your problem deterministically. The password is in (at least) two places: (1) the NSData object returned by [[DummyEnc sharedInstance] decDummy], where it's a UTF-8 string, and (2) the NSString object referred to by tempStr, where it's a UTF-16 code unit array.


Both of these use some kind of underlying storage (in general) for the actual data they contain, and you can't (in general) force that data to be overwritten.


For the NSData object, the best you can hope for is that its underlying buffer is overwritten by something after it's returned to the malloc pool and later reused. (Returning it to the pool will overwrite part of it, probably, but not all.) If it's really a NSMutableData object, you might be able to overwrite the underlying data yourself, before releasing it.


For the NSString object, the situation is similar, in that if it's really a NSMutableString you might be able to cause the underlying data to be overwritten. However, unlike NSData, there's no direct API for this, and you can't be certain that changing the value of a NSMutableString overwrites its internal buffer, instead of freeing it and allocating a new one.


Furthermore, you don't know for certain whether your code is causing any temporary copies of the data to be created. Perhaps not, but it's implementation dependent.


The only absolutely safe way is brick the phone. You seem to have discovered that solution empirically. 🙂

I was not thinking about NSData at all. I will also consider NSData. It is still not testable. Thanks - by brick man

UndoManager of text field saves the text entered for undo purpose.


So incase if textfield is used.To completely remove the strings from the heap memory, along with replacing the text in the text field, undo manager should be disabled or removeAllActions of undoManager(after setting the text) should be executed on the TextField.


[textField.undoManager removeAllActions];