String przez port czy lepiej bufor i szyfrowanie

Dzień dobry,
Tworzę swój pierwszy serwer prostych szyfrowanych baz danych na własny użytek i moich programów(wiem że są gotowce, ale tak też się uczę, protokołów i funkcji sql).
Przesyłam przez port stringi z danymi , po połączeniu , warunkiem otrzymania odpowiedzi od serwera jest padanie hasła.
Moje pytanie jest takie, czy szyfrować dane przesyłane i przesyłać je jako bufor bajtów czy port przesyłający string jest na tyle bezpieczny,że nie trzeba tego szyfrować?
Generalnie program, dla jakiego piszę teraz serwer nie przechowuje żadnych danych wymagających ochrony, jednak skoro już serwer sobie napiszę to chciałbym aby do ew. przyszłych projektów mógł służyć również. Działa tylko w sieci lokalnej ale rozważam rozszerzenia o przekierowanie portu i dostęp z internetu, chociażby aby mógł wprowadzać automatyczne aktualizacje bez używania serwera ftp wszystkich klientów w sieci lokalnej.

Zależy od serwera bazodanowego - np. Postgres wspiera TCP/IP + SSL natywnie (https://www.postgresql.org/docs/9.1/ssl-tcp.html).

chociażby aby mógł wprowadzać automatyczne aktualizacje bez używania serwera ftp wszystkich klientów w sieci lokalnej

fwiw, dla bezpieczeństwa oraz wygody zasadniczo obecnie rzadko korzysta się z rozwiązań w których klient łączy się bezpośrednio do bazy - najczęściej po drodze jest jakieś HTTP API; w takiej sytuacji bazodanowy TLS ma trochę mniejszy sens, ponieważ klienci łączą się jedynie do API (np. po HTTPS) i nie widzą bezpośredniego ruchu między serwerem API a serwerem bazodanowym.

Nie używam żadnego serwera baz danych poza pisanym właśnie przez siebie(wykonuje polecenia jakie prześlę stringiem i jakie sam zaprogramowałem). Dane są szyfrowane przeze mnie (programy) kluczem losowym zmiennej długości wmonotwanym w przesyłane dane i w każdą z baz danych. Zapewnić to może pełne zabezpieczenie danych przed rozszyfrowaniem. Jednak nie wiem jak bardzo jest to potrzebne w sieci lokalnej. Czy szyfrować czy używać stringów. Szyfrowanie nieco spowolni przesył, choć z drugiej strony ilość danych jest mała w zapytaniach, przynajmniej w tym projekcie. (Amatorskim)

Skoro szyfrujesz dane i klucz wysyłasz razem z nimi, to dowolna osoba podsłuchująca ruch w sieci (i znająca Twój algorytm) może ten ruch rozszyfrować, c'nie -- a zatem na czym polega tutaj bezpieczeństwo?

Chyba że masz sytuację w stylu, że szyfrujesz kluczem publicznym, a baza danych ma w sobie schowany klucz prywatny; wtedy najprawdopodobniej jesteś podatny na replay attack, ale jako-tako pewne bezpieczeństwo to gwarantuje.

Tak czy siak, zawsze najlepiej nie wynajdywać szyfrowania od zera - jeśli naprawdę zależy Ci na bezpieczeństwie, to wykorzystaj TLS albo tuneluj ruch po SSL; każde rozwiązanie w stylu "szyfruję stringi ręcznie emacsem przez sendmail" będzie miało jakieś ukryte wady, o których możesz się dowiedzieć za późno (chyba że jesteś specjalistą od kryptografii, oczywiście ).

Druga opcja, czyli baza ma ukryty klucz w sobie i ja tylko wiem na jakiej zasadzie go szukać w danych ,jest losowy i długi też losowo ale dość długi. Tak więc każdy bajt w bazie i przesyłanych danych jest losowy(bo powiązany z kluczem tworzonym na nowo przy każdym zapisie do bazy, który jest losowy).

Oczywiście to wszystko jest tworzone na nowo, ale raczej jeśli nikomu nie zdradzę sposobu szyfrowania, jak znaleźć klucz to złamanie sposobu będzie niezmiernie trudne.

Może wyważanie otwartych drzwi jest trochę śmieszne- zamiast korzystać z gotowych sposobów ale zabawa z bajtami , chowanie klucza trochę ćwiczy głowę i bawi. Nie koniecznie spowalnia proces pisania programu - bo i tak wszystko jest amatorskie bardzo i hobbystyczne, na ile czasu wystarcza.

Pewnie, tak żeby poeksperymentować i zobaczyć jak szyfrowania działają, jest to dobra i wartościowa rzecz :-)

i ja tylko wiem na jakiej zasadzie go szukać w danych

fwiw, to się nazywa security by obscurity i nie stanowi żadnej bariery / nie daje żadnej gwarancji bezpieczeństwa; głównie dlatego, że skoro szyfrowanie danych następuje w kliencie, a klient działa na komputerach użytkowników (z tego co zrozumiałem), to nic nie stoi na przeszkodzie, aby ktoś sobie tego klienta odpalił pod debuggerem i zobaczył jak działa szyfrowanie (a z tego wywnioskował jak może działać odszyfrowywanie); jedyną ostoją bezpieczeństwa tutaj jest fakt, że baza danych operuje na klucz prywatnym, który tej bazy nigdy nie opuszcza (a i to jest bezpieczne jedynie pod warunkiem, że szyfrowanie jest skuteczne - tutaj, jak rozumiem, oparte o RSA).

Zgadza się! Jeśli na komputerze gdzie jest klient debugowanie ktoś sobie włączy to tylko będzie znał sposób kodowania przesyłanych danych(choć debugować plik wykonywalny chyba nie jest łatwo?), a skoro ma klienta to i tak ma dostęp do danych przesyłanych na zapytanie. Natomiast nadal nie ma dostępu do bazy danych bo szyfrowanie tam jest inne- dużo większe porcje danych w plikach i fizycznego dostępu do bazy nie ma.

choć debugować plik wykonywalny chyba nie jest łatwo?

Nah, w XXI wieku, zwłaszcza z narzędziami w stylu https://rr-project.org/ czy IDA Pro, debuggowanie bez dostępu do kodu źródłowego to pestka.

Natomiast nadal nie ma dostępu do bazy danych

Tak, ale często to w ogóle nie jest potrzebne - zauważ, że jeśli Twoją obawą jest podsłuch ruchu, to dostęp do binarki klienta (a zatem możliwość ekstrakcji algorytmu szyfrowania oraz części klucza) w połączeniu z niebezpiecznym / źle zastosowanym algorytmem szyfrowania stanowi właśnie możliwy wektor ataku; może i nie umożliwi Ci on bezpośredniego dostępu do bazy, ale podsłuch odszyfrowanego ruchu sieciowego do bazy (np. z innych komputerów w firmie) to już wiele.

(przykładowy scenariusz umożliwiający wykorzystanie takiej luki: atakujący i komputery pracowników znajdujące się w tej samej sieci wifi.)

Oczywiście, nie zawsze i nie wszędzie coś takiego będzie stanowiło problem - ale jeśli rozmawiamy ogólnie o dobrych praktykach związanych z szyfrowaniem, no to replay attack i podglądanie odszyfrowanego strumienia to nie byle co :-)

@Windowbee:

Bez urazy, ale twój post to jedno wielkie pomieszanie wszystkiego.
A jest moim życiowym doświadczeniem (nie tylko w informatyce) , że jak ktoś nie umie "w punktach" czegoś zaplanować, to przepali dużo energii i nic wartościowego nie osiągnie.

A co do uczenia się, najczęściej nauczy się źle - jak zła gra na instrumencie, pływanie w złym stylu itd.

U jednego z klientów paprok-dostawca dał (za kasę) super-duper program-skrypt "zaszyfrowany". Skrypt się wyłożył po pewnym czasie, zostawił sobie plik czasowy.
Odszyfrowanie zajęło mi 15 min , zawdzowniłem im, co źle w skrypcie zrobili.

Zaczęło się od tego nieszyfrowanego stringa na porcie. Temat zamknięty. Wiem że muszę szyfrować.

Poświęciłem jakieś 40 min może 1h żeby sklecić konkurs:

link

Pod linkiem jest program wykonywalny exe oraz baza danych szyfrowana wg mojego sposobu. Tak z czystej ciekawości : ile czasu zajmie wstawienie tutaj zrzutu ekranu z hasłem dostępowym do bazy, czy ktoś to zdebuguje i zrobi, albo złamie bazę bez debugowania?

Po wpisaniu odpowiedniego hasła(po złamaniu bazy lub programu) baza jest wyświetlana w tmemo. Jest tam opis sposobu jej szyfrowania. Dla ułatwienia nie jest szyfrowana od nowa co uruchomienie programu. Pozostaje cały czas tym samym plikiem nazwanym baza.dbx

Poza tym programuję bardzo kiepsko więc nie powinno to stanowić wielkiego problemu. Ale szczerze jestem niezmiernie ciekawy.

Środowisko lazarus, nie jest to wirus(ale na wszelki wypadek uruchamiajcie w odseparowanym środowisku, lazarusa pobierałem z oficjalnej strony) Plik wykonywalny dla Windowsa tylko, dla osx musiałbym więcej porobić. Przepraszam za nomenklaturę którą kaleczę.

Czy ktokolwiek się podejmie? Jedyną nagrodą jest pokazanie ,że faktycznie odszyfrowywanie takich plików i debugowanie programów deszyfrujących, jest mega proste i szybkie, wszystkim, którzy się uczą.