App.config verschlüsseln

Warum hast Du mit .NET Core 3 eine App.Config, und keine AppSettings.json?
In eine Settings-Datei sollten überhaupt keine sensiblen Informationen platziert werden.

Was ist denn Deine Umgebung? Webanwendung? IIS? Cloud?

Nein, prinzipiell ist AppSettings die aktuelle Variante.
Das neue Tooling unterstützt auch App.Configs gar nicht mehr. Auch die .NET Core Settings Dokumentation behandelt ausschließlich AppSettings.json :-)

Prinzipiell solltest Du bei der Grundstruktur der Konsolenanwendungen folgendes machen:
Bau Dir einen ConsoleHost, der die Konfiguration und die Dependency Injection übernimmt.
Siehe Sample hier:  https://github.com/BenjaminAbt/Hangfire....rver/Program.cs

Damit hast Du die Grundstruktur.

Bleibt das Thema Settings: Settings-Dateien, egal ob AppConfig oder AppSettings.json, die sensible Informationen haben, haben auf gemeinsamen Laufwerken nichts, aber auch gar nichts zu suchen.
Da hilft Dir prinzipiell die beste Verschlüsselung nichts, weil man sie eben auch wieder in der Anwendung entschlüsseln kann - dann kannst es gleich lassen.

Du kannst problemlos Settings aus mehreren Quellen laden
- Dateien, an verschiedenen Orten
- Umgebungsvariablen
- Datenbanken...

Speicher die sensible Daten bei Desktopanwendungen im Benutzerverzeichnis (AppData) oder in de Umgebungsvariablen des Nutzers.
Aber bitte nicht auf Shared Folders.

Alternativ: einfach die Connection Strings gar nicht speichern und den Benutzer beim Start eingeben lassen.
Die Variante verwende ich recht häufig - eben um nirgends irgendwelche Settings zu hinterlassen.

Zitat von RayYago:

Ich weiß nicht genau was ein ConsoleHost ist

Wenn Du etwas nicht weißt, dann hilft meist ein Blick in die Dokumentation.

Zitat von https://docs.microsoft.com/de-de/aspnet/core/fundamentals/host/generic-host?view=aspnetcore-3.1:

Der Host ist ein Objekt, das alle Ressourcen der App kapselt, z. B.: Abhängigkeitsinjektion Protokollierung Konfiguration IHostedService-Implementierungen

Es sorgt dafür, dass Du ein Rahmen hast, der Dir gewisse Verantwortungen abnimmt - egal ob in ASP.NET Anwendungen, wo es bereits eingebaut ist, oder Konsolenanwendungen (in denen man es leider selbst hinzugefügen muss) oder Desktop Anwendungen (in denen man das meiste noch hinzufügen muss).
Ein Code Beispiel für Konsolenanwendungen siehst Du via dem GitHub Link.
Die eigentliche Anwendung ist dann:

C#-Code:

// Startup                     services.AddHostedService<MyHangfireApp>();

als Start und als Implementierung:

C#-Code (https://github.com/BenjaminAbt/Hangfire.ConsoleHost/blob/master/sample/Server/MyHangfireApp.cs):

public class MyHangfireApp : IHostedService, IDisposable

Daher hab ich Dir den Link gegeben.

Zitat von RayYago:

Diese Verzeichnise sind doch auch einsehbar?

Hab ProgramData in AppData bereits korrigiert gehabt.

Aber ja, diese Verzeichnisse sind immer lesbar, sobald der PC komprommitiert ist.
Während er Entwicklung gibt es auch die dotnet user secrets, die manche LEute auch für den produktiven Einsatz nehmen, die auf Environment Variables basieren, aber für den produtiven Einsatz nicht empfohlen sind.

Zitat von https://docs.microsoft.com/de-de/aspnet/core/security/app-secrets?view=aspnetcore-3.1&tabs=windows:

Umgebungsvariablen werden im Allgemeinen in unverschlüsseltem, unverschlüsseltem Text gespeichert. Wenn der Computer oder der Prozess kompromittiert ist, kann von nicht vertrauenswürdigen Parteien auf Umgebungsvariablen zugegriffen werden. Möglicherweise sind zusätzliche Maßnahmen erforderlich, um eine Offenlegung von Benutzer Geheimnissen zu verhindern.

Zitat von RayYago:

Umgebungsvariablen sind doch auch als plain text zu sehen. Und eine Datei mit dem ConnectionString einfach unter ProgramData abzulegen ist wahrscheinlich auch nicht besonders sicher oder?

Egal wie man ein Passwort ablegt: sobald man ein Passwort irgendwo ablegt, ist es nicht sicher.
Sicher sind nur integrierte Lösungen wie zB. Azure Active Directory oder zB. Azure Key Vault (für Applikationen in der Azure Umgebung).

Alles, was Du irgendwie auf Deinem PC ablegst, kann auf eine gewisse Art und Weise ausgelesen werden.
Alles.

Eine Verschlüsselung von etwas, das Du nachher wieder im Urzustand brauchst (wie ein ConnectionString oder ein Passwort, also kein Hashing) ist prinzipiell auch nur eine Verschleierung.
Spätestens im Speicher kann es ausgelesen werden.

Daher auch den Tipp mit der Alternative.

Der Zustand

Zitat von RayYago:

Aber die eigentliche App.Config bleibt unverschlüsselt. Der Client hat zwar die verschlüsselte Version, aber in meinen Verzeichnissen ist die unverschlüsselte Datei zu finden.

ist prinzipiell korrekt so.
Du hast während der Entwicklung immer die originale Datei; und wenn diese Teil des Publish Prozesses ist, dann wird diese natürlich zusätzlich mitgliefert.

Im Prinzip ist das alles eher "ein Problem Deines Workflows"; das so kein Tooling abdeckt.

Ein wenig google hätte dich zu diesem Beitrag geführt:
 https://stackoverflow.com/questions/5491...ation-programma

--> indem du dir über DI die Implementierung von IApplicationLifetime holst.

Edit: Hier noch die Dokumentation dazu:  https://docs.microsoft.com/en-us/aspnet/...icationlifetime

Den Exit Code musst du weiterhin aus der Main method zurückgeben.

Eine "globale Variable" ist nicht notwendig, hierfür kannst du das gleiche Konstrukt verwenden, wie Microsoft für den IApplicationLifetime verwendet: Ein im Dependency Injection registriertes Singleton, dass du allerdings vorab instanziierst und zur Kommunikation zwischen deinem HostedService und der Main Methode verwendest.

C#-Code:

static async Task<int> Main(string[] args)         {             MyLifetimeHandler myLifetime = new MyLifetimeHandler();             IHostBuilder builder = new HostBuilder()                     .ConfigureAppConfiguration((hostingContext, config) =>                     {                         config.SetBasePath(Directory.GetCurrentDirectory());                         config.AddJsonFile("appsettings.json", optional: true);                         config.AddJsonFile($"appsettings.{Environment.MachineName}.json", optional: true);                     })                     .ConfigureServices((hostingContext, services) =>                     {                         services.AddOptions();                         services.AddSingleton(myLifetime);                         // Startup                         services.AddHostedService<MyApp>();                     });             await builder.RunConsoleAsync();             return myLifetime.ExitCode;         }

C#-Code:

class MyApp: IHostedService {   public MyApp(...., MyLifetimeHandler lifetime) {...}   [...] }

C#-Code:

class MyLifetimeHandler {   private readonly IApplicationLifetime _lifetime;   public int ExitCode { get; private set; }   MyLifetimeHandler(IApplicationLifetime lifetime)   {      _lifetime = lifetime;   }   void Exit(int exitCode)   {     ExitCode = exitCode;     _lifetime.StopApplication();   } }

Edit: vielleicht kann einer der Mods das mal vom Thema trennen.