Przede wszystkim spróbuj zrozumieć, jak działa uwierzytelnianie SSL (HTTPS) i HTTP.
Zwykłe metody uwierzytelniania HTTP (Digest, Basic i wszelkie formularze + schemat uwierzytelniania oparty na plikach cookie, które można wdrożyć na HTTP) same w sobie są niepewne, ponieważ wysyłają informacje uwierzytelniające mniej więcej w postaci czystego tekstu. Niezależnie od tego, czy dane znajdują się w polach POST, czy w nagłówkach i czy zastosowano kodowanie base64, nie ma w tym względzie żadnego znaczenia, hasło jest wyraźnie widoczne dla każdego, kto ma dostęp do ruchu sieciowego. Oznacza to, że uwierzytelnianie HTTP w niezaufanym kanale jest bezwartościowe: atakujący musi odczytać hasło tylko po to, by wąchać sieć.
SSL implementuje bezpieczny kanał komunikacyjny poprzez z natury niepewny kanał. Działa to mniej więcej tak:
- Serwer wysyła podpisany certyfikat
- Klient sprawdza poprawność certyfikatu na podstawie listy dobrze znanych kluczy podpisujących; podpisy certyfikatów można łączyć w łańcuchy, tak aby każdy węzeł powiedział „jeśli podpis, który mnie podpisuje, jest dobry, to ja też”, ale ostatecznie łańcuch musi zostać rozwiązany do jednej z garstki zaufanych organów wstępnie skonfigurowanych na kliencie.
- Klient używa publicznego klucza szyfrowania serwera, aby wysłać wspólny klucz tajny
- Serwer odszyfrowuje udostępniony klucz tajny za pomocą klucza prywatnego (ponieważ tylko prawidłowy serwer ma klucz prywatny, inne serwery nie będą w stanie odszyfrować wspólnego klucza)
- Klient wysyła rzeczywiste dane żądania, zaszyfrowane przy użyciu wspólnego hasła
- Serwer odszyfrowuje dane żądania, a następnie wysyła zaszyfrowaną odpowiedź
- Klient odszyfrowuje odpowiedź i przedstawia ją użytkownikowi.
Zwróć uwagę na kilka ważnych punktów tutaj:
- Łańcuch certyfikatów pozwala klientom upewnić się, że serwer, z którym rozmawia, jest prawdziwy, a nie ktoś przechwytuje ich żądania. Dlatego powinieneś kupić prawdziwy certyfikat SSL i dlaczego przeglądarki rzucają ci przerażające ostrzeżenia, gdy trafisz na stronę, która używa nieprawidłowego, wygasłego lub w inny sposób niepoprawnego certyfikatu: całe szyfrowanie na świecie nie pomaga, jeśli jesteś rozmowa z niewłaściwą osobą.
- Szyfrowanie publiczne / prywatne używane do wymiany tajnego klucza zapewnia, że pomyślna komunikacja będzie działać tylko między tą konkretną parą klienta i serwera: sniffowane pakiety sieciowe zostaną zaszyfrowane i będą wymagały prywatnego klucza serwera, aby uzyskać dostęp do danych.
- Szyfrowanie symetryczne jest stosowane w przypadku większości żądań, ponieważ ma znacznie niższy narzut wydajnościowy niż szyfrowanie kluczem prywatnym / publicznym. Klucz (wspólny klucz tajny) jest jednak wymieniany przy użyciu szyfrowania klucza prywatnego / publicznego, ponieważ jest to jedyny sposób, aby to zrobić w bezpieczny sposób (z wyjątkiem przeniesienia go osobnym kanałem, takim jak usługa kurierska).
Oczywiście wiąże się to z pewnymi kosztami ogólnymi, ale nie jest tak źle, jak mogłoby się wydawać - głównie w skali, w której „rzuć na to więcej sprzętu” jest odpowiednią reakcją, chyba że przygotowujesz się na absolutnie ogromne natężenie ruchu ( pomyśl Google lub Facebook). W normalnych okolicznościach, to jest w typowym użyciu aplikacji internetowych, narzut SSL jest znikomy, w związku z czym, gdy tylko masz jakiekolwiek poufne dane, najlepiej po prostu uruchomić wszystko przez SSL, w tym zasoby. SSL to także jedyny możliwy sposób zabezpieczenia ruchu HTTP; inne metody po prostu nie są tak ujednolicone i dlatego nie są szeroko wspierane, i absolutnie nie chcesz wdrażać tych rzeczy samodzielnie, ponieważ szczerze mówiąc, po prostu zbyt łatwo jest je pomylić.
TL; DR: Tak, uwierzytelnianie podstawowe SSL + jest dobrym pomysłem, tak, potrzebujesz bezpiecznego serwera (i ważnego certyfikatu ), tak, to trochę spowolni, ale nie, nie należy się tym martwić teraz.