• Hi @JSerpas649073 (Community Member)​ ,

     

    Veracode Static Analysis reports a flaw of the category CWE-316: Cleartext Storage of Sensitive Information in Memory if it can detect a password being kept in memory in string form for an extended period of time in the form of a string.

     

    The risk associated with this flaw is that an attacker gains access to the memory of your application or a dump of it's memory. To read more on how difficult it may be to secure memory I recommend this thread on Stack Exchange: https://security.stackexchange.com/a/29023/3206 ).

     

    To remediate this flaw you can try to following strategies (in order of preference):

    1. Do not keep the password in memory, read it from the secure storage, use it and immediately unset it.
    2. Use OS level security mechanisms like DPAPI on Windows or Keychain on OS X.
    3. Use a more secure alternative for storage of sensitive data in memory like char[] in Java ( https://stackoverflow.com/a/8881376/4512 ) or SecureString ( https://docs.microsoft.com/en-us/dotnet/api/system.security.securestring?view=netframework-4.8 ) in C#.
    4. If making these changes is difficult (vendor or legacy software) and you have full control of the runtime (server runtime) you may contact your security team to investigate if a different policy is available for your application that does not require you to remediate this flaw category.

     

    Please let me know if you have any remaining questions or concerns.

     

    Thank you,

    Boy Baukema

    Expand Post
    Selected as Best
  • Hi @JSerpas649073 (Community Member)​ ,

     

    Veracode Static Analysis reports a flaw of the category CWE-316: Cleartext Storage of Sensitive Information in Memory if it can detect a password being kept in memory in string form for an extended period of time in the form of a string.

     

    The risk associated with this flaw is that an attacker gains access to the memory of your application or a dump of it's memory. To read more on how difficult it may be to secure memory I recommend this thread on Stack Exchange: https://security.stackexchange.com/a/29023/3206 ).

     

    To remediate this flaw you can try to following strategies (in order of preference):

    1. Do not keep the password in memory, read it from the secure storage, use it and immediately unset it.
    2. Use OS level security mechanisms like DPAPI on Windows or Keychain on OS X.
    3. Use a more secure alternative for storage of sensitive data in memory like char[] in Java ( https://stackoverflow.com/a/8881376/4512 ) or SecureString ( https://docs.microsoft.com/en-us/dotnet/api/system.security.securestring?view=netframework-4.8 ) in C#.
    4. If making these changes is difficult (vendor or legacy software) and you have full control of the runtime (server runtime) you may contact your security team to investigate if a different policy is available for your application that does not require you to remediate this flaw category.

     

    Please let me know if you have any remaining questions or concerns.

     

    Thank you,

    Boy Baukema

    Expand Post
    Selected as Best
    • JGauthier982875 (Community Member)

      Hi, fyi in SecureString documentation it is stated:

      " Important

      We don't recommend that you use the SecureString class for new development.

      For more information, see SecureString shouldn't be used on GitHub."

       

      From GitHub ("DE0001: SecureString shouldn't be used"), it is stated:

      "Don't use SecureString for new code. When porting code to .NET Core, consider that the contents of the array are not encrypted in memory.

      The general approach of dealing with credentials is to avoid them and instead rely on other means to authenticate, such as certificates or Windows authentication."

      Expand Post
      • Hi @JGauthier982875 (Community Member)​ ,

         

        Thank you for mentioning that, Veracode Research has examined this and provides the following response:

         

        Keep in mind that SecureString will just make it more difficult for an attacker to extract passwords from a running process, it won't be impossible. And one downside when running the .NET Core app on *NIX is that it won't be encrypted when it's not being used.

         

        Even when running SecureString on a platform that does do the encryption when it's not used I would advice the customer to figure out if the password really needs to be available in that point in the application. Best remediation would be not to have it stored in memory at all! Maybe it's possible to stay away from storing passwords/keys at all and leverage e.g. operating system features for that. I can imagine that it will probably involve some application-architectual changes.

         

        Second thing I would do is limit the lifetime of that SecureString and make sure it's available for a limited time window. Because it implements IDisposable it's possible to use a using compound and reduce the time it's really available in memory. 

         

        Even without the encryption done if the app is run on NIX (1 out of the 3 platforms) *SecureString remains the best available remediation for the developer. I'm not aware of any alternative and I would also not advice our customers to perform their own encryption on that.

         

        Thank you,

        Boy Baukema

        Expand Post
      • JGauthier982875 (Community Member)

        Thanks Boy, so introducing the use of SecureString will prevent Veracode Static Scan to consider it as a medium issue anymore? 🙂

        Thanks,

        Jerome

      • Hi @JGauthier982875 (Community Member)​ ,

         

        Correct, though as mentioned before, generally w recommend first investigating:

         

        1. Not keeping the password in memory, read it from the secure storage, use it and immediately unsetting it.
        2. Using an OS level security mechanisms like DPAPI on Windows or Keychain on OS X.

         

        Thank you,

        Boy Baukema

        Expand Post

Topics (4)

No articles found
Loading

Ask the Community

Get answers, share a use case, discuss your favorite features, or get input from the community.