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.