Logowanie, bezpieczeństwo, w jaki sposób zrobić to dobrze?

Question

Hej. Z góry oznajmiam iż jestem świeżakiem, jeśli popełnię jakiś błąd to proszę bez linczu jak na pewnym forum na litekę "e" :). Otóż pisze program w winforms, jest to projekt który pisze w celu nauczenia się języka. Posiadam formularz logowania i tutaj pojawia się mój problem.

1. Jak dobrze zrobić logowanie, aby wszystko było bezpiecznie? 

Na poradnikach dla początkujących, widzę jak ludzie wrzucają swojego connection stringa do kodu, logują się szukając danych podanych od użytkownika przy logowaniu (login,hasło) w bazie danych. Wyczytałem (i też tak podejrzewam) że to skrajnie głupie, podawanie swojego loginu i hasła do bazy danych bezpośrednio w kodzie.. Jak zatem to rozwiązać? Tak żeby było bezpiecznie, tak żeby użytkownik nie musiał się bać zalogować do aplikacji :D. 

+Nadmienię tutaj jeszcze tylko, że znam zasady z hashowaniem haseł, używaniem salt i wiem dokładnie jak się to robi, chodzi mi konkretnie o wpisywanie swoich danych dostępowych do kodu.

2. Jak postępować z danymi użytkownika w dalszej części, po zalogowaniu?

Okej, załóżmy że nasz użytkownik się zalogował. Znika okno logowania, pojawia się program. W programie bym chciał wyświetlić:

• Nickname użytkownika
• Ilość punktów 

Oczywiście do obu danych posiadam pola im odpowiadające w bazie danych. Z samymi komendami do SQL nie mam problemu, mógłbym te dane najzwyczajniej w świecie wyciągnąć z bazy, ale domyślam się że wpisanie na sztywno SELECT points FROM users WHERE user=login; jest skrajnie głupim pomysłem, co prawda by zadziałało ale ja chciałbym żeby aplikacja była bezpieczna i szukam sposobu aby zrobić to poprawnie.

Bardzo proszę o pomoc, oprócz samych wskazówek wszelkie materiały (po angielsku też mogą być) się przydadzą, z góry dziękuję! :)

Używam PostgreSQL, Piszę w C# WinForms

Answer 1

Odpowiadając na 1. pytanie:

Connection stringi najlepiej podawać w plikach konfiguracynych (dla ASP.NET Core to będzie najczęściej appsettings.json, dla WinForms app.config). Z takim podejściem najczęściej się spotykam.

Alternatywna opcja, to podawanie danych jako environment variables lub argumenty przekazywane podczas uruchomienia programu. Plus tej opcji jest taki, że łatwo można podać te argumenty z CI/CD. Minus, że trudniej uruchamiać aplikację podczas zwykłego developmentu.

2. pytanie:

W środowisku .NET Core mamy takie narzędzie jak Entity Framework Core (lub w .NET Framework - Entity Framework). Korzystanie z niego ogarnia właśnie kwestie SQL Injections za nas (oczywiście to dużo bardziej rozbudowane narzędzie).

Co do SELECT points FROM users WHERE user=login dobrze, że zdajesz sobię sprawę z niebezpieczeństwa. Ktoś mógłby dać jako login - "jakisLogin OR 1=1" i wszyscy userzy byliby pobrani.

 

W samej technologii WinForms nie siedzę, więc nie wiem jakie rozwiązanie w tym przypadku jest najlepsze. Starałem się odpowiedzieć w sposób uniwersalny, więc ktoś mający większe doświadczenie z Winforms może mieć celniejszą odpowiedź.

Comments

Bardzo dziękuję za odpowiedź :). Czy znasz może jakieś godne polecenia źródła do nauki Entity Framework? Wiem że mogę pogooglować i pewnie znajdę z 10 poradników stworzonych przez kolegów z Indii, ale może mógłbys coś polecić? Mogą być książki do kupienia, mogą być anglojęzyczne materiały, bez znaczenia.

---

Do EFCore: msdn - poważnie, tutaj jest wszystko - masz nawet ładnie poukładane tematycznie.

A co do sekretów to nie polecam trzymać tego w appsettings.json, tylko korzystać z secret storage

---

No właśnie, zależy mi o takim materiale do EF (nie core). Czym to się różni w działaniu, w którym z tych plików trzymam connection stringa? Jak mogę ocenić co lepiej trzymać w jednym, a co w drugim?

---

Co do EF, to zaleca się, żeby nowe projekty pisać już na Core. Tutaj masz porównanie EF6 vs Core, jeśli w Corze jest wszystko czego potrzebujesz to nie ma sensu stawiać tego na starym EF6.

Co do appsettings.json, to trzymałbym tam konfiguracje projektu, żadnych danych wrażliwych. Wszelkie dane wrażliwe, tj. klucze API, SSH, sekrety do tokenów etc. w secret storage. Secret storage różni się tym, że nigdy nie zacommitujesz kluczy przez przypadek, bo domyślnie tworzy Ci plik z kluczami poza projektem.