Reliable zero memory in NSString

In iOS, I was curious, say, if I read the user-entered password value as such:

NSString* strPwd = UITextField.text; //Check 'strPwd' ... //How to clear out 'strPwd' from RAM? 

I just don't like leaving confidential data โ€œhanging outโ€ in RAM. Any idea how to reset it?

+8
memory-management security objective-c cocoa-touch cocoa
source share
2 answers

Basically, you really can't. Errors filed with Apple on this exact issue. In addition, there are problems with UITextField and NSString at least.

Repeat comment in @Leo Natan's deleted answer:

Releasing the NSString closing object does not guarantee a string of bytes โ€” these are zeros in memory. In addition, if the device is locked, the entire Apple promises sandbox will be useless. However, in this case, little can be done, since you can change the entire execution time in the middle of the running application, this is getting the password from memory.

Please write another mistake with an apple requesting this, all the better.

Apple bug reporter

+9
source share

Although NSString does not have this capability (for the encapsulation reasons mentioned elsewhere), it should not be too difficult to get your application to use the usual old C-strings, which are just pointers to memory. When you have this pointer, it's pretty easy to clarify when you are done.

This will not help with user-entered text fields (which use NSString -s, and we cannot change them), but you certainly can store all sensitive data of your application in memory based on pointers.

I have not experimented with it (I do not have a current jailbreak device), but it may also be interesting to experiment with NSMutableString - something like:

 // Code typed in browser; may need adjusting // keep "password" in an NSMutableString NSInteger passLength = password.length; NSString *dummy = @"-"; while (dummy.length < passLength) { dummy = [dummy stringByAppendingString: @"-"]; } NSRange fullPass = NSMakeRange(0, passLength); [password replaceOccurancesOfString: password withString: dummy options: 0 range: fullPass]; 

NOTE. I have no idea if this does what you want; this is what i was thinking when typing my earlier answer. Even if it works now, I think it depends on the implementation, which is fragile (which means: may be broken in the future), so it should not be used.

However, it can be an interesting exercise! :)

0
source share

All Articles