Project

General

Profile

Feature #2214

Secure clear WString content

Added by Boris Nagaev almost 9 years ago. Updated almost 9 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
09/15/2013
Due date:
% Done:

0%

Estimated time:

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

#1

Updated by Koen Deforche almost 9 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

#2

Updated by Boris Nagaev almost 9 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

Also available in: Atom PDF