Zwykły tekst hasło przez HTTPS

Nadal musisz się upewnić, że wysyłasz go za pośrednictwem POST request, a nie GET. Jeśli wyślesz go za pośrednictwem żądania GET, może on zostać zapisany w postaci zwykłego tekstu w logach historii przeglądarki użytkownika lub logach dostępu serwera www.

Jeśli HTTP jest wyłączony, a Ty tylko używasz HTTPS, to tak naprawdę nie przekazujesz hasła jako zwykłego tekstu.

Hash po stronie klienta. Dlaczego? Pozwól, że opowiem ci o małym eksperymencie. Podejdź do komputera w firmowej stołówce. Otwórz przeglądarkę na stronę logowania do firmowej witryny internetowej (https). Wciśnij F12, kliknij zakładkę Sieć, zaznacz opcję persist log, Minimalizuj konsolę, ale pozostaw stronę otwartą na stronę logowania. Usiądź i zjedz lunch. Obserwuj, jak pracownik po pracowniku loguje się na stronie internetowej firmy i jest dobrym małym pracownikiem wylogowuje się po zakończeniu. Zakończ lunch, usiądź przy komputerze, otwórz kartę Sieć i zobacz wszystkie nazwa użytkownika i hasło w postaci zwykłego tekstu.

Żadnych specjalnych narzędzi, żadnej specjalnej wiedzy, żadnego wymyślnego sprzętu hakerskiego, żadnych keyloggerów tylko stary dobry F12.

Ale hej, myśl dalej, wszystko czego potrzebujesz to SSL. Źli cię za to pokochają.

Pozostałe plakaty są poprawne. Teraz, gdy używasz SSL do szyfrowania transmisji hasła, upewnij się, że hashujesz je za pomocą dobrego algorytmu i soli, aby było chronione, gdy jest w spoczynku...

Zróbmy notatki do poprzednich odpowiedzi.

Po pierwsze, prawdopodobnie nie jest to najlepszy pomysł, aby używać algorytmów hashowych po stronie klienta. Jeśli Twoje hasło jest zasolone po stronie serwera, nie będziesz mógł porównać hashów(przynajmniej nie, jeśli nie przechowasz hasha klienta w bazie danych w jednej z warstw hashujących z hasła, które jest takie samo lub gorsze). I nie chcesz zaimplementować algorytmu haszującego używanego przez bazę danych po stronie Klienta, byłoby to głupie.

Drugi, Wymiana kluczy kryptograficznych też nie jest idealna. MITM może teoretycznie (biorąc pod uwagę, że ma zainstalowany na kliencie root cert) zmienić klucze kryptograficzne i zmienić za pomocą własnych kluczy:

Oryginalne połączenie (nie biorąc pod uwagę tls) z teoretycznego serwera, który wymienia klucze:

Żądanie klienta klucze publiczne > serwer przechowuje klucze prywatne, generuje klucze publiczne do klienta > serwer wysyła klucze publiczne do Klienta

Teraz, w teoretycznym MITM atrack:

Żądanie klienta klucze publiczne > MITM generuje fałszywe klucze prywatne > Serwer przechowuje klucze prywatne, generuje klucze publiczne do klienta > MITM odbiera klucze publiczne z oryginalnego serwera, teraz możemy wysłać nasze fałszywe klucze publiczne do klienta, a za każdym razem, gdy żądanie pochodzi od klienta, odszyfrowujemy dane Klienta za pomocą fałszywych kluczy, zmieniamy ładunek (lub odczytujemy go) i szyfrujemy za pomocą oryginalnych kluczy publicznych > MITM wysyła fałszywe klucze publiczne do klienta. klient.

To jest sens posiadania zaufanego certyfikatu CA w TLS i w ten sposób otrzymujesz komunikat z Ostrzeżenia przeglądarki, jeśli certyfikat nie jest ważny.

W odpowiedzi na OP: moim skromnym zdaniem nie można tego zrobić, bo prędzej czy później ktoś będzie chciał zaatakować użytkownika z twojego serwisu i będzie próbował złamać twój protokół.

Możesz jednak zaimplementować 2FA, aby zapobiec próbom logowania się przy użyciu tego samego hasła. Beaware of jednak ataki typu replay.

Nie jestem dobry w kryptografii, Proszę mnie poprawić, jeśli się mylę.