On 7/9/24 17:29, Rainer Deyke via Boost wrote:
On 09.07.24 14:28, Ruben Perez via Boost wrote:
Hi all,
Boost.MySQL and Boost.Redis need to hold sensitive information, like passwords, to work. Using std::string may be sufficient for many use cases, but it's not the best security practice. std::string doesn't wipe its memory on cleanup, resulting in the password remaining in memory for an indeterminate amount of time.
Other languages like C# implement a SecureString class that wipes memory on destruction. Crypto++ implements a similar concept, but it's a big dependency I'm not willing to take.
I'd like to know whether everyone else's opinion on this:
* Have you faced this issue before? * Do you think this is something we (as Boost authors) should care about, or am I thinking too much? * Do you think a library implementing secure string/array/buffer classes would be a valuable addition to Boost?
I'm not an expert, but this sounds like security theater to me. Clearing passwords from memory wouldn't hurt, but what actual concrete attacks would it actually prevent?
If a hostile process can read your memory while your process is running, then it can also do so while the password is still in memory.
If a hostile process can read your memory after your process has terminated, then you have an OS-level vulnerability. (Consider that your process can crash before it has erased the password from memory.)
Passwords travel along a long chain from user input to system calls. The entire chain needs to be secure or none of it is.
Why does it have to be an "all or none" choice? Security is always about making life *hard enough* for the attacker so that the attack is not worthwhile. It is never about making the protection impenetrable, as there is simply no such thing.
There are applications where security is so important that the extra step of erasing all passwords from memory is worthwhile despite its limitations. Such an application will already use a crypto library that provides secure strings, if not Crypto++ then another.
Unless you're using some sort of hardware memory encryption, like Intel SGX, there will inevitably be an instant where the data will be in clear form. Otherwise you wouldn't be able to use it.