nats-io / nats.net

The official C# Client for NATS

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Ability to create connection with string credentials instead of from a file

schoetbi opened this issue · comments

Proposed change

The current implementation expects a file name for the credentials. This requires the file to be on disk, what makes it readable by others.

A workaround is the use of the handlers Options.UserJWTEventHandler and Options.UserSignatureEventHandler but this is not straightforward.

I propose that the credentials are transported as a SecureString so that it can be read e.g. from the Windows Data Protection API or directly from a key vault like Azure key vault.

So this is the method signature:

/// <param name="credentials">The content of the chained credentials file.</param>
public IConnection CreateConnection(string url, SecureString credentials, bool reconnectOnConnect = false)

Use case

I do not want to store the credentials unencrypted on disk

Contribution

No response

@schoetbi I can't do this because of the language level of the project. Any chance you have a greenfield project? If so I would suggest using the .NET v2.
Everything else underneath is insecure, but I can offer these, that way you can use SecureString and present the credentials from memory as strings instead of need a file.

public IConnection CreateConnection(string url, string credentials, bool reconnectOnConnect = false)
public IConnection CreateConnection(string url, string userJwt, string nkeySeed, bool reconnectOnConnect = false)

WDYT?

@scottf Yes, I can use .NET v2 for my project. The main priority is that I want to avoid writing the credentials to disk. The use of SecureString is optional. So your suggestion with passing the credentials as string (not filename) is fine.

In general you should not use SecureString for new development, and even when available it does not adequately protect confidential information.

https://learn.microsoft.com/en-us/dotnet/fundamentals/runtime-libraries/system-security-securestring

@sixlettervariables Thanks for this interesting read. The use of SecureString might also be a little bit too much for my thread model. I only want to ensure that the credentials are not written to disk. So I will refrain from the use of SecureString.

Adding regular string version of the api here: #885