Mam aplikacje desktopową, która przesyła poufne dane do mojej aplikacji webowej.
Chciałbym za wszelką cene się zabezpieczyć przed wyciekiem takich danych, dlatego też rozważam dodatkowe szyfrowanie w postaci klucza publicznego po stronie klienta i prywatnego po stronie serwera, za pomocą którego po prostu zaszyfruje przesyłany payload. Pytanie czy takie coś ma w ogóle sens, czy sam fakt że dane lecą po HTTPS już jest wystarczający?
0
4
Pomijasz jeden ważny aspekt - przed czym (kim) chcesz się bronić? Bo mówiąc "wyciek danych" mam wrażenie, że chodzi ci o kogoś, kto podsłucha twoje połączenie sieciowe po drodze (np. w hotelowym WiFi) i rozszyfruje sobie te dane. W tym przypadku wymuszony HTTPS jest nie do złamania. A krypto asymetryczne pewnie doda ci +10 do poczucia bezpieczeństwa.
Ale - jeśli bronisz się przed użytkownikiem aplikacji, to przecież mogę odpalić debugger i sobie te dane z pamięci wyciągnąć. Na co wtedy szyfrowanie? Może tutaj trzeba się zastanowić?
0
Case jest taki:
- klient wpisuje w apce desktopowej dane logowania username/password i wysyla je w body/headerach do serwera
- serwer uderza do innej aplikacji webowej by na podstawie tych danych uzyskac bearer token
- nastepnie z tym tokenem wykonuje kilka operacji w tej aplikacji webowej i zwraca ich wynik do apki desktopowej
- username/password trzymany jest po stronie klienta
- token trzymany jest w pamieci / krotko zyjacym cache tylko na czas wykonania tych kilku operacji, tak by nie pytac o nowy token przy kazdym callu
Wiec jasne, klient aplikacji desktopowej moze sobie wyciagnac swoje hasla, czy moj klucz publiczny, ale to raczej nie problem.
A pozostale przypadki - tutaj wychodzi na to ze sam HTTPS spokojnie wystarczy?
4
A pozostale przypadki - tutaj wychodzi na to ze sam HTTPS spokojnie wystarczy?
Używasz aplikacji bankowej czy fb na telefonie? To jest właśnie idealny przykład komunikacji klient-serwer zabezpieczonej TLS-em. Więc jeśli ten sposób zabezpieczenia transmisji jest wystarczajacy dla banków to czym się przejmujesz?
P.S. dlatego programiści powinni mieć podstawowa wiedzę z zakresu sieci komputerowych i serwerów, a nie kłapać dziobem ze wyzyskujo
0
Zrób kompresję danych. I w innej formie masz i szybciej będzie chodzić.
3
Re: dodatkowe szyfrowanie
Zwykle, jak junior programista chce "ulepszyć po fabryce" np jako DODATKOWE szyfrowanie - życie pokazuje że osłabia projekt, np wprowadza dodatkowe punkty crackowania, których nie było wcześniej.
@kelog: @markone_dev: popieram
@johnny_Be_good: jak zwykle nie na temat
0
Wprowadzając dodatkowe szyfrowanie chronisz się przed tym, że nawet jak ktoś ci ukradnię domenę i wsadzi swój certyfikat to twoje dane są bezpieczne.
1
Nie ma sensu wprowadzanie dodatkowego (ponad HTTPS) szyfrowania transmisji danych. Zadbaj o to, żeby HTTPS był dobrze skonfigurowany (protokoły, długość klucza, certificate pinning...). Natomiast mając wartościowe dane, należy upewnić się, że są one chronione na każdym etapie, w tym w spoczynku (na dyskach).
Co się stanie, jeżeli ktoś zdobędzie fizyczny dostęp do urządzenia? Dane nadal będą dostępne? Co jeżeli ktoś zdobędzie fizyczny dostęp do do dysku serwera? Jak chronione są backupy? Co w przypadku gdy ktoś włamie się na serwer baz danych? Czy da się zabezpieczyć dane przed odczytaniem przez programistę/devopsa?