Obecnie pracuję nad dostawcą PHP OpenID, który będzie działał przez HTTPS (stąd szyfrowanie SSL).
Czy przekazywanie hasła w postaci zwykłego tekstu jest złe ? HTTPS w teorii nie może zostać przechwycony, więc nie widzę nic złego. A może jest to niebezpieczne na jakimś poziomie i nie widzę tego?
Odpowiedzi:
To jest bezpieczne. Tak działa cała sieć. Wszystkie hasła w formularzach są zawsze wysyłane w postaci zwykłego tekstu, więc ich zabezpieczenie należy do protokołu HTTPS.
Nadal musisz upewnić się, że wyślesz go za pomocą żądania POST, a nie GET. Jeśli wyślesz go za pomocą żądania GET, może zostać zapisany w postaci zwykłego tekstu w dziennikach historii przeglądarki użytkownika lub dziennikach dostępu do serwera internetowego.
Jeśli protokół HTTP jest wyłączony i używasz tylko protokołu HTTPS, to i tak tak naprawdę nie przesyłasz hasła jako zwykłego tekstu.
Hash po stronie klienta. Czemu? Opowiem o małym eksperymencie. Podejdź do komputera w firmowej stołówce. Otwórz przeglądarkę na stronie logowania do witryny internetowej firmy (https). Naciśnij F12, kliknij kartę sieci, odznacz dziennik utrwalania, zminimalizuj konsolę, ale pozostaw otwartą stronę internetową na stronie logowania. Usiądź i zjedz obiad. Obserwuj, jak pracownik za pracownikiem loguje się do witryny internetowej firmy, a bycie dobrym małym pracownikiem wylogowuje się po zakończeniu. Skończ obiad, usiądź przy komputerze, otwórz kartę sieci i zobacz każdą nazwę użytkownika i hasło w postaci zwykłego tekstu w formularzu.
Żadnych specjalnych narzędzi, żadnej specjalnej wiedzy, żadnego wyszukanego sprzętu do hakowania, żadnych keyloggerów, tylko stary, dobry F12.
Ale hej, myśl, że wszystko, czego potrzebujesz, to SSL. Źli będą cię za to kochać.
Zróbmy notatki do poprzednich odpowiedzi.
Po pierwsze, prawdopodobnie nie jest najlepszym pomysłem używanie algorytmów mieszania po stronie klienta. Jeśli twoje hasło jest solone po stronie serwera, nie będziesz mógł porównać hashów (przynajmniej nie, jeśli nie przechowujesz hasha klienta w bazie danych w jednej z warstw haszujących z hasła, które jest takie samo lub gorzej). I nie chcesz implementować algorytmu haszującego używanego przez bazę danych po stronie klienta, byłoby głupie.
Po drugie, handel kluczami kryptograficznymi też nie jest idealny. MITM mógłby teoretycznie (biorąc pod uwagę, że ma zainstalowany certyfikat główny na kliencie) zmienić klucze kryptograficzne i zmienić je własnymi kluczami:
Oryginalne połączenie (nie biorąc pod uwagę tls) z teoretycznego serwera, który wymienia klucze:
Klucze publiczne żądań klienta> serwer przechowuje klucze prywatne, generuje klucze publiczne dla klienta> serwer wysyła klucze publiczne do klienta
Teraz w teoretycznym atracie MITM:
Klucze publiczne żądań klienta> MITM generuje fałszywe klucze prywatne > Serwer przechowuje klucze prywatne, generuje klucze publiczne dla klienta> MITM otrzymuje klucze publiczne z oryginalnego serwera, teraz możemy wysłać nasze fałszywe klucze publiczne do klienta i ilekroć żądanie przychodzi od klienta, odszyfrujemy dane klienta fałszywymi kluczami, zmienimy ładunek (lub przeczytamy go) i zaszyfrujemy oryginalnymi kluczami publicznymi > MITM wysyła fałszywe klucze publiczne do klienta.
O to właśnie chodzi w posiadaniu zaufanego certyfikatu CA w TLS i tak otrzymujesz komunikat z przeglądarki z ostrzeżeniem, jeśli certyfikat nie jest ważny.
W odpowiedzi na OP: moim skromnym zdaniem nie możesz tego zrobić, bo wcześniej 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. Uważaj jednak na ataki powtórkowe.
Nie jestem świetny w kryptografii, popraw mnie, jeśli się mylę.
Pozostałe plakaty są poprawne. Teraz, gdy używasz SSL do szyfrowania transmisji hasła, upewnij się, że haszujesz je dobrym algorytmem i solą, aby było chronione również w stanie spoczynku ...
Przykład @CodeDog zawiera problemy.
Tak, wierzę, że użytkownicy będą logować się do skrzynki w kafeterii. Jeśli przechwytujesz logi z korporacyjnej kafeterii, to ty naruszeniem bezpieczeństwa. Firmowe kafeterie powinny być ustawione wyłączone, np. Bez terminów, bez rejestratorów, bez zdalnego dostępu itp. Aby zapobiec tobie, wewnętrznemu hakerowi.
Dobry przykład dotyczy bezpieczeństwa dostępu do komputera i nie jest tak naprawdę związany z bezpieczeństwem sieci. Jest to uzasadnienie dla haszowania po stronie klienta, ale jeśli masz dostęp do komputera, możesz po prostu użyć rejestratora naciśnięć klawiszy i ominąć to. Skrót po stronie klienta jest znowu nieistotny. Przykład @CodeDog to włamanie do komputera i wymaga technik innych niż hacki warstwy sieci.
Ponadto włamanie do komputera publicznego jest chronione przez uszkodzenie systemu przed zagrożeniami, jak wspomniano powyżej. np. użyj Chromebooka jako komputera w publicznej kawiarni. Ale to jest pomijane przez fizyczne hack. Poza godzinami pracy idź do kafeterii i skonfiguruj tajną kamerę, aby nagrywać naciśnięcia klawiszy przez użytkowników. Wtedy nie ma znaczenia, czy komputer w kafeterii jest uszkodzony, LUB jaki typ szyfrowania jest używany.
warstwa fizyczna -> warstwa komputera -> warstwa klienta -> warstwa sieciowa -> warstwa serwera
W przypadku sieci nie ma znaczenia, czy hashujesz po stronie klienta, ponieważ warstwa https / ssl zaszyfruje zwykłe hasło. Tak więc, jak wspominają inni, mieszanie klienta jest zbędne, jeśli protokół TLS jest bezpieczny.