OWASP
Update: Secrets Management Cheat Sheet
What is missing or needs to be updated?
The cheat sheet mentions (in 2.5) the .Net SecureString class. However, Microsoft discourages its use - see https://learn.microsoft.com/en-us/dotnet/fundamentals/runtime-libraries/system-security-securestring and https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md.
How should this be resolved?
The "solution" in the second URL mentioned above is: "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." Thus, the best idea would be to inform readers about this. (My additional ideas are, unfortunately, layman's thoughts that are not suitable for a public cheat sheet used by hopefully many software engineers).
H.M.
Did a quick read through the 2 references (once I fixed the bogus http://url/ links). I think this has always been the case as far back as I can remember, but the bottom line is SecureString is a much better choice than 'string' when working with secrets.
On Wed, Jun 18, 2025, 8:58 AM Jim Manico @.***> wrote:
jmanico left a comment (OWASP/CheatSheetSeries#1704) https://github.com/OWASP/CheatSheetSeries/issues/1704#issuecomment-2984103067
This is great - we take PR's! :)
— Reply to this email directly, view it on GitHub https://github.com/OWASP/CheatSheetSeries/issues/1704#issuecomment-2984103067, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAO6PGZYGAE5S5FJE6M5YS33EFO7FAVCNFSM6AAAAAB7SNINN2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOBUGEYDGMBWG4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Also, suggest you ask @sempf to review any PR for this. (Sorry to throw you under the bus like that Bill, but this is right up your alley.)
-- Blog: https://off-the-wall-security.blogspot.com/ | GitHub: @kwwall https://github.com/kwwall| OWASP ESAPI Project https://owasp.org/www-project-enterprise-security-api/co-lead | OWASP and ACM lifetime member NSA: All your crypto bit are belong to us.
On Wed, Jun 18, 2025, 10:01 AM Kevin W. Wall @.***> wrote:
Did a quick read through the 2 references (once I fixed the bogus http://url/ links). I think this has always been the case as far back as I can remember, but the bottom line is SecureString is a much better choice than 'string' when working with secrets.
On Wed, Jun 18, 2025, 8:58 AM Jim Manico @.***> wrote:
jmanico left a comment (OWASP/CheatSheetSeries#1704) https://github.com/OWASP/CheatSheetSeries/issues/1704#issuecomment-2984103067
This is great - we take PR's! :)
— Reply to this email directly, view it on GitHub https://github.com/OWASP/CheatSheetSeries/issues/1704#issuecomment-2984103067, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAO6PGZYGAE5S5FJE6M5YS33EFO7FAVCNFSM6AAAAAB7SNINN2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOBUGEYDGMBWG4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Is the first "you" intended to refer to me? If so, I'll contact @sempf!--Gesendet mit der GMX Mail AppAm 18.06.25, 16:04 schrieb "Kevin W. Wall" @.***>: kwwall left a comment (OWASP/CheatSheetSeries#1704) Also, suggest you ask @sempf to review any PR for this. (Sorry to throw
you under the bus like that Bill, but this is right up your alley.)
-- Blog: https://off-the-wall-security.blogspot.com/ | GitHub: @kwwall https://github.com/kwwall| OWASP ESAPI Project https://owasp.org/www-project-enterprise-security-api/co-lead | OWASP and ACM lifetime member
NSA: All your crypto bit are belong to us.
On Wed, Jun 18, 2025, 10:01 AM Kevin W. Wall @.***> wrote:
Did a quick read through the 2 references (once I fixed the bogus
http://url/ links). I think this has always been the case as far back as
I can remember, but the bottom line is SecureString is a much better choice
than 'string' when working with secrets.
On Wed, Jun 18, 2025, 8:58 AM Jim Manico @.***> wrote:
jmanico left a comment (OWASP/CheatSheetSeries#1704) https://github.com/OWASP/CheatSheetSeries/issues/1704#issuecomment-2984103067
This is great - we take PR's! :)
—
Reply to this email directly, view it on GitHub https://github.com/OWASP/CheatSheetSeries/issues/1704#issuecomment-2984103067, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAO6PGZYGAE5S5FJE6M5YS33EFO7FAVCNFSM6AAAAAB7SNINN2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOBUGEYDGMBWG4 .
You are receiving this because you are subscribed to this thread.Message
ID: @.***>
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
@hmmueller - My first comment was just a general comment, directed at no one in particular. The 2nd comment was directed at @jmanico or @szh or whomever might end up reviewing it. It's been since about 2010 since I've done any .NET/C# coding which is why I suggested Bill. He's written a book or 2 on it.
So hi. I just figured out what the leetle blue dot in the corner of my Github dashboard means, so ... hi! Should I still look at this or is it all done and I missed it?
@sempf - Heh. Most folks also have email notifications enabled for GitHub mentions. 😜
What I wanted you to comment on was the SecureString vs. string comment that @hmmueller started out with and particular the point of Microsoft not recommending SecureString.
Note the actual URL links mentioned at the beginning of this issue do not work, as they both refer to https://github.com/OWASP/CheatSheetSeries/issues/url.
Instead refer to these links:
- https://learn.microsoft.com/en-us/dotnet/fundamentals/runtime-libraries/system-security-securestring
- https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md
I think its a matter of expectations. I'd argue that the best way to represent secures in .NET/C# would be as char or byte array, so you are in complete control and can explicitly overwrite the memory when you are done, but that may not always be an option and I sort of see that as letting the perfect become the enemy of the good. While I can understand that developers may have excessive security expectations of a class named SecureString, and those faulty assumptions may lead to them writing insecure code and leaking secrets, I still think that SecureString is a better option for storing secrets in memory than is using string (well, at least if you remember to invoke the dispose method when your through with the object).
If you (@sempf) have questions, hit me up on Signal.
I didn't even KNOW we had a secrets management cheatsheet, so I guess I'm glad you moved my rock.
Anyway, securestring should not be used anymore. It was fine 20 years ago, when the main threat was someone stealing a hard drive and reading the memory cache or something. With stuff like Rowhammer actually a reality, it's just not really doing anything for the dev.
I vote that we strike the sentence in question. The rest of the paragraph covers the appropriate steps, and honestly I don't even think that guardedstring should be recommended.
Not really sure how relevant Rowhammer is here. If it's part of one's Thread Model, then don't deploy your apps to the cloud (or at least restrict them to the private cloud) or only deploy your apps with sensitive data on places where ECC DRAM is used. That said, I'm fine with removing both SecureString and GuardedString from this. My recommendation would be if you concerned about secrets leaking, don't use them with C# or Java. Instead, make that part of the application a separate service and write that application in C++and use its RAII (Resource Allocation Is Initialization) pattern. Or better, redesign it so that secrets are not used. For instance, some places where secrets are used can be replaced by a Zero Knowledge approach.
So it seems we have a consensus that we can remove the recommendation to use SecureString/GuardedString. @hmmueller do you want to create a PR?
Will do (try) tomorrow!--Gesendet mit der GMX Mail AppAm 16.07.25, 19:46 schrieb Shlomo Zalman Heigh @.***>: szh left a comment (OWASP/CheatSheetSeries#1704) So it seems we have a consensus that we can remove the recommendation to use SecureString/GuardedString. @hmmueller do you want to create a PR?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>