Also "My.Settings" sind beim ausliefern der App das was du default eingetragen hast(das ist einkompiliert). Ändert der User was, wird das in
C:\Users\Username\AppData\Local\applikationsname\applikationsname.exe_<zufällige zeichenkette>/Versionsnummer/user.config

gespeichert, verschiebst du die Applikation, ist alles wieder default, ändert der User dann wieder was in den Settings, wird wie oben ein weiterer Ordner angelegt wieder mit zufälliger Zeichenkette, dort ist dann auch wieder eine user.config.

Die My.Settings sind also Pfadgebunden, sollte auch Versions gebunden sein, kann also sein sein, das nach einem Update(wenn die versionnummer geändert wurde) wieder alles default ist, obwohl der Pfad(der exe) gleich ist. Ich empfehle eine Datei neben der exe zu nutzen.(De-/Serialisierung)

@Lord Luxor Oder Du schaust hier mal vorbei, da werden die "normalen" Settings da abgelegt, wo Du es vorgibst:
UserSettingsProvider (Persistieren von UserSettings)

Nur zur Ergänzung, wann und wo die Daten der Settings versteckt werden...
Setting Speicherort

Ähm - üblicherweise wird eine Connection doch mit einem speziell dafür vorgesehenem Setting-Typ gespeichert - wundert mich, dass du da 4 Einstellungen für verwendest - alle als String

Ja das mit den Passwörten ist so eine Sache. Hab ich erst garnet drauf geachtet, also ich täte niemals auf die Idee kommen, andere als root-user auf die DB zugreifen zu lassen. Erstelle weitere User mit weniger rechten. Oder greifen die nicht mit dem Tool auf einer deiner DBs zu?

Auch ist es immer eine gute Idee, wenn die DB öffentlich erreichbar ist, den User root umzubenennen, den das schützt bei Angriffen, würde ich auf die Idee kommen eine DB zu attackieren, wären root und admin die ersten Usernamen mit den ich probieren täte.(Abgesehen von SQL-Injection)

Sobald es der Computer "lesen" kann, kann es jeder der weiss wie. Daher lasse ich keinen direkten Zugriff auf DBs zu, wenn ich von aussen auf DBs zugreifen muss, mache ich mir eine kleine API mit PHP, so ist es ausgeschlossen, das jemand von aussen ans Passwort kommt, jeder "User" hat sein eigenes Passwort und nur betimmte Rechte, nämlich nur die, die er braucht, auch protokolliere ich jeden schreibenden Zugriff. Der Nachteil der daraus entsteht, den nehm ich gern in kauf(Api mit PHP zu erstellen), DataSet&Co von Hand erstellen etc.

Ich bin da "Better Safe than sorry" eingestellt.

Verschlüssel halt die einzelnen Strings bevor du sie den Settings zuweist.

@Takafusa und wo stehen die Zugangsdaten für die API bzw. wie sind diese gesichert? Wir hatten hier mal genau dieses Thema, leider finde ich den Thread nicht mehr. @VaporiZed findest du diesen Thread noch wo wir über das Thema „Passwörter“ Diskutiert hatten?

Lord Luxor schrieb:

Es geht mir primär darum, dass der Anwender die Möglichkeit hat die Datenquelle jederzeit zu ändern.

Das ist bei Setting-ConnectionStrings nicht vorgesehen.
Beim Verteilen eines Programms wird eine geeignete .config-Datei mitgeliefert, die den ConnectionString bestimmt.
Dass iwelche User lustig die Datenbank wechseln ist wie gesagt nicht vorgesehen, und ich kann mir weder vorstellen, wozu das gut sein sollte, und wenn doch, dass sowas dann auch gut geht.

---

Jp, das Sicherheitsproblem ist problematisch.
Auf Arbeit haben wir einen Web-Dienst, der die DB komplett verbirgt.
Per https kann ein User sich anmelden, und eine Session eröffnen. Für die Session erhält er ein "Token" - das ist eine Art temporäres Passwort.
Das heisst: Nirgendwo sind Credentials "versteckt" gespeichert, sondern die müssen im Kopf des Anwenders sein.
Und auch im weiteren bleibt die Kommunikation TLS-verschlüsselt.

Also nix, was ein einzelner HobbyProgrammierer sich so hinbasteln könnte.

@mrMo Die Passwörter für die API habe ich verschlüsselt neben der Anwendung aber auch noch zufällige Bytes welche auch innerhalb der Bytes der verschlüsselten Credentials sind, wenn der User die denn speichern will, diese bekommt auch das FileAttribute "Hidden", klar ist das auch leicht knackbar. Ich finde das so einfacher zu verwalten, via maßgeschneidertes Webinterface, wer auf welche Datenbank/Tabellen zugreifen kann, wer wo schreiben darf. Zudem ist die API auch nur via HTTPS erreichbar.

ErfinderDesRades schrieb:

Also nix, was ein einzelner HobbyProgrammierer sich so hinbasteln könnte.

Mit meiner Api ist das ähnlich(nur ohne Token, ich hab PHP Sessions), nur kann der User optional die Zugangsdaten speichern, wird das Passwort aber geleakt, muss er "den kopf hinhalten", wird ja alles Protokolliert und Backups werden auch regelmäßig gemacht. Bin aber auch nur ein einzelner HobbyProgrammierer, das ist durchaus machbar, wenn man sich in die Materie einarbeitet und gut drüber nachdenkt, wie auch bereit ist, mehrafuwand in kauf zu nehmen.
Aber ich finde eine Website wo man ein Token generieren kann, auch nicht schlecht, wie geht das bei euch via Webseite oder in der Applikation selbst? Nur firmenintern erreichbar? Denn bei webseite hat man auch wieder das Problem mit dem speichern von zugangsdaten, das geht ja auch im Webbrowser.

Takafusa schrieb:

wie geht das bei euch via Webseite oder in der Applikation selbst?

Weiss ich nicht wirklich.
vermutlich "Website", weil "Application" kann man unsere Service-Landschaft wohl kaum nennen.
Und da sind auch Zertifikate dran beteiligt, und ein fettes Nuget-Paket, mit viele Interfaces, Konfiguration, und Krims und Krams - wo ich alles nicht durchblicke, und auch froh bin, dassich es nicht muss.

Takafusa schrieb:

HobbyProgrammierer, das ist durchaus machbar

Tja, da haste mir was vorraus - ich hab privat noch nichtmal eine TLS-Kommunikation hinbekommen, und auch keinen Dienst, als ichs mal versucht hattete.

Muss man nicht mal selbst implementieren. SSL Zertifikat, selbst erstellen oder lassen, Server konfigurieren, nur HTTPS zulassen. Via Webrequest die Zugriffe machen. Klar gibt es so auch Angriffsmöghlichkeiten, aber ich schätze das Risiko als sehr gering ein. Strip SSL ist da denke ich eine der wenigen Möglichkeiten. Das Risiko eines geleakten Passworts schätze ich als höher ein.

PHP selbst ist keine API, ein Script Interpreter passt eher, hab mir damit eine API gebastelt. Mit PHP hohle ich die Daten aus der DB und spiele sie aus. Bzw. nehme auch Daten an, um sie in die DB einzutragen, aber nur wenn der User angemeldet ist, jedesmal wird geprüft ob für den User eine Session erstellt wurde, das passiert nur wenn er sich anmeldet.

Also der MySql-Server, wie auch der Web-Server(Apache) laufen auf dem gleichen System. Von aussen ist kein Direkt-Zugriff auf den DB-Server möglich.

@mrMo:
Hashing und Verschlüsseln von DB-Daten: best practice gesucht