On Tue, 9 Jul 2024 at 14:57, Artyom Beilis via Boost
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/3faf2947f9951bb10239cb1c34cae9c571133... 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/3faf2947f9951bb10239cb1c34cae9c571133... 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.