Niniejszym piszę, że wiem jak działa SSL, wiem po co jest, wiem co zapewnia i wiem, że jest do podsłuchania/obejścia po jednej ze stron łącza (właściwie po obu, ale łatwiej po stronie użytkownika).
Dane, przed wysłaniem i po odebraniu, są w postaci niezaszyfrowanej, więc nie ma za bardzo sensu ich podsłuchiwania - wystarczy po nie sięgnąć. Przed tym procederem powinien chronić antywirus, którego skuteczność nie jest przedmiotem tej dyskusji.
Ponadto klucze były upraszczane swego czasu, niektóre metody szyfrowania zostały zaklasyfikowane jako niebezpieczne, i zalecono używać krótszych, "bezpieczniejszych" kluczy.
Tak, osłabiono algorytm A5/1 stosowany w sieciach GSM na potrzeby eksportowe USA do krajów z ograniczeniami importowania produktów z funkcjami szyfrowania. Najpopularniejsze algorytmy szyfrowania symetrycznego używają kluczy: 56-bitowych (DES), 112 (3DES), 128/256 (AES), więc długość klucza jest wydłużana. W przypadku szyfrowania asymetrycznego początkowo stosowano klucze 768-bitowe, ale od wielu lat zaleca się stosowanie 2048-bitowych i dłuższych.
Więc _domyślam się_ że podsłuch może się odbywać również na pośredniczących routerach; a na pewno logowanie i później ew. deszyfracja offline wybranych pakietów.
Może i nazywa się Man In The Middle, z tym że próba podsłuchiwania wymaga podmiany certyfikatów wykorzystywanych do ustalenia klucza symetrycznego, co kończy się informacją o błędnym certyfikacie serwera. Zebranie danych zaszyfrowanych, aby rozszyfrować je off-line mija się z celem, ze względu na czas potrzebny do tej czynności.
A co ma JS? ano to, że serwer wysyła określony kod szyfrujący
Musisz mieć możliwość zweryfikowania, czy otrzymany "kod szyfrujący" pochodzi z właściwego źródła. Do tego służą certyfikaty. Inaczej zły człowiek przechwyci transmisję, w miejsce "kodu szyfrującego" serwera wstawi własny i prześle do klienta. Dalej mamy klasyczne MITM.
jedno hasło może wygenerować różne hasze (+ jakaś sól) a samo hasło może pasować do różnych haszy (kolizja).
Odwrotnie, to samo hasło zawsze da ten sam hash. Dopiero dodawanie losowej soli do hasła daje różne hashe. Kolizja jest wtedy, gdy dwie różne dane dają ten sam skrót.
Jedyną właściwą drogą jest na serwerze sprawdzenie zgodności hasła do hasza. Porównanie hasza do hasza jest nieprawidłową i skrajnie niebezpieczną praktyką. Tak się nie robi.
Jak chcesz "hasło" porównać z "610881de40fac65b12445aef6c603234" (MD5 tylko dla przykładu)? :-) Trzymanie haseł w postaci jawnej jest skrajnie nieodpowiedzialne. Przechowuje się hashe i ew. sól. Podczas uwierzytelniania do przesłanego hasła dodawana jest sól, z tego obliczany jest skrót i dopiero to jest sprawdzane.
Wystarczy na koncie hostingowym kliknąć "włącz SSL" i wygenerować sobie darmowy certyfikat Let's Encrypt. Całość nie powinna przekroczyć 3 minut.
Certyfikaty Let's Encrypt ważne są trzy miesiące i dobrze jest mieć narzędzie do automatycznego odnawiania. Poza tym na hoscie trzeba mieć możliwość włączenia szyfrowania spełniającego współczesne wymogi. :-p