Jak bezpiecznie wysłać hasło przez HTTP?

Jeśli na ekranie logowania użytkownik przesyła formularz ze swoją nazwą użytkownika i hasłem, hasło jest wysyłane zwykłym tekstem (nawet z POST, popraw mnie, jeśli się mylę).

Zatem pytanie brzmi: jaki jest właściwy sposób ochrony użytkownika i jego hasła przed osobami trzecimi, które mogą podsłuchiwać dane komunikacyjne?

Zdaję sobie sprawę, że HTTPS rozwiązuje problem, ale czy istnieje sposób na zapewnienie przynajmniej pewnego poziomu bezpieczeństwa przy użyciu standardowego protokołu HTTP (żądanie POST)? (być może używając w jakiś sposób javascript)

EDYTUJ Mogłem pominąć kilka ważnych rzeczy.

Miałem na myśli stronę - czyli stronę logowania wygenerowaną w PHP, która jest oczywiście wysyłana do użytkownika w żądaniu HTTP GET jako plik HTML. Nie ma połączenia (@Jeremy Powel) między serwerem a klientem, więc nie mogę utworzyć takiego protokołu uzgadniania. I chcę, aby cały proces był przejrzysty dla użytkownika - chce podać hasło, a nie zajmować się kryptografią.

Dzięki.

Korzystanie z protokołu HTTP z SSL znacznie ułatwi Ci życie i możesz spać spokojnie. Bardzo mądrzy ludzie (przynajmniej mądrzejsi ode mnie!) Od lat badają tę metodę poufnej komunikacji.

Bezpieczne uwierzytelnianie to szeroki temat. Krótko mówiąc, jak wspomniał @ jeremy-powell, zawsze preferuj wysyłanie danych uwierzytelniających przez HTTPS zamiast HTTP. Zabierze to wiele bólów głowy związanych z bezpieczeństwem.

Certyfikaty TSL / SSL są obecnie dość tanie. W rzeczywistości, jeśli w ogóle nie chcesz wydawać pieniędzy, istnieje darmowy letsencrypt.org - automatyczny urząd certyfikacji.

Możesz pójść o krok dalej i skorzystać z witryny caddyserver.com, która w tle wywołuje letencrypt.

Teraz, gdy już usunęliśmy HTTPS ...

Nie należy przesyłać loginu i hasła przez ładunek POST lub parametry GET. Zamiast tego użyj nagłówka autoryzacji (schemat uwierzytelniania dostępu podstawowego), który jest zbudowany w następujący sposób:

• Nazwa użytkownika i hasło są łączone w ciąg oddzielony dwukropkiem, np .: nazwa użytkownika: hasło
• Wynikowy ciąg jest kodowany przy użyciu wariantu RFC2045-MIME Base64, ale nie jest ograniczony do 76 znaków / wiersz.
• Metoda autoryzacji i spacja, np. „Basic”, są następnie umieszczane przed zakodowanym ciągiem.

źródło: Wikipedia: nagłówek autoryzacji

Może się to wydawać nieco skomplikowane, ale tak nie jest. Istnieje wiele dobrych bibliotek, które zapewniają tę funkcjonalność zaraz po wyjęciu z pudełka.

Istnieje kilka dobrych powodów, dla których warto użyć nagłówka Authorization

1. To jest standard
2. To proste (po nauczeniu się ich obsługi)
3. Pozwoli ci to zalogować się na poziomie adresu URL, na przykład: https://user:[email protected]/login(Chrome, na przykład, automatycznie przekonwertuje go na Authorizationnagłówek)

WAŻNE:
Jak zauważył @zaph w swoim komentarzu poniżej, wysyłanie poufnych informacji jako zapytania GET nie jest dobrym pomysłem, ponieważ najprawdopodobniej trafią one do dzienników serwera.

Możesz użyć schematu odpowiedzi na wyzwanie. Powiedz, że klient i serwer znają sekret S. Następnie serwer może mieć pewność, że klient zna hasło (bez podawania go) przez:

1. Serwer wysyła losową liczbę R do klienta.
2. Klient wysyła H (R, S) z powrotem do serwera (gdzie H to kryptograficzna funkcja skrótu, taka jak SHA-256)
3. Serwer oblicza H (R, S) i porównuje to z odpowiedzią klienta. Jeśli są zgodne, serwer wie, że klient zna hasło.

Edytować:

Występuje tu problem ze świeżością języka R i faktem, że protokół HTTP jest bezstanowy. Można temu zaradzić, każąc serwerowi utworzyć sekret, nazwij go Q, który zna tylko serwer . Następnie protokół wygląda tak:

Należy zauważyć, że ponieważ H (R, Q) nie może zostać sfałszowane przez klienta, H (R, Q) działa jako plik cookie (i dlatego może być faktycznie zaimplementowane jako plik cookie).

Kolejna edycja:

Poprzednia edycja protokołu jest nieprawidłowa, ponieważ każdy, kto obserwował H (R, Q), wydaje się być w stanie odtworzyć ją z poprawnym hashem. Serwer musi pamiętać, które R nie są już świeże. Dążę do tej odpowiedzi, więc możecie to zmienić i wypracować coś dobrego.

Jeśli Twój host na to pozwala lub będziesz musiał radzić sobie z poufnymi danymi, użyj HTTPS, kropka. (Często jest to wymagane przez prawo).

W przeciwnym razie, jeśli chcesz zrobić coś przez HTTP. Zrobiłbym coś takiego.

1. Serwer osadza swój klucz publiczny na stronie logowania.
2. Klient wypełnia formularz logowania i klika Prześlij.
3. Żądanie AJAX pobiera aktualny znacznik czasu z serwera.
4. Skrypt po stronie klienta łączy poświadczenia, znacznik czasu i sól (zaszyfrowaną z danych analogowych, np. Ruchy myszy, zdarzenia związane z naciśnięciem klawisza), szyfruje je przy użyciu klucza publicznego.
5. Przesyła wynikowy skrót.
6. Serwer odszyfrowuje skrót
7. Sprawdza, czy sygnatura czasowa jest wystarczająco aktualna (zezwala tylko na krótkie 5-10 sekundowe okno). Odrzuca logowanie, jeśli sygnatura czasowa jest zbyt stara.
8. Przechowuje hash przez 20 sekund. Odrzuca ten sam skrót do logowania w tym okresie.
9. Uwierzytelnia użytkownika.

W ten sposób hasło jest chronione i ten sam skrót uwierzytelniania nie może zostać odtworzony.

O bezpieczeństwie tokena sesji. To trochę trudniejsze. Możliwe jest jednak nieco utrudnienie ponownego wykorzystania skradzionego tokena sesji.

1. Serwer ustawia dodatkowy plik cookie sesji, który zawiera losowy ciąg.
2. Przeglądarka odsyła ten plik cookie przy następnym żądaniu.
3. Serwer sprawdza wartość w pliku cookie, jeśli jest inna, niszczy sesję, w przeciwnym razie wszystko jest w porządku.
4. Serwer ponownie ustawia plik cookie z innym tekstem.

Jeśli więc token sesji zostanie skradziony, a żądanie zostanie wysłane przez kogoś innego, to przy następnym żądaniu pierwotnego użytkownika sesja zostanie zniszczona. Jeśli więc użytkownik aktywnie przegląda witrynę, często klikając w linki, to złodziej nie zajdzie daleko ze skradzionym tokenem. Ten schemat można wzmocnić, wymagając innego uwierzytelnienia dla wrażliwych operacji (takich jak usunięcie konta).

EDYCJA: Należy pamiętać, że nie zapobiega to atakom MITM, jeśli osoba atakująca utworzy własną stronę z innym kluczem publicznym i żądaniami serwerów proxy do serwera. Aby się przed tym zabezpieczyć, klucz publiczny musi być przypięty do lokalnej pamięci przeglądarki lub w aplikacji, aby wykryć tego rodzaju sztuczki.

O implementacji: RSA jest prawdopodobnie najbardziej znanym algorytmem, ale jest dość powolny dla długich kluczy. Nie wiem, jak szybka byłaby implementacja PHP lub Javascript. Ale prawdopodobnie istnieją szybsze algorytmy.

Użyłbym systemu wymiany kluczy Diffie-Hellman po stronie serwera i klienta z AJAX lub wieloma przesyłaniami formularzy (polecam ten pierwszy), chociaż nie widzę żadnych dobrych implementacji w Internecie. Pamiętaj, że biblioteka JS zawsze może zostać uszkodzona lub zmieniona przez MITM. W pewnym stopniu można skorzystać z pamięci lokalnej, aby temu zaradzić.

Możesz użyć SRP, aby używać bezpiecznych haseł na niezabezpieczonym kanale. Zaletą jest to, że nawet jeśli atakujący podsłuchuje ruch lub włamie się do serwera, nie może użyć haseł na innym serwerze. https://github.com/alax/jsrp to biblioteka javascript obsługująca bezpieczne hasła przez HTTP w przeglądarce lub po stronie serwera (przez węzeł).

HTTPS jest tak potężny, ponieważ wykorzystuje kryptografię asymetryczną. Ten rodzaj kryptografii pozwala nie tylko stworzyć zaszyfrowany tunel, ale także zweryfikować, czy rozmawiasz z właściwą osobą, a nie z hakerem.

Oto kod źródłowy Java, który wykorzystuje asymetryczny szyfr RSA (używany przez PGP) do komunikacji: http://www.hushmail.com/services/downloads/

możesz użyć ssl dla swojego hosta istnieje darmowy projekt dla ssl, taki jak letsencrypt https://letsencrypt.org/

Korzystanie z protokołu HTTPS brzmi tutaj najlepiej (certyfikaty nie są obecnie takie drogie). Jeśli jednak wymagany jest http, możesz użyć szyfrowania - zaszyfrować go po stronie serwera i odszyfrować w przeglądarce użytkownika (wyślij klucz osobno).

Wykorzystaliśmy to przy implementacji safevia.net - kodowanie odbywa się po stronie klienta (nadawcy / odbiorcy), więc dane użytkowników nie są dostępne w warstwie sieciowej ani serwerowej.