Re: A secure string library?

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2024-07-10 10:13:15

On Tue, 9 Jul 2024 at 14:57, Artyom Beilis via Boost
<boost_at_[hidden]> wrote:
>
> While this can be a useful class, it is useful mostly in the context of
> cryptography.
> So I rarely can see a case when you use it independently of a crypto
> library.
>
> Additionally passwords are almost never stored as clear text so the only
> location I can see password is handled is in the forms you receive and
> usually the UI toolkits themselves handle it as string - so you don't solve
> it
> there unless you rewrite the 3rd party toolkits to use "safe" string.

Oh, you're referring to actual user passwords being stored in MySQL.
We're speaking about different things. Sure, this kind of passwords
must be first hashed, e.g. by using scrypt or argon2.

I'm talking about the credentials require to actually log into the
MySQL or Redis database server - this line, concretely:
https://github.com/boostorg/mysql/blob/3faf2947f9951bb10239cb1c34cae9c571133d3e/include/boost/mysql/connect_params.hpp#L47

Best practices say that password should be erased once the
connect_params object gets destroyed.

While I think that's useful, there's also a similar problem when doing
connection pooling - except that these credentials are usually
required for the lifetime of the application, so the security gain
would be much lower. See
https://github.com/boostorg/mysql/blob/3faf2947f9951bb10239cb1c34cae9c571133d3e/include/boost/mysql/pool_params.hpp#L93

My use case for this secure_string class would be these two places.

It's true that Boost.MySQL does require OpenSSL, indeed, so I could
just use OPENSSL_Cleanse and code a Boost.MySQL specific secure_string
class. But better hear people's opinion first, as it's a non-trivial
task.

Regards,
Ruben.