Feature #2214
openSecure clear WString content
0%
Description
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.
Regards,
Boris Nagaev
Updated by Koen Deforche about 11 years ago
- Status changed from New to Feedback
Hey,
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?
Regards,
koen
Updated by Boris Nagaev about 11 years ago
Hello!
For example, Microsoft provides SecureZeroMemory() function:
http://msdn.microsoft.com/en-us/library/aa366877%28VS.85%29.aspx
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 (http://stackoverflow.com/a/5735744) is also interesting for implementation. It states that custom allocator is not sufficient.
The .NET solution to this is SecureString:
http://msdn.microsoft.com/en-us/library/system.security.securestring.aspx
Guideline 2-2 of the Secure Coding Guidelines for the Java Programming Language, Version 4.0 (http://www.oracle.com/technetwork/java/seccodeguide-139067.html#2):
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.
Regards,
Boris Nagaev