Question: I am in need to build a secure application for Mac. For that I am using a master password that only exists in the head of the creator. 

To retrieve it the password first needs to be entered in a secure textfield\* it can then be used to encrypt and decrypt files. While the application remains open that master password will be stored in a variable, meaning it exists in memory. Would encrypting this password in memory be overkill? 

The reason why I am asking this question is that before the master password can be encrypted for memory it already exists as a variable, meaning it's already open for memory scanning attacks. Is this something I should be worried about?

I read the following on <https://www.apple.com/macos/security/>:

> 
> **Runtime protections defend at the core.** The technically sophisticated
>  runtime protections in macOS work at the very core of your Mac to help
>  keep your system safe. Built right into the processor, the XD (execute
>  disable) feature creates a strong wall between memory used for data
>  and memory used for executable instructions. This protects against
>  malware that attempts to trick the Mac into treating data the same way
>  it treats a program in order to compromise your system. Address Space
>  Layout Randomization (ASLR) changes the memory locations where
>  different parts of an app are stored. This makes it difficult for an
>  attacker to do harm by finding and reordering parts of an app to make
>  it do something it wasn’t intended to do. macOS brings ASLR to the
>  memory used by the kernel at the heart of the operating system, so the
>  same defenses work at every level in your Mac.
> 
> 
> 

Can I conclude that Mac has already build in protection against memory scanning and hijacking?

(\* I am aware this might cause keylogger vulnerability)

Answer: 
In every case, you would first derrive a key from the user password, and use this key to encrypt the files. So instead of holding the password in memory, you can immediately calculate the key with a key-derivation-function, and hold the key in memory. The advantage you get is, that an attacker can only learn the key, which allows to decrypt the files, but not the original password, which can possibly be reused.

Some OS offer a specialized [SecureString](https://msdn.microsoft.com/en-us/library/system.security.securestring(v=vs.110).aspx), which is probably the nearest you can get to what you want, it holds a string encrypted in memory and can remove it from there. I do not know whether OSX provides anything like this.

I doubt that an encrypted key in memory is of much use. If an attacker is capable of analysing the memory, (s)he will probably be able to decrypt the memory as well, the application must be able to decrypt the key after all. But certainly it raises the bar and needs more work to do.

The linked article addresses another problem in my opinion, it prevents to place executable code in memory (as input data) and trick the processor to execute it afterwards.
The existence of tools such as `mach_inject` and `Cycript` clearly indicate your program's memory is never safe. In iOS world the security of keychain comes from the fact the key is engraved in a separate hardware chip and it's never copied to application memory. If you're doing the encryption/decryption inside your program by definition it's prone to being hijacked in some form. Key things to consider:

* what do you want protect? The data? The encryption method? Both?
* having access to your binary program an attacker is likely to reverse engineer it, what are the implications?
* Do you need the actual encryption/decryption to happen in your program? If at least one crucial step required for the data to be useful would be moved to a external backend it could be way safer
* Supplementing your solution with file system encryption like `FileVault` or `TrueCrypt` will always improve security