You are mixing separate things here, namely encryption software and password managers. For both tho, there is no way around storing the key in memory and the problems can be reduced to one:

• If you want to store passwords like in KeePassX, you have to unlock the password database once and keep it open (so you can autotype them via hotkeys).
• If you encrypt files, you have to enter your master password once and keep the files open.

In either case the password will be in memory for a finite time and you need to overwrite it after using it in order to make sure it doesn't stay there. If you simply reallocate the memory, it's not guaranteed to be overwritten ever.

memset can set a memory block to whatever you want it to be, so it could help us here. Problem: If you use compiler optimizations, the compiler might think memset is useless and remove it for more efficiency.

This is why for example VeraCrypt includes special functions like RtlSecureZeroMemory and its wrapper method burn to ensure memory will be reset, like this:

BootArgs = *bootArguments; BootArgsValid = TRUE; burn (bootArguments, sizeof (*bootArguments)); 

Of course this doesn't make deletion 100% guaranteed, because now you have to ensure that there is no possible execution path that forgets to call this function.

In the latest audit of VeraCrypt it was revealed that there is one occasion where burn is called after a code segment where a TC_THROW_FATAL_EXCEPTION can be thrown, thus leading to sensitive data remaining in memory.

You are mixing separate things here, namely encryption software and password managers. For both tho, there is no way around storing the key in memory and the problems can be reduced to one:

• If you want to store passwords like in KeePassX, you have to unlock the password database once and keep it open (so you can autotype them via hotkeys).
• If you encrypt files, you have to enter your master password once and keep the files open.

In either case the password will be in memory for a finite time and you need to overwrite it after using it in order to make sure it doesn't stay there. If you simply reallocate the memory, it's not guaranteed to be overwritten ever.

memset can set a memory block to whatever you want it to be, so it could help us here. Problem: If you use compiler optimizations, the compiler might think memset is useless and remove it for more efficiency.

This is why for example VeraCrypt includes special functions like RtlSecureZeroMemory and its wrapper method burn to ensure memory will be reset, like this:

BootArgs = *bootArguments; BootArgsValid = TRUE; burn (bootArguments, sizeof (*bootArguments)); 

Of course this doesn't make deletion 100% guaranteed, because now you have to ensure that there is no possible execution path that forgets to call this function.

In the latest audit of VeraCrypt it was revealed that there is one occasion where burn is called after a code segment where a TC_THROW_FATAL_EXCEPTION can be thrown, thus leading to sensitive data remaining in memory.

This is generally one of the problems in designing safe and secure programs, if you implement methods to prevent memory leaks you have to ensure there is no way to prevent them from getting called.

You are mixing separate things here, namely encryption software and password managers. For both tho, there is no way around storing the key in memory and the problems can be reduced to one:

• If you want to store passwords like in KeePassX, you have to unlock the password database once and keep it open (so you can autotype them via hotkeys).
• If you encrypt files, you have to enter your master password once and keep the files open.

In either case the password will be in memory for a finite time and you need to overwrite it after using it in order to make sure it doesn't stay there. If you simply reallocate the memory, it's not guaranteed to be overwritten ever.

memset can set a memory block to whatever you want it to be, so it could help us here. Problem: If you use compiler optimizations, the compiler might think memset is useless and remove it for more efficiency.

This is why for examply VeraCrypt includes special functions like RtlSecureZeroMemory and its wrapper method burn to ensure memory will be reset, like this:

BootArgs = *bootArguments; BootArgsValid = TRUE; burn (bootArguments, sizeof (*bootArguments)); 

Of course this doesn't make deletion 100% guaranteed, because now you have to ensure that there is no possible execution path that forgets to call this function.

In the latest audit of VeraCrypt it was revealed that there is one occasion where burn is called after a code segment where a TC_THROW_FATAL_EXCEPTION can be thrown, thus leading to sensitive data remaining in memory.

You are mixing separate things here, namely encryption software and password managers. For both tho, there is no way around storing the key in memory and the problems can be reduced to one:

• If you want to store passwords like in KeePassX, you have to unlock the password database once and keep it open (so you can autotype them via hotkeys).
• If you encrypt files, you have to enter your master password once and keep the files open.

In either case the password will be in memory for a finite time and you need to overwrite it after using it in order to make sure it doesn't stay there. If you simply reallocate the memory, it's not guaranteed to be overwritten ever.

memset can set a memory block to whatever you want it to be, so it could help us here. Problem: If you use compiler optimizations, the compiler might think memset is useless and remove it for more efficiency.

This is why for example VeraCrypt includes special functions like RtlSecureZeroMemory and its wrapper method burn to ensure memory will be reset, like this:

BootArgs = *bootArguments; BootArgsValid = TRUE; burn (bootArguments, sizeof (*bootArguments)); 

Of course this doesn't make deletion 100% guaranteed, because now you have to ensure that there is no possible execution path that forgets to call this function.

In the latest audit of VeraCrypt it was revealed that there is one occasion where burn is called after a code segment where a TC_THROW_FATAL_EXCEPTION can be thrown, thus leading to sensitive data remaining in memory.