Czy powinienem zaszyfrować hasło przed wysłaniem go na serwer?

Zauważyłem, że większość witryn wysyła hasła w postaci zwykłego tekstu przez HTTPS do serwera. Czy jest jakaś korzyść, jeśli zamiast tego wyślę skrót hasła na serwer? Czy byłoby to bezpieczniejsze?

To stare pytanie, ale poczułem potrzebę wypowiedzenia się w tej ważnej sprawie. Jest tu wiele błędnych informacji

OP nigdy nie wspominał o wysyłaniu hasła czystym hasłem przez HTTP - tylko HTTPS, jednak wielu wydaje się odpowiadać na pytanie o wysłanie hasła przez HTTP z jakiegoś powodu. To mówi:

Uważam, że hasła nigdy nie powinny być przechowywane (nie mówiąc już o przesyłaniu) w postaci zwykłego tekstu. Oznacza to, że nie są przechowywane na dysku ani nawet w pamięci.

Osoby odpowiadające tutaj wydają się myśleć, że HTTPS jest srebrną kulą, a tak nie jest. Z pewnością jednak bardzo pomaga i powinno być używane w każdej uwierzytelnionej sesji.

Naprawdę nie ma potrzeby wiedzieć, jakie jest oryginalne hasło. Wszystko, czego potrzeba, to niezawodny sposób generowania (i niezawodnego ponownego generowania) „klucza” uwierzytelniania na podstawie oryginalnego tekstu wybranego przez użytkownika. W idealnym świecie ten tekst powinien natychmiast wygenerować „klucz” poprzez zaszyfrowanie go przy użyciu nieodwracalnej soli. Ta sól powinna być unikalna dla generowanych poświadczeń użytkownika. Ten „klucz” będzie używany przez systemy jako hasło. W ten sposób, jeśli kiedykolwiek Twoje systemy zostaną naruszone w przyszłości, te dane uwierzytelniające będą przydatne tylko w Twojej organizacji i nigdzie indziej, gdzie użytkownik był leniwy i używał tego samego hasła.

Mamy więc klucz. Teraz musimy wyczyścić wszelkie ślady hasła na urządzeniu klienta.

Następnie musimy dostać ten klucz do twoich systemów. Nigdy nie należy przesyłać klucza ani hasła „jawnie”. Nawet przez HTTPS. HTTPS nie jest nieprzenikniony. W rzeczywistości wiele organizacji może stać się zaufanym MITM - nie z perspektywy ataku, ale do przeprowadzania inspekcji ruchu w celu wdrożenia własnych zasad bezpieczeństwa. Osłabia to protokół HTTPS i nie jest to jedyny sposób, w jaki się to dzieje (na przykład przekierowania do ataków HTTP MITM). Nigdy nie zakładaj, że jest to bezpieczne.

Aby obejść ten problem, haszujemy klucz jednorazowo. Ten numer jednorazowy jest unikalny dla każdego przesłania klucza do Twoich systemów - nawet dla tego samego poświadczenia podczas tej samej sesji, jeśli musisz wysłać go wiele razy. Możesz cofnąć ten numer jednorazowy, gdy dotrze on do Twoich własnych systemów, aby odzyskać klucz uwierzytelniający i uwierzytelnić żądanie.

W tym momencie nieodwracalnie haszowałbym go po raz ostatni, zanim zostanie trwale przechowywany we własnych systemach. W ten sposób możesz udostępniać dane uwierzytelniające organizacjom partnerskim do celów logowania jednokrotnego itp., Jednocześnie będąc w stanie udowodnić, że Twoja organizacja nie może podszyć się pod użytkownika. Najlepsze w tym podejściu jest to, że nigdy nie udostępniasz niczego wygenerowanego przez użytkownika bez jego autoryzacji.

Zrób więcej badań, ponieważ jest w tym więcej, niż ujawniłem, ale jeśli chcesz zapewnić swoim użytkownikom prawdziwe bezpieczeństwo, myślę, że ta metoda jest obecnie najbardziej kompletną odpowiedzią.

TL; DR:

Użyj protokołu HTTPS. Bezpiecznie haszuj hasła, nieodwracalnie, z unikalną solą dla każdego hasła. Zrób to na kliencie - nie przesyłaj jego rzeczywistego hasła. Przesyłanie oryginalnego hasła użytkownika na Twoje serwery nigdy nie jest „OK” ani „W porządku”. Usuń wszelkie ślady oryginalnego hasła. Użyj wartości nonce niezależnie od protokołu HTTP / HTTPS. Jest znacznie bezpieczniejszy na wielu poziomach. (Odpowiedź na OP).

Ponieważ jest to połączenie przez HTTPS, zdecydowanie dobrze jest wysłać hasło bez haszowania (przez HTTPS nie jest to zwykły tekst). Co więcej, jeśli Twoja aplikacja jest zależna od HTTPS, aby zapewnić bezpieczeństwo zawartości, nie ma sensu haszować hasła przed wysłaniem go przez HTTPS (tj. Jeśli atakujący może odszyfrować dane w sieci, i tak masz spieprzone)

Nie, w rzeczywistości byłaby to luka. Jeśli atakujący jest w stanie uzyskać skrót z bazy danych, może go użyć do uwierzytelnienia bez konieczności łamania go. Pod żadnym pozorem użytkownik ani osoba atakująca nie może uzyskać hasła mieszającego.

Cały sens haszowania haseł polega na dodaniu dodatkowej warstwy bezpieczeństwa. Jeśli atakujący jest w stanie uzyskać hash i sól z bazy danych za pomocą SQL Injection lub niezabezpieczonej kopii zapasowej, musi znaleźć zwykły tekst, wymuszając go brutalnie. John The Ripper jest powszechnie używany do łamania zasolonych skrótów haseł.

Nieużywanie protokołu HTTPS stanowi naruszenie OWASP Top 10: A9-Insufficient Transport Layer Protection

EDYCJA: Jeśli w Twojej implementacji obliczasz a, sha256(client_salt+plain_text_password)a następnie obliczasz kolejny skrót po stronie serwera, sha256(server_salt+client_hash)nie jest to poważna luka w zabezpieczeniach. Jednak nadal istnieje możliwość podsłuchania i ponownego odtworzenia żądania. Zatem jest to nadal wyraźne naruszenie WASP A9. Jednak nadal wykorzystuje to skrót wiadomości jako warstwę bezpieczeństwa.

Najbliższą rzeczą, jaką widziałem w zastępstwie https po stronie klienta, jest diffie-hellman w wymianie kluczy w javascript . Jednak zapobiega to aktywnym atakom MITM, a zatem jest technicznym naruszeniem OWASP A9. Autorzy kodu zgadzają się, że nie jest to całkowity zamiennik HTTPS, jednak jest lepszy niż nic i lepszy niż system haszowania po stronie klienta.

Wysłanie skrótu przez kabel całkowicie mija się z celem tego skrótu, ponieważ osoba atakująca może po prostu wysłać hash i zapomnieć o haśle. Krótko mówiąc, system, który uwierzytelnia za pomocą skrótu w czystym tekście, jest szeroko otwarty i może być narażony na szwank jedynie poprzez podsłuchiwanie sieci.

Hasło w postaci zwykłego tekstu nigdy (nawet przy korzystaniu z protokołu HTTPS) nie opuszcza klienta. Powinien zostać nieodwracalnie zaszyfrowany przed opuszczeniem klienta, ponieważ serwer nie musi znać rzeczywistego hasła.

Haszowanie, a następnie przesyłanie rozwiązuje problemy z bezpieczeństwem leniwych użytkowników, którzy używają tego samego hasła w wielu lokalizacjach (wiem, że tak). Jednak nie chroni to twojej aplikacji jako hakera, który uzyskał dostęp do bazy danych (lub w jakikolwiek inny sposób był w stanie zdobyć hash), ponieważ haker może po prostu przesłać hash i pozwolić serwerowi go zaakceptować.

Aby rozwiązać ten problem, możesz oczywiście po prostu zaszyfrować skrót otrzymany przez serwer i wywołać go codziennie.

Moje podejście do problemu w aplikacji internetowej opartej na gniazdach, które tworzę, polega na tym, że po połączeniu z klientem serwer generuje sól (losowy ciąg do dodania przed haszowaniem) i przechowuje go w zmiennej gniazd, a następnie przesyła ten hash do klienta. Klient pobiera hasło użytkownika, haszuje je, dodaje sól z serwera i haszuje całość przed przesłaniem go na serwer. Następnie jest wysyłany do serwera, który porównuje ten hash z hashem (hash w DB + salt). O ile wiem, jest to dobre podejście, ale szczerze mówiąc nie czytałem zbyt wiele na ten temat i jeśli się mylę, chciałbym zostać poprawiony :)

Użyj skrótu HTTP - zabezpiecza hasło nawet przed http (ale najlepszym zastosowaniem byłoby skrót http przez https)

Wikipedia:

Uwierzytelnianie dostępu HTTP jest jedną z uzgodnionych metod, których może używać serwer WWW do negocjowania poświadczeń z użytkownikiem sieci (przy użyciu protokołu HTTP). Uwierzytelnianie szyfrowane ma na celu zastąpienie niezaszyfrowanego użycia uwierzytelniania dostępu podstawowego, umożliwiając bezpieczne ustalenie tożsamości użytkownika bez konieczności wysyłania hasła w postaci zwykłego tekstu przez sieć. Uwierzytelnianie Digest to w zasadzie zastosowanie haszowania kryptograficznego MD5 z wykorzystaniem wartości nonce, aby zapobiec kryptoanalizie.

Link: http://en.wikipedia.org/wiki/Digest_access_authentication

Jeśli chcesz zobaczyć zastosowanie „z prawdziwego życia”, możesz przyjrzeć się phpMyID - dostawcy php openid, który używa uwierzytelniania http digest http://siege.org/phpmyid.php

.. lub możesz zacząć od próbek auth php pod adresem http://php.net/manual/en/features.http-auth.php

Rfc skrótu HTTP: http://www.faqs.org/rfcs/rfc2617

Z moich testów wynika, że ​​wszystkie nowoczesne przeglądarki to obsługują ...

Jeśli chcesz zastąpić hasło w postaci zwykłego tekstu przez HTTPS hasłem zaszyfrowanym przez HTTP, pytasz o kłopoty. HTTPS generuje losowy, wspólny klucz transakcji podczas otwierania kanału komunikacyjnego. Trudno to złamać, ponieważ jesteś prawie ograniczony do brutalnego wymuszania wspólnego klucza używanego do (stosunkowo) krótkoterminowej transakcji. Podczas gdy twój haszysz można po prostu wąchać, zabrać z linii i spojrzeć w tęczowy stół lub po prostu brutalnie wymusić przez długi czas.

Jednak podstawowe zaciemnianie hasła po stronie klienta (nie hash) wysyłane przez HTTPS ma pewną wartość. Jeśli się nie mylę, niektóre banki używają tej techniki. Celem tej techniki nie jest ochrona hasła przed podsłuchiwaniem przez kabel. Raczej ma to na celu powstrzymanie używania hasła przez głupie narzędzia szpiegowskie i wtyczki przeglądarki, które po prostu przechwytują każde żądanie HTTPS GET / POST, które zobaczą. Widziałem plik dziennika przechwycony ze złośliwej witryny, który zawierał 400 MB losowych transakcji GET / POST przechwyconych z sesji użytkowników. Możesz sobie wyobrazić, że strony internetowe, które korzystały tylko z protokołu HTTPS, pojawiałyby się w dzienniku z hasłami w postaci zwykłego tekstu, ale witryny z bardzo podstawowym zaciemnieniem (ROT13) również pojawiałyby się z hasłami, które nie są od razu używane.

Jeśli masz połączenie z serwerem https, strumień danych między serwerem a przeglądarką powinien być zaszyfrowany. Dane są tylko zwykłym tekstem przed wysłaniem i po otrzymaniu. Artykuł w Wikipedii

Zastrzeżenie: jestem ekspertem ds. Bezpieczeństwa - i piszę z nadzieją że inni ocenią moje stanowisko jako zbyt ostrożne lub możliwe do ulepszenia, a ja się z tego wyciągnę. Powiedziawszy to, chcę tylko podkreślić, że haszowanie, gdy opuszcza klienta, nie oznacza, że ​​nie musisz haszować na zapleczu przed umieszczeniem go w bazie danych.

Zrób jedno i drugie

Zrób jedno i drugie, ponieważ:

1. Hashing on the ride over pomaga ukryć luki w zabezpieczeniach transportu, jeśli połączenie SSL jest zagrożone, nadal nie widzą surowego hasła. Nie ma to znaczenia, jeśli chodzi o możliwość podszywania się pod autoryzowanych użytkowników, ale będzie chronić użytkowników przed odczytaniem ich haseł w powiązaniu z ich e-mailami. Większość ludzi nie postępuje zgodnie z najlepszymi praktykami i używa tego samego hasła do wielu swoich kont, więc może to stanowić poważną lukę dla odwiedzających.

2. Jeśli ktoś w jakiś sposób był w stanie odczytać hasła z bazy danych (to się zdarza, myślę, że wstrzyknięcie SQL), nadal nie będzie mógł wykonywać uprzywilejowanych działań podszywających się pod użytkowników za pośrednictwem mojego API. Dzieje się tak z powodu asymetrii haszyszu; nawet jeśli znają skrót przechowywany w Twojej bazie danych, nie znają oryginalnego klucza użytego do jego utworzenia i właśnie tego używa Twoje oprogramowanie pośredniczące do uwierzytelniania. Dlatego też zawsze powinieneś solić swój magazyn haszyszowy.

To prawda, mogliby wyrządzić wiele innych szkód, gdyby mieli swobodę czytania z Twojej bazy danych.

Chcę tylko podkreślić, że jeśli zdecydujesz się zaszyfrować klucz przed odejściem od klientów, to nie wystarczy - hashowanie backendu jest, imo, o wiele ważniejsze i dlatego: Jeśli ktoś przechwytuje ruch z twojego klient, wtedy zobaczy zawartość passwordpola. Niezależnie od tego, czy jest to hash, czy zwykły tekst, nie ma znaczenia - mogą go skopiować dosłownie, aby podszyć się pod autoryzowanego klienta. (Chyba że wykonasz kroki opisane przez @ user3299591 i polecam to zrobić). Z drugiej strony haszowanie kolumny DB jest koniecznością i wcale nie jest trudne do wdrożenia.

Czy SSL / TLS nie zastępuje wartości jednorazowej? Nie widzę w tym żadnej wartości dodanej, ponieważ SSL / TLS chroni również przed atakami typu Replay.

Nr ref. https://en.wikipedia.org/wiki/Cryptographic_nonce

W rzeczywistości mniej bezpieczne byłoby haszowanie hasła i wysyłanie go niezaszyfrowanym kanałem. Ujawnisz swój algorytm haszujący na kliencie. Hakerzy mogą po prostu węszyć skrót hasła, a następnie użyć go do włamania się później.

Używając protokołu HTTPS, uniemożliwiasz hakerowi uzyskanie hasła z jednego źródła, ponieważ HTTPS używa dwóch kanałów, z których oba są szyfrowane.

To, czy istnieje przewaga i czy jest bardziej (lub mniej) bezpieczne, naprawdę zależy od implementacji. Zapewne jest pewna zaleta, ale jeśli zaimplementujesz to źle, z pewnością możesz stworzyć rozwiązanie, które jest mniej bezpieczne niż przekazywanie nawet hasła w postaci zwykłego tekstu.

Można na to spojrzeć z perspektywy dwóch typów ataków - jednego z dostępem do ruchu sieciowego, a drugiego z dostępem do bazy danych.

Jeśli osoba atakująca może przechwycić ruch sieciowy w wersji tekstowej w postaci zwykłego tekstu, zobaczenie skrótu hasła jest bezpieczniejsze niż zobaczenie hasła w postaci zwykłego tekstu. Chociaż osoba atakująca może nadal logować się na serwer przy użyciu tego skrótu, wymagałoby to brutalnego złamania (czasami wstępnie obliczonego) tego skrótu, aby określić hasło, które może być przydatne w innych systemach. Ludzie powinni używać różnych haseł w różnych systemach, ale często tego nie robią.

Jeśli osoba atakująca uzyskała dostęp do bazy danych, na przykład poprzez kopię kopii zapasowej, należy się upewnić, że nie można się zalogować, mając tylko tę wiedzę. Jeśli, na przykład, zapisałeś hash z nazwą logowania jako Czy wysyłasz hasło w postaci zwykłego tekstu lub hash po stronie klienta tego hasła, powinieneś zaszyfrować tę wartość po stronie serwera i porównać ten skrót z hashem przechowywanym w rekord użytkownika.hash(login_name+password) i przekazałeś ten sam hash od klienta do bezpośredniego porównania, atakujący może wybrać losowo użytkownika, wysłać odczyt skrótu z bazy danych i zalogować się jako ten użytkownik bez znajomości hasła, zwiększając zakres naruszenia. W takim przypadku wysłanie hasła w postaci zwykłego tekstu byłoby bezpieczniejsze, ponieważ osoba atakująca musiałaby znać ten tekst, aby się zalogować, nawet mając kopię bazy danych. W tym miejscu kluczowa jest implementacja.

Koncepcje, o których należy pamiętać:

• „Solisz” hash, dodając do swojego skrótu wartość unikalną dla zakresu, zazwyczaj unikalną dla wiersza. Jego celem jest zagwarantowanie unikalności skrótów od siebie nawzajem, nawet jeśli wartości w postaci zwykłego tekstu, które reprezentują, są takie same, więc dwóch użytkowników z tym samym hasłem nadal będzie miało różne skróty. Nie trzeba traktować soli jako tajemnicy.
• Podczas uwierzytelniania zawsze haszuj po stronie serwera jakąkolwiek wartość, którą przekazujesz od klienta jako hasło (nawet jeśli jest już zaszyfrowana) i porównuj ją z wstępnie zhaszowaną wartością przechowywaną w bazie danych. Może to wymagać przechowywania podwójnie zaszyfrowanej wersji oryginalnego hasła.
• Podczas tworzenia skrótu rozważ dodanie do skrótu soli unikatowej dla serwera / klastra, a także soli unikalnej dla wiersza, aby zabezpieczyć się przed dopasowaniem jakichkolwiek wstępnie obliczonych skrótów w tabelach odnośników.