@FakeAccount - W tej sytuacji to niezbyt pomoże, bo
- hashem hasła sie nie zaloguje
- hash hasła jest bezpieczniejszy od plaintextu ale dalej można go złamać (zakładając słabe hasło)
- program musi się zalogować do bazy żeby robić swoje operacje - więc jeśli hashem hasła program się zaloguje w jakiś sposób, to dokładnie tego samego sposobu może użyć "zły" użytkownik i wychodzi ostatecznie na to samo.
@dobry.basket - słusznie masz wątpliwości, bo to rzeczywisty problem.
http://www.dreamincode.net/forums/topic/236688-encryptingdecrypting-your-appconfig-or-webconfig/
To żadne rozwiązanie (z punktu widzenia security), bo hasło do bazy dalej jest u użytkownika. Skoro program potrafi connection string z configa przeczytać, będzie to potrafił też zrobić abuser. Szyfrowanie web.configu to czyste security through obscurity.
Rozwiązania masz dwa:
- zignorować problem, liczyć że nikt tego nie będzie sprawdzał (z tego założenia wychodzą dziesiątki tysięcy programistów, nawet tych robiących dość wrażliwe rzeczy) - oczywiście nie polecam ;)
- zrobić dobrze: założyć że wszystko co może zrobić aplikacja, może też zrobić abuser. I skoncentrować się na ograniczeniu tych możliwości (co będzie wymagało zmian w kodzie niestety).
Czyli musisz stworzyć jakieś API po stronie serwera, które będzie przyjmowało requesty od użytkownika i wykonywało odpowiednie operacje - program nie będize miał bezpośredniego dostępu do bazy danych, i zamiast db.Execute("insert into users values y") będzie np. coś w rodzaju api.InsertUser(y);.
Gdzie tu zysk: możesz dzięki temu
- (przede wszystkim) kontrolować co może zapisać/odczytać/zmienić użytkownik. Np. może dodać x do tabeli y, ale nie może usunać wszystkich danych z żadnej tabeli, ani zmienić danych innych użytkowników. Najlepiej oczywiście żeby każdy użytkownik aplikacji był autentykowany jakimś id i hasłem.
- robić jakieś quoty, ograniczać ilość requestów/sekundę wykonywanych przez użytkownika etc
- (poza bezpieczeństwem) robić statystyki/monitorować aktywność użytkowników i np. patrzeć które funkcje programu są najczęściej używane
Ewentualnie biedniejsza wersja poprzedniego - username i hasło użytkownika do bazy zostawić w konfigu i aplikacji, ale ograniczyć maksymalnie uprawnienia tego użytkownika. W najlepszej możliwej opcji użytkownik na którego loguje sie aplikacja winformsowa ma wyłącznie prawo do wołania przeznaczonych do niego procedur składowanych.
Obie te opcje wymagają trochę zmian w kodzie - magicznego rozwiązania "dopisz kilkanaście linijek kodu" niestety nie ma.