Re: A secure string library?

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-07-09 14:37:20

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.