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

110

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?

Jader Dias
źródło
5
@Jader Dias: Wiem, że o to nie pytałeś, ale nie zapewniłoby to większego bezpieczeństwa, gdybyś to zaszyfrował, a następnie wyślij przez https. W rzeczywistości może to uczynić go mniej bezpiecznym, ponieważ narażasz swoją sól. Ponadto (mówię tutaj o mojej tylnej stronie), mieszanie algorytmów może powodować więcej kolizji z hashami i uczynić je bardziej podatnymi na hakowanie.
Merlyn Morgan-Graham
@Merlyn "kolizje hash" dobra uwaga!
Jader Dias
Algorytmy mieszające w ogóle nie zwiększają prawdopodobieństwa kolizji. O to właśnie chodzi w funkcji skrótu. Biorąc pod uwagę dowolną entropię wejściową, zwraca wynik, który ma równe prawdopodobieństwo, że znajdzie się w dowolnym miejscu możliwej przestrzeni wyjściowej.
JJ
@JJ "Algorytmy mieszania w ogóle nie zwiększają prawdopodobieństwa kolizji." Naprawdę chciałbym zobaczyć dowód tego stwierdzenia. Pozwól, że cię zatrzymam: to nieprawda , generalnie zwiększa kolizje. Mogę łatwo skonstruować taką funkcję haszującą, że h (x) nie jest stałą 0, ale h (h (x)) = 0 dla wszystkich x. Musiałbyś więc odnieść się do dokładnego zestawu algorytmów haszujących i sposobu ich mieszania. Wtedy musiałbyś udowodnić swoje oświadczenie. AFAIK nawet dla wielu SHA (z solą) jest to otwarty problem. Zasadniczo uważamy, że to prawda. Kryptografia jest trudna.
dziwaczny

Odpowiedzi:

155

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

user3299591
źródło
25
Właśnie sprawdziłem Gmaila i Facebooka - narzędzia programistyczne Chrome podają mi zarówno POST, jak i wiadomość zakodowaną w postaci urlen, zawierającą moją nazwę użytkownika i hasło w postaci zwykłego (niesolonego) tekstu. Jak / dlaczego duzi gracze nie używają solenia nonce na kliencie?
gremwell
18
Haszujesz klucz wartością jednorazową i twierdzisz, że możesz ją odwrócić po stronie serwera. Czy w takim razie brutalnie wymuszasz hasz? Albo jak odzyskać wartość jednorazową, gdy otrzymujesz hash = HASH (sekret + nonce) HASH powinien być funkcją nieodwracalną. Zaimplementowałeś to? Nie sądzę, żeby to, co pan wyjaśnił, było wykonalne. Czy potrafisz stworzyć schemat blokowy protokołu?
Srebrny
19
Jeśli nie ufasz HTTPS, każdy wysiłek jest bezcelowy! Twój kod jest przesyłany przez sieć, a osoba atakująca może zmodyfikować / zastąpić wszystkie twoje próby zabezpieczenia hasła podczas przesyłania
Sajid Kalla
3
MitM, który może przepisać certyfikat, może przepisać wartość jednorazową. Albo co powiedział Sajid.
Leewz
4
Jeśli martwisz się o MITM z HTTPS, jaki jest sens wysyłania soli do klienta, aby klient mógł zasolić hasło przed przesłaniem skrótu z powrotem na serwer? Wydaje się bezcelowe. Równie dobrze może po prostu wykonać niesoloną mieszankę na serwerze, a następnie ponownie użyć soli do mieszania na serwerze. Oczywiście klient nie może być również generatorem soli klienta, ponieważ przy następnym logowaniu byłby inny i nie obliczałby tego samego skrótu po stronie serwera.
zmiażdżyć
24

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)

Kiersten Arnold
źródło
5
To nie powinno stanowić problemu. Jeśli klient korzysta z serwera proxy, wszystko, co zobaczy serwer proxy, to zaszyfrowane dane HTTPS. Jeśli mówisz o ataku typu man-in-the-middle, odpowiednio skonfigurowany certyfikat powinien temu zapobiec.
Kiersten Arnold
7
@Jader: Żadne majstrowanie przy danych nie powstrzyma ataku MITM, ponieważ może on po prostu przekazać wszystko, co do niego przyjdzie. Nie ma znaczenia, czy przesyłasz hasło, czy skrót. To zupełnie inna sprawa.
David Thornley
2
Celem SSL (HTTPS = HTTP przez SSL) jest udaremnienie MITM.
yfeldblum
1
@carnold - MINTM - A co z przekierowaniem na http? Czy większość ludzi to zauważy? sslstrip - securityfocus.com/brief/910
nate c
1
@Jader Dias próbujesz zatrzymać problem, który nie istnieje. HTTPS zatrzymuje ten problem, hash po stronie klienta nie dodaje żadnego zabezpieczenia. Klientowi nigdy nie można ufać.
wieża
17

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.

wieża
źródło
4
Właściwie chciałbym to ponownie zaszyfrować na serwerze, więc edytuj swoją odpowiedź, biorąc pod uwagę ten scenariusz.
Jader Dias
@Rook używa wymiany kluczy diffie-hellman razem z https jest "bezużytecznym" rozwiązaniem? (Mam na myśli, że możemy używać tylko https, a diffie helman nie zwiększa imao bezpieczeństwa)
Michel Gokan
@Michel Kogan wymiana kluczy DH może być używana w HTTP wraz z innymi narzędziami.
wieża
1
@Rook Najlepszą praktyką jest stosowanie skrótu na serwerze, więc myślę, że powinieneś zaktualizować początek swojej odpowiedzi, aby nie odrzucać haszowania po stronie klienta, a dopiero potem wspomnieć, że przechowywane hashe i sole serwera nigdy nie powinny być ujawniane.
Levente Pánczél
8

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.

Paul Keister
źródło
2
Wydaje się, że to bzdura ... W jaki sposób hash jest mniej bezpieczny niż hasło?
Levente Pánczél
1
Dotyczy to tylko „głupich” skrótów. Rozważ to: serwer wysyła sól S do klienta, a klient wykonuje HASH (S + PASSWORD) i wysyła go do serwera. Serwer honoruje ten konkretny skrót tylko dla bieżącej sesji. Osoba atakująca może rzeczywiście wysłać hash i zapomnieć o haśle, ale TYLKO NA BIEŻĄCĄ SESJĘ. Dlatego jest bezpieczniejszy niż zwykły tekst.
Hello World,
Aktualizacja: Uwierzytelnianie Digest Access jest jeszcze bardziej wyrafinowane: en.wikipedia.org/wiki/Digest_access_authentication
Hello World,
2
Żeby było jasne: kiedy mówię „pokonuje cel hashowania”, mam na myśli powszechną i bezpieczną praktykę haszowania haseł przed zapisaniem ich w bazie danych. Niemniej jednak argument utrzymuje, że wysłanie wartości zakodowanej zamiast hasła nie poprawia bezpieczeństwa bez dodatkowych kroków.
Paul Keister
Aby dodać do tego, co powiedział Paweł: ten rodzaj ataku nazywany jest „atakiem powtórkowym”, jeśli ktoś chce przeczytać o nim więcej w innym miejscu.
5

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 :)

Victor Zimmer
źródło
3

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

vlad b.
źródło
HTTP Digest implementuje to, co miałem na myśli w tym pytaniu, ale czy mielibyśmy jakąś przewagę, gdybyśmy użyli HTTPS Digest (SSL + HTTP Digest)?
Jader Dias
Jedną z głównych różnic jest to, że wszystko jest wysyłane / odbierane w postaci zaszyfrowanej - wysyłane i odbierane nagłówki http oraz odpowiedź HTML. Dla kogoś, kto losowo próbuje „zhakować” protokół ssl za pomocą ataku typu man-in-the-middle-skrót http byłby dodatkowym motywem do tego, by przeszukał inny łatwiejszy cel, lub jeśli rejestruje cały przechwycony ruch, Twoje hasła są nadal bezpieczniejsze. Mogłem źle zrozumieć pytanie, angielski nie jest moim pierwszym językiem.
vlad b.
Hash over password ma jedną wielką zaletę: jeśli ruch zostanie w jakiś sposób zarejestrowany lub przechwycony, utrudni to pracę tej osobie. Ponadto w przypadku skrótu http, jeśli protokół ssl nie zawsze jest wymagany, możesz pozwolić użytkownikom wybrać między http a https. Lub możesz użyć różnych protokołów dla różnych serwerów (na przykład nie wymuszam https, aby wyświetlać / modyfikować mniej importowanych danych (nazwa użytkownika, przesyłanie awatarów), ale wymuszam https w rozliczeniach i innych częściach witryny (w ten sposób mogę zmniejszyć obciążenie niektóre serwery, jeśli / kiedy są potrzebne).
vlad b.
3

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.

Simon w LabSlice-com
źródło
„ale strony internetowe z bardzo podstawowym zaciemnianiem (ROT13) również pojawiałyby się z hasłami, które nie są natychmiast używane” - zaprzecza to pierwotnemu stwierdzeniu. Kluczem jest to, że nie są one NATYCHMIAST używane, ale to naprawdę daremne. Hasło i jego ROT13 są równoważne. ALE jeśli SHA2 hasło nie będzie obecne w dziennikach (więc twoi administratorzy nie poznają możliwych haseł użytkowników do innych systemów), a TY JUŻ NIE naruszasz prawie każdej ustawy o prywatności.
Levente Pánczél
2

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

jac
źródło
Czy serwery proxy nie przechwytują tych danych?
Jader Dias
Jak rozumiem, robią, ale proxy nie jest odpowiedzialne za szyfrowanie / odszyfrowywanie i chyba że jest to pozbawiony skrupułów serwer proxy, przekazuje dane tylko dalej. Typ i siła szyfrowania zależą od tego, co serwer i klient mogą obsługiwać.
jac
1
Nawet jeśli serwer proxy jest nieuczciwy, nie może odszyfrować danych, ponieważ jest zaszyfrowany przy użyciu klucza publicznego serwera. Jedynym sposobem, w jaki proxy może odszyfrować dane, jest sfałszowanie certyfikatu serwera za pomocą innego klucza
Kiersten Arnold
@Jader. Gdyby tak było, HTTPS byłby dość kiepski. kiedy uwierzytelniasz się na serwerze za pomocą HTTPS, otrzymujesz gwarancję (zakładając, że certyfikat jest ważny), że łączysz się z określonym serwerem i masz zaszyfrowaną ścieżkę z jednego końca do drugiego. Hipotetycznie można by zrobić atak typu man in the middle, aby cię oszukać, ale to nie to samo, co podstawowy internetowy serwer proxy.
Peter Recore
2

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.

pixelpax
źródło
0

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.

Carter Medlin
źródło
1
Właściwie zhaszowałbym go ponownie na serwerze, a mimo to użyłbym HTTPS, więc proszę edytuj swoją odpowiedź, biorąc pod uwagę ten scenariusz.
Jader Dias
@Jader, chodzi o to, że teraz atakujący potrzebuje tylko pierwszego skrótu, a nie hasła. W efekcie skrót hasła po stronie klienta jest teraz tak samo przydatny, jak samo hasło. Więc tak naprawdę nie zyskujesz większego bezpieczeństwa.
Peter Recore
Czy ktoś kiedykolwiek pomyślał o nieprzesyłaniu części tokena? na przykład jeśli znasz swoje metody haszowania, po co to wysyłasz. czy serwer nie powinien znać klucza klienta do odszyfrowania?
jemiloii
0

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.
phatfingers
źródło