Feature #2214


Secure clear WString content

Added by Boris Nagaev over 10 years ago. Updated over 10 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


Hello! Significant data, like passwords, should be zeroed of filled with random bytes before freeing memory to prevent security leaks in case of bugs (e.g., allocating buffer and using it without zeroing, then send it to user). This can be done with std::string, but there is no way to do this for WString.

I think, WString should get property "secure", which can be set (but not unset!) using method .setSecure(). In destructor of "secure" string, it should be filled with zeros before freeing memory. Secure bit should be inherited when WString is constructed from secure WString or is assigned to secure WString. WLineEdit with EchoMode=Password should produce secure WStrings. Other WFormWidgets should also get property "secure", which can set by user and mean "produces secure value". Wt::Auth should set secure bit on data like passwords and salt.

Wt can not make sure that non-WString data (std::string, std::wstring) derived from WString are zeroed before freeing, so this is up to user called methods .toUTF8(), .value(), etc.


Boris Nagaev

Actions #1

Updated by Koen Deforche over 10 years ago

  • Status changed from New to Feedback


Interesting idea, and it makes sense. I would like to get some independent confirmation that this is indeed a recommended practice in the context of security --- do you have a reference for that?



Actions #2

Updated by Boris Nagaev over 10 years ago


For example, Microsoft provides SecureZeroMemory() function:

This function should be used for this instead of std::fill_n, as call to std::fill_n can be optimized out by compiler.

This stackoverflow answer ( is also interesting for implementation. It states that custom allocator is not sufficient.

The .NET solution to this is SecureString:

Guideline 2-2 of the Secure Coding Guidelines for the Java Programming Language, Version 4.0 (

Guideline 2-2: Do not log highly sensitive information

Some information, such as Social Security numbers (SSNs) and passwords, is highly sensitive. This information should not be kept for longer than necessary nor where it may be seen, even by administrators. For instance, it should not be sent to log files and its presence should not be detectable through searches. Some transient data may be kept in mutable data structures, such as char arrays, and cleared immediately after use. Clearing data structures has reduced effectiveness on typical Java runtime systems as objects are moved in memory transparently to the programmer.

This guideline also has implications for implementation and use of lower-level libraries that do not have semantic knowledge of the data they are dealing with. As an example, a low-level string parsing library may log the text it works on. An application may parse an SSN with the library. This creates a situation where the SSNs are available to administrators with access to the log files.


Boris Nagaev


Also available in: Atom PDF