[lifapek]

Pytanko bo z pół godziny już szukam i nie umiem tego znaleźć. Jak ktoś ma jakiś artykuł pod ręką, który wyjaśnia temat to poproszę.

Czy ja dobrze rozumiem, ze podczas logowania gdy użytkownik wpisuje login i hasło i wciska 'zaloguj' przeglądarka za pomocą certyfikatu SSL szyfruje cały request i wysyła na serwer i to nam zapewnia, że login i hasło są bezpieczne?

1. Jeśli tak to po zalogowaniu jak już dostaniemy token JWT i mamy w headerze token bearer, który poświadcza naszą autentyczność, to czy cały token JWT też jest za każdym razem szyfrowany przy każdym requescie czy szyfrowanie odbywa się tylko przy logowaniu i ewentualnie przesyłaniu wrażliwych danych typu numer karty kredytowej?
2. Gdy serwer dostanie nasze dane gdy np. tworzymy nowego użytkownika to zakładając, że są one zaszyfrowane przez SSL to jak to się dzieje(o ile się dzieje), że z poziomu kodu serwer "nie widzi", np. przy debugu, faktycznych, nie zaszyfrowanych, haseł użytkownika i w sposób bezpieczny zapisuje je do bazy już zaszyfrowane?

#programowanie #https #ssl #security #informatyka

[uzytkownik_wykop_pl]

@lifapek: Zaszyfrowana jest cała komunikacja między twoją przeglądarką a serwerem. Serwer posiada klucz dzieki któremu może sobie odszyfrować wiadomość i przekazać dalej, np. do API. Trochę uproszczone, ale tak mniej więcej działa.

[y.....l]

@lifapek:
1. Jeżeli masz https to szyfrowany jest cały ruch, także headery przy każdym requeście.
2. Request jest rozszyfrowany jak dochodzi do miejsca gdzie jest terminacja SSL (np. w serwerze www). Potem jest już rozszyfrowany, więc jeżeli logujesz przesyłane hasło to jest ono zapisywane w logach. Hasła nie są zapisywane do bazy (tzn. nie powinny być, ale nie masz pewności, zawsze używaj różnych haseł do różnych serwisów).

[fiolkins]

@lifapek: Kwestia bezpieczeństwa i tego czy ktoś to widzi czy nie to warstwa aplikacji. Nie da się zrobić w pełni bezpiecznego systemu. Zabezpieczenie które wymyślił człowiek, inny człowiek potrafi złamać. Powinno się minimalizować wszystkie ryzyka z tym związane i tyle. W javie naprzyklad dane wrażliwe nie powinny być przechowywane w Stringu tylko w char[]. Ale to temat na ktory mozna pisac doktoraty

[plusujemny]

@lifapek: wszystko co idzie po TLS jest szyfrowane, wiec cały request tez jest szyfrowany w całości (z headerami) za każdym razem. Sama aplikacja do której uderzasz widzi wszystko tak jak wyglądało przed TLSem (upraszczam mocno bo możliwe że proxy po drodze coś dorzucą bądź dodadzą).
Serwer widzi hasła użytkownika bez szyfrowania, ale przechowywuje je najczęściej zahashowane (nie mylić z szyfrowaniem) - serwer nie porównuje przysłanego hasła bezpośrednio z tym w bazie,

[Saly]

2. Gdy serwer dostanie nasze dane gdy np. tworzymy nowego użytkownika to zakładając, że są one zaszyfrowane przez SSL to jak to się dzieje(o ile się dzieje), że z poziomu kodu serwer "nie widzi", np. przy debugu, faktycznych, nie zaszyfrowanych, haseł użytkownika i w sposób bezpieczny zapisuje je do bazy już zaszyfrowane?

@lifapek: widzi, po prostu trzeba projektować system tak, żeby nie dało się nic zobaczyć np. jak logujesz requesty zawierające

[lifapek]

@yggdrasil: @Saly: Chodzi mi o to, że przy szyfrowaniu SSL jak te dane wejdą na serwer to jak sprawić, żeby bez nie można było tego debugiem odczytać? java dev here

[y.....l]

@lifapek: To nie zapisuj do logów po prostu.

[fiolkins]

@lifapek: No napisałem Ci. Używaj char[] zamiast string. Zeruj tablice po użyciu, nigdy nie trzymaj tego nie zaszyfrowanego w pamięci a klucz szyfrowania trzymaj w zewnętrznym KMI i jeszcze milion innych rzeczy. O logach nawet nie pisze bo to oczywista oczywistość

[fiolkins]

@lifapek: https://docs.oracle.com/en/middleware/idm/identity-governance/12.2.1.3/omicf/org/identityconnectors/common/security/GuardedString.html tutaj przykład takiej klasy