Hasło w postaci zwykłego tekstu przez HTTPS

93

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?

WhyNotHugo
źródło

Odpowiedzi:

129

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.

Eduardo Scoz
źródło
20
Drobny chwytak: niektóre formularze logowania używają JavaScript do skrótu hasła zamiast wysyłać je w postaci zwykłego tekstu.
Thorarin
5
@Thorarin, jeśli naprawdę to haszuje, oznacza to, że serwer przechowuje hasło w postaci zwykłego tekstu, aby mógł haszować z tą samą solą do weryfikacji. Ick! Wysłanie hasła w postaci zawiniętej w protokół SSL jest lepsze, ponieważ serwer nie musi wtedy przechowywać hasła w postaci zwykłego tekstu.
DGM
11
@DGM: podwójne haszowanie jest również opcją, więc hasła w postaci zwykłego tekstu nie są bezwzględnie konieczne.
Thorarin
3
@Denis: haszowanie po stronie klienta tak naprawdę nie pomaga. Może to sprawić, że rzeczy są nieco trudniejsze niż zwykły tekst, ale ktoś, kto naprawdę chce ukraść hasło, może to zrobić bez problemów. Bezpiecznie zadziała tylko wtedy, gdy wyślesz przynajmniej jednorazowy token przez bezpieczny kanał (ssl), w takim przypadku równie dobrze możesz po prostu wysłać hasło w SSL, aby rozpocząć.
Eduardo Scoz
4
Mówię tylko, że Yahoo uważało, że haszowanie po stronie klienta było wystarczająco bezpieczne, dopóki nie było ich stać na przejście aż do SSL. Ale hej, jestem za https :)
Denis
74

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.

nikt
źródło
7
Tak, wiedziałem o tym, ale nadal jest to dobry komentarz dla innych, którzy tu szukają. :)
WhyNotHugo
lub wyślij w nagłówku
james
22

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.

Czy Berk Güder
źródło
4
Jednak serwer nie ma dostępu do hasła zwykłego tekstu, można je przechowywać go w postaci zwykłego tekstu, należy zalogować się niepoprawnie jako zwykłego tekstu itd. To znaczy, hasła nie pozostaje po stronie klienta, serwer również widzi dokładnie co to jest.
odnośnik z
14

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ć.

CodeDog
źródło
6
Twój komentarz ze stołówki nie ma żadnego sensu, bez względu na to, jak często go ponownie przeczytałem. Dlaczego ludzie mieliby po prostu podchodzić do komputera i wpisywać swoje dane uwierzytelniające? Co próbujesz udowodnić? Ponadto haszowanie w żaden sposób nie sprawi, że będzie to bardziej niebezpieczne.
Haszowanie
4
Głosowałem za obydwoma, ponieważ tak, przyjęta odpowiedź jest czytana wiele lat później. Byłoby dobrze, gdyby @CodeDog wskazał na jakąś strategię łagodzenia skutków. I tak, ludzie po prostu podchodzą do przypadkowych komputerów, na przykład w lokalnej bibliotece, i wprowadzają swoje dane!
JoeAC
3
Szyfruję hasła po stronie klienta kluczem publicznym, a następnie umieszczam tylko zaszyfrowane hasło w formularzu. Jest to klucz asymetryczny, więc posiadanie klucza publicznego po stronie klienta jest bezużyteczne dla atakujących. Każdy dziennik generuje nową parę kluczy, więc ataki typu Replay również nie będą działać. Klucz zmienia się nawet przy nieudanych próbach logowania. Pary kluczy są generowane po stronie serwera, gdy użytkownicy pojawiają się na ekranie logowania. Tylko klucz publiczny jest dostarczany do kodu po stronie klienta.
CodeDog,
Przy okazji widziałem, jak ten hack był używany w hotelowym centrum biznesowym przez pracowników w celu zbierania kodów dostępu do numerów pokoi. Użyliby hasła, aby połączyć się z siecią bezprzewodową i korzystać z komputerów w centrum biznesowym, a opłata byłaby naliczana w pokoju.
CodeDog,
Przeprowadziłem taki eksperyment samodzielnie, logując się na swoje konto bankowe i muszę zgodzić się z @CodeDog - Żądanie ładunku zawiera mój login i hasło w postaci zwykłego tekstu.
Artur Michajluk
6

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ę.

Lucca Ferri
źródło
Należy pamiętać, że ta dyskusja pochodzi z 2009 roku. W tamtym czasie były to właściwie najlepsze praktyki.
WhyNotHugo
3
@WhyNotHugo Jestem świadomy. Postanowiłem zostawić odpowiedź, ponieważ najlepsza odpowiedź google na to pytanie doprowadziła mnie tutaj, więc dlaczego nie.
Lucca Ferri
4

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 ...

Grossvogel
źródło
Tak, zdaję sobie z tego sprawę, dziękuję, miałem na myśli tylko przekaz.
WhyNotHugo
0

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.

ramakarl
źródło
1
Podczas gdy robisz dobre punkty, odpowiadasz na odpowiedź (która sama w sobie nie jest tak naprawdę istotna dla zadanego pytania), więc nie jest odpowiednia dla modelu pytań i odpowiedzi Stackoverflow.
Martin