Re: A secure string library?

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

On 7/9/24 15: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?

Yes. My use case involved a third party library that implemented an RPC
protocol, which was used in some instances to pass sensitive
information. Luckily, that library offered a way to customize the string
type used in the sensitive APIs, which I leveraged to specify my own
string class that performed secure storage cleanup.

This is not a 100% secure solution since there is still a time frame in
the application lifetime when the sensitive data is present in the
process' memory in clear form. However, this is still better than the
default because that time frame is very short compared to the rest of
the run time of the application.

> * Do you think this is something we (as Boost authors) should care
> about, or am I thinking too much?

I think, the most important thing to do in this regard is offer a way
for the user to customize the string/container type so that what I did
is possible.

> * Do you think a library implementing secure string/array/buffer
> classes would be a valuable addition to Boost?

Perhaps. But such a library should have a more layered design, with at
least these layers:

- Raw functions that perform secure memset and destructive memmove and
memcpy. Maybe also str* equivalents.
- Secure allocators that securely clear memory contents on reclamation.
- Secure containers and strings. This may be necessary even with secure
allocators since some containers may not use allocators (e.g.
std::basic_string with SSO or std::array).

But I should note again that such a library would not provide a 100%
protection against the data leaking since there is a time point when the
data is present in memory in clear form. This point should be very
clearly stated in the library docs.