Basic usage of secret manager in VB.net

Question

I have the following two questions:

ONE

A long time ago I used to be able to see constants in the executable by simply opening the binary file it in a text editor. Is this still possible? In other words for application types such as a class library DLL or basic windows form executable is using secret manager necessary to keep parameters from being exposed?

TWO

All tutorials on implementing secrets that I found were very difficult to understand for a beginner, but I so far have

Private Function getTwilioParam(paramName As String) As String
    Dim result As String = "getTwilioParam Failed"
    Dim builder As New ConfigurationBuilder()
    builder.AddUserSecrets(Of TypeOf(Startup.GetTypeInfo().Assembly)) ()  ' I can't tell what to put in for "ProjectType"
    Dim configuration As IConfigurationRoot = builder.Build()

    '' Access secrets
    If paramName = "acctSID" Then result = configuration("Twilio:acctSID")
    If paramName = "authToken" Then result = configuration("Twilio:authToken")

    Return result
End Function

I cannot figure out what the arguments to .AddUserSecrets should be, for a .net class library (dll) or a stand-alone executable.

Any hints will be appreciated.

Answer 1

A long time ago I used to be able to see constants in the executable by simply opening the binary file it in a text editor. Is this still possible?

Yes, though a simple text editor will likely be tripped-up by non-ASCII-compatible encoding schemes - not that you should consider that any kind of protection or obfuscation, because it isn't: tools like IDA Pro, Ghidra, and WinDbg are freely available, extremely powerful, and with many knowledgable users; for this reason not even Microsoft bothers to obfuscate their executables.

In other words for application types such as a class library DLL or basic windows form executable is using secret manager necessary to keep parameters from being exposed?

The hard-and-fast rule is that you must not embed or hard-code any kind of secret, password, key, token, or anything of the kind in your program - even if it is stored in any encrypted form, and no matter how strong you think your obfuscation is.

Instead, your software should prompt the user to input the key/password/secret during its setup or configuration stage, and you should be distributing those secrets in a side-channel (such as an email or online portal) where users can copy-and-paste them from. Your software should then use a system-provided protected-storage system for storing those secrets at-rest (such as Windows DPAPI or .NET's ProtectedData APIs). Doing this means you can also associate secrets with your individual users which might be advantageous for you as it disincentivizes them to leak or release them - and in any event it helps protect those secrets from malicious attackers who might compromise your users' accounts/security/etc;

But keep in mind that provided your users run your software on their machines then you cannot keep secrets from your own users, this is why DRM is always doomed to be cracked eventually.