Currently when SQLITE_HAS_CODEC is enabled, the database key can only be passed to key() or rekey() via const std::string&. This is a problem: between small string optimization, implicit copying, and allocation it is very difficult for an application to securely erase this key data when it has to go into an std::string. A pretty decent rule is that sensitive data like database keys should never see the inside of a std::string to avoid leaving potential shadow copies of the sensitive value around.
An API that allows more security (if the using code wants it) would be to take this key as a string_view (for C++17), or a pointer+size pair for pre-C++17, so that an application can worry about how secure it wants to be about ensuring where the DB key might be lying around. If std::string is good enough for the user then that still works fine with a string_view, and if it isn't, they can avoid touching std::string with sensitive data.
But as it is, the existing key/rekey APIs are of questionable utility with an encrypted database because of this issue.
Fixed by #518
Currently when SQLITE_HAS_CODEC is enabled, the database key can only be passed to
key()orrekey()viaconst std::string&. This is a problem: between small string optimization, implicit copying, and allocation it is very difficult for an application to securely erase this key data when it has to go into an std::string. A pretty decent rule is that sensitive data like database keys should never see the inside of astd::stringto avoid leaving potential shadow copies of the sensitive value around.An API that allows more security (if the using code wants it) would be to take this key as a string_view (for C++17), or a pointer+size pair for pre-C++17, so that an application can worry about how secure it wants to be about ensuring where the DB key might be lying around. If std::string is good enough for the user then that still works fine with a string_view, and if it isn't, they can avoid touching std::string with sensitive data.
But as it is, the existing key/rekey APIs are of questionable utility with an encrypted database because of this issue.
Fixed by #518