Jak zaszyfrować connectionstring w app.config, aby aplikacja desktopowa działała ?

VS2015, SQLServer2012, aplikacja desktopowa (nie webowa).
Po uruchomieniu programu Aplik, tworzy się plik Aplik.exe.config , który jest taki sam jak app.config i widać connectionstring.

Jak ukryć connectionstring ?

Mam w app.config:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
    </configSections>
    <connectionStrings>
        <add name="Aplik.Properties.Settings.bazaConnectionString" connectionString="Data Source=serw-123\SQLEXPRESS;Initial Catalog=baza;Persist Security Info=True;User ID=sa;Password=haslo123"
            providerName="System.Data.SqlClient" />
    </connectionStrings>
</configuration>

W kilku DataSet mam po kilka TableAdapter, które korzystają z Connection: bazaConnectionString i rozumiem, że podczas działania programu co chwilę korzysta on ze stałej bazaConnectionString.

Piszą żeby zaszyfrować w app.config jak poniżej

...
<connectionStrings>
  <add name="cn" connectionString="retYretYretYretYretYretY" providerName="System.Data.SqlClient"/>
</connectionStrings>
...

Przecież jak to zaszyfruję, to i tak muszę odszyfrować w aplikacji i nadać nową "odszyfrowaną" wartość

i tu się ślad urywa, bo nie można zmienić wartości dla

Properties.Settings.Default.bazaConnectionString

Proszę o pomoc w rozwiązaniu tego poważnego dla mnie programu.
Dziękuje z dołu (bo czuję jak się zapadam:-)

Encoding App.Config

Być może da rady wykorzystać jeszcze to: https://kurzyniec.pl/artykuly/zabezpieczenie-pliku-webconfig/

Szyfrowanie jedynie ochroni connection stringa przed wścibskimi oczami mniej rozgarniętych użytkowników. Jak ktoś będzie chciał się dobrać do bazy to i tak wydobędzie login i hasło z apliakcji. Dlatego trzeba się liczyć z tym że hasło i użytkownik są dostępne i trzeba odpowiednio ograniczyć możliwości takiego użytkownika na bazie. A najlepiej dodać warstwę api pomiędzy aplikacją a bazą, wtedy będziemy mieli największą elastyczność w definiowaniu autoryzacji użytkowników.

Nadal problem.
W Project-> Properties -> Setting mam bazaConnectionString i mogę go wyświetlić:
Properties.Settings.Default.bazaConnectionString . Usunąłem go.

No to inaczej:
Zaszyfrowałem app.config dla mojej aplikacji desktopowej poleceniem:

%windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -pef "connectionStrings" c:\wynik

i zrobił się ładny zaszyfrowany web.config, zmieniłem nazwę na app.config i skopiowałem do VisualStudio.

Uruchomiłem program i jak sprawdzić czy się wczytało ?
Jaki wyświetlić aktualny "niby" wczytany z app.config connectionstring ?

P.S.
Podczas pracy w programie wywala błąd w DataSet na TableAdapter, gdzie jest właściwość Connection, ale chyba stara.
Jak ją zmienić ?

Niemożliwe, żeby VS nie rozwiązywał takiego przypadku w prosty sposób :-(

Profesjonalnie zajmuje się wyciąganiem haseł do baz danych (automotive głównie) i ich deszyfrowaniem, dlatego powiem Ci, że zapisanie hasła do połączenia gdziekolwiek uchroni Cię jedynie przed kimś, kto nie odpali sobie tego w debuggerze. W przeciwnym wypadku można takie hasło przechwycić dokładnie w momencie wywołania, albo zastawiając w debuggerze pułapkę na funkcji łączącej się z bazą, albo podstawiając jej spreparowane sterowniki bazy danych z włączonym logowaniem (takie proxy). Rozumiem, że niekiedy nie ma wyboru, jeśli baza danych jest instalowana lokalnie, no ale mówiąc tak w skrócie - to i tak nie ma sensu :)

Jak chcesz sobie zaszyfrować string w C# to mam taką zabawkę https://www.stringencrypt.com/ tu masz darmowy kod aktywacyjny 0BD1-B2F6-4BC7-ABAC

1. Wpisujesz string
2. Wpisujesz label
3. Wybierasz C#
4. Szyfruje Ci string
5. Generuje polimorficzny (losowy) kod deszyfrujący dla tego stringa

Wystaw API zamiast podpinać użytkownika bezpośrednio do współdzielonej bazy.

Generalnie tutaj samo podejście jest złe.

Aplikacja desktopowa nie powinna się łączyć bezpośrednio z bazą.
Rozwiązuje się to w taki sposób, że wystawiasz API komunikacyjne. Aplikacja komunikuje się z tym API, a ono dopiero z bazą. Dodatkowo API powinno autoryzować zapytania na podstawie danych nie przechowywanych w samej aplikacji (np. login i hasło użytkownika). Wtedy nawet jak ktoś zdekompiluje Twoją aplikację to nie będzie znał danych do połączenia z API.

kobi55 napisał(a):

Aplikacja desktopowa nie powinna się łączyć bezpośrednio z bazą.

To rozjechałeś 99% rynku ...
Ty tak serio? Czy "zapomniałeś" określić kontekst wypowiedzi?

AnyKtokolwiek napisał(a):

kobi55 napisał(a):

Aplikacja desktopowa nie powinna się łączyć bezpośrednio z bazą.

To rozjechałeś 99% rynku ...
Ty tak serio? Czy "zapomniałeś" określić kontekst wypowiedzi?

Wyjaśnij mi proszę co Cię tak zbulwersowało w mojej wypowiedzi? Być może napisałem zbyt ogólnie to z chęcią to dopowiem ;)

@kobi55: No ja akurat rozumiem @AnyKtokolwiek bo takie firmy jak Comarch i ich Optima, czy Soneta i ich Enova nie ma żadnego API pośredniego i łączy się bezpośrednio do bazy danych. Mam jeszcze jedno pytanie. Co jeśli napiszę aplikację okienkową, która robi kopię bazy danych? API ma mi wysłać parogigowy plik? Czy jak mam to zrobić?

To jak to jest w końcu z tym pośrednictwem Web API? Bo właśnie siedzę nad małą aplikacją WPF i nie wiem czy klepać do niej API czy repo ;p

A tak trochę poważniej, to kiedyś gdzieś czytałem, że to jest bezpieczniejsze rozwiązanie niż bezpośrednie połączenie. Ale ja się nie znam.

Specjalnie dla tych wszystkich złośników wyżej. Wybaczcie mi, nie pomyślałem, że ktoś może w ogóle wpaść na pomysł pisania api do aplikacji standalone czy innej małej aplikacyjki. Jestem pod wrażeniem ;)

PS. Tak dla pełnego zrozumienia: do aplikacji konsolowej, która jednorazowo realizuje jakąś czynność też nie każę Wam pisać API ;)

mimirus napisał(a):

i tu się ślad urywa, bo nie można zmienić wartości dla

Properties.Settings.Default.bazaConnectionString

1.można zmienić, tu działający przykład:
EwidCP.Properties.Settings.Default["EwidOsobConnectionString"] = cnn0_str.ConnectionString;

2. Możesz trochę utrudnić życie włamywaczom w ten sposób, że stosujesz logowanie 2-etapowe.
   Właściwy login i hasło masz zapisane w bazie, w app.config trzymasz login i hasło startowe,
   login startowy ma prawo tylko do widoku odczytującego login i hasło główne.
   Dane startowe kodujesz innym algorytmem niż główne.
   Oczywiście po zdekompilowaniu aplikacji da się wyciągnąć główny login.