Consider adding SecureString support for basic auth credentials

[gmarz]

Should/do we want to add support for passing basic auth credentials using SecureString?

This has come up in the past and now recently in https://discuss.elastic.co/t/nest-client-with-basicauthentication-and-securestring/69565

It seems like it's feasible- quickly taking a look, we would need to use NetworkCredential, which both HttpClient and HttpWebRequest support, rather than manually adding to the request headers as we do now.

The tricky bit would be supporting both string and SecureString, as I'd imagine we'd want to do, and also backporting without breaking backwards compatibility.

Thoughts @Mpdreamz @russcam ?

[Mpdreamz]

SecureString was removed from netstandard 1.x and still has some issues being really encrypted on platforms other than Windows.

netstandard 2.x brings it back so we could look at supporting this in 6.x

[russcam]

Looks like netstandard1.3 support for this might be better now, if we think it's worth doing?

[Mpdreamz]

https://github.com/dotnet/coreclr/blob/e74cdcb1ed6021eaf03eea5ee7f6ba3c6b403daf/src/mscorlib/corefx/System/Security/SecureString.Unix.cs#L11-L19

this makes me inclined to start changing this over to SecureString in 7.x adding it in 6.x is a bwc break I think.

[russcam]

I've opened #3806 to address

[russcam]

Closing this as implemented in 7.x

[RolfDeVries]

In some cases the createstring method returns a value that looks like chinese instead of the original string. I still have to investigate why. Is this a known issue?

I think it is a threading issue. Secure string does not seem thread safe, it encrypts and decrypts the buffer in place on Read actions without a lock.
https://referencesource.microsoft.com/#mscorlib/system/security/securestring.cs,77d68ea938f47705,references

Elasticclient is now no longer threadsafe, which does not comply to the docs
https://www.elastic.co/guide/en/elasticsearch/client/net-api/current/lifetimes.html

[russcam]

@RolfDeVries I've replied on #3806 (comment).