Dlaczego prawie nie ma hashów stron internetowych w kliencie przed przesłaniem (i zaszyfrowaniem ich ponownie na serwerze), aby „chronić” przed ponownym użyciem hasła?

46

Istnieje wiele witryn w Internecie, które wymagają danych logowania, a jedynym sposobem ochrony przed ponownym użyciem hasła jest „obietnica”, że hasła są mieszane na serwerze, co nie zawsze jest prawdziwe.

Zastanawiam się więc, jak trudno jest stworzyć stronę internetową, która haszy hasła na komputerze klienckim (z Javascriptem), zanim wyśle je na serwer, gdzie zostaną ponownie zakodowane? Teoretycznie nie daje to żadnego dodatkowego bezpieczeństwa, ale w praktyce można to wykorzystać do ochrony przed „nieuczciwymi witrynami”, które nie mieszają hasła na serwerze.

— Martín Fixman
źródło

18

hasło zaszyfrowane wysłane w postaci czystej nie jest lepsze niż hasło wysłane w postaci czystej, jeśli serwer po prostu porównuje wartości skrótowe, ataki człowieka w środku uwielbiają tego rodzaju „bezpieczeństwo”

3

Najlepszym rozwiązaniem jest (imo) menedżer haseł po stronie klienta. W ten sposób możesz wygenerować losowy ciąg znaków jako hasło i nie polegasz na serwerze, który cię „ochroni”.

— Dean Harding

2

@Jarrod - wydaje mi się jednak, że różne strony internetowe wykorzystujące różne algorytmy haszujące po stronie klienta zapobiegłyby atakowi opisanemu przez ten komiks. Jednym z często używanych haseł staje się wiele różnych haseł dzięki różnym algorytmom mieszającym. To obliczanie wartości skrótu po stronie klienta nie uniemożliwia stosowania innych rodzajów zabezpieczeń - takich jak wysyłanie skrótu za pośrednictwem bezpiecznego połączenia.

— Steve314,

2

@ Steve314 chodzi mi o to, że domyślnie zagrożone jest to, że klient jest zagrożony. Możesz mieszać i mieszać i mieszać, jeśli jest to wykonywane na kliencie i przekazywane w tę iz powrotem do serwera clear, jest to w tym momencie matematyczna masturbacja. Musiałem naprawić odziedziczony przeze mnie system, który został zaprojektowany dokładnie tak, jak Ty i OP, ciągle go hakują nastolatkowie z Wireshark. Zablokowaliśmy go tylko wtedy, gdy wprowadziliśmy REALszyfrowanie oraz zaszyfrowaliśmy i podpisaliśmy wszystkie ładunki do i z serwera, manipulacja kontem zatrzymała się i nigdy więcej się nie powtórzyła.

5

Wygląda na to, że Twoim planem ochrony przed nieuczciwymi witrynami jest poproszenie tych nieuczciwych stron o skonfigurowanie lepszego bezpieczeństwa. ?

— pc1oad1etter

46

Dlaczego nie jest używany? Ponieważ jest to dużo dodatkowej pracy dla zerowego wzmocnienia. Taki system nie byłby bardziej bezpieczny. Może być nawet mniej bezpieczny, ponieważ daje fałszywe wrażenie, że jest bardziej bezpieczny, co prowadzi użytkowników do stosowania mniej bezpiecznych praktyk (takich jak ponowne użycie hasła, hasła do słownika itp.).

— Rein Henrichs
źródło

2

To najlepsza jak dotąd odpowiedź.

1

To jest jak szyfrowanie Blu-Ray i DVD. Nie wymaga nawet klucza do odblokowania. Jedyną „ochroną”, jaką zapewnił, było to, że kiedy po raz pierwszy ukazały się dyski DVD, koszt zakupu płyty do skopiowania był większy niż zakup pełnej kopii filmu. Oczywiście teraz możesz kupić DVD za dolara, a tym bardziej, że klucze są teraz powszechnie znane. To samo dzieje się z Blu-Ray

— Michael Brown

2

Myślę, że mieszanie hasła po stronie klienta zwiększa bezpieczeństwo. Jeśli słucham, widzę tylko twój skrót, a nie hasło. Jeśli serwer wyśle wyzwanie (tak jak powinno), skrótu nie można nawet ponownie użyć.

— Andomar

2

Myślę, że podejście x4u może być bardzo odpowiednie dla niektórych aplikacji, w których wymagania bezpieczeństwa są gdzieś pomiędzy przesyłaniem haseł w sieci i używaniem certyfikatów. Wydaje mi się, że niektórzy z nieprzyzwoitych mówców przeoczają, że haszowanie hasła przed jego wysłaniem odbywa się oprócz standardowej obsługi poświadczeń po stronie serwera. Pytanie zatem brzmi: czy propozycja x4u poprawia bezpieczeństwo w scenariuszu przesyłania hasła na linii, czy nie. Mówię, że tak. Kluczem do osiągnięcia tego celu jest użycie soli według hasła.

— LOAS

6

Prawidłowym sposobem zapobiegania atakom MITM jest szyfrowanie całościowe. Istnieje protokół TLS (https): użyj go. Nie wymyślaj własnych schematów kryptograficznych.

— Rein Henrichs

14

Teoretycznie nie daje to żadnego dodatkowego bezpieczeństwa, ale w praktyce można to wykorzystać do ochrony przed „nieuczciwymi witrynami”, które nie mieszają hasła na serwerze.

Jak dokładnie to chroni? Wygląda na to, że wszystko, co chcesz zrobić, to haszować hashowane hasło, które jest w pewnym sensie bezcelowe. Ponieważ zaszyfrowane hasło stanie się wówczas hasłem.

Istnieje wiele witryn w Internecie, które wymagają danych logowania, a jedynym sposobem ochrony przed ponownym użyciem hasła jest „obietnica”, że hasła są mieszane na serwerze, co nie zawsze jest prawdziwe.

Co powiesz na nieużywanie tego samego hasła do więcej niż jednej witryny? Powodem, dla którego witryny haszują hasło w teorii, jest uniemożliwienie dostępu do konta, jeśli zostaną one naruszone. Używanie tego samego hasła do wielu stron jest po prostu głupie.

Jeśli używałeś javascript, wszystko, co „haker” musiałby zrobić, to użyć tej samej metody na hash-hashed-passwords. Po uzyskaniu informacji o haszowaniu obliczenie hasła-> tego samego skrótu w bazie danych zajmuje tylko chwilę, co jest czynnikiem uniemożliwiającym dostęp do konta.

— Ramhound
źródło

1

Jeśli twoja przeglądarka zawsze ma to samo, to tak, hash może być używany jako hasło wszędzie indziej. Ale co, jeśli przeglądarki przypisały sól na podstawie strony (może domeny?) Przed mieszaniem i wysyłaniem jej na stronę? Myślę, że to ciekawy pomysł.

— Tesserex

2

jeśli to na kliencie jest zagrożone, każda sól na kliencie jest widoczna, jest to nielogiczne pytanie. jeśli nie rozumiesz odpowiedzi @ Ramhounda, nie powinieneś pisać kodu, który musi być bezpieczny, i zacznij czytać o bezpieczeństwie i kryptografii od samego początku.

3

Gdy cytujesz oryginalny plakat, sformatuj tekst jako taki (zaznacz tekst i użyj ikony cytatu tuż nad edytorem)

— Marjan Venema

1

Jarrod, postępuj zgodnie z własnymi radami i zapoznaj się z informacjami zanim zaczniesz śmiesznie twierdzić. Mężczyzna w środku ataku jest bezużyteczny wobec bezpiecznych funkcji skrótu o rozsądnej długości soli. A moja sugestia nie jest w żaden sposób „zabezpieczeniem przez zaciemnienie”, jest w rzeczywistości bezpieczna w oparciu o to, co jest obecnie znane i akceptowane przez ekspertów w tej dziedzinie i jest stosowana w ten sam sposób w wielu protokołach. To nie jest mój wynalazek, po prostu zastosowałem dobrze zrozumiałą procedurę do logowania na stronie internetowej. Twoje fałszywe założenia nie zyskują na znaczeniu, ponieważ są one oczywiście podzielane przez wiele innych.

— x4u

3

Jeśli sól jest znana klientowi i jest wysyłana w czystej postaci z serwera, wszystko w środku również to wie. Nigdy nie mówiłem, że muszę cofnąć skrót, jeśli znasz sól na kliencie, to nie jest bezpieczne.

11

Ponieważ niewiele by to dodało do żadnej wartości. Przyczyną haszowania jest to, że jeśli baza danych zostanie zhakowana, haker nie będzie miał listy prawidłowych haseł, a jedynie hasze. Dlatego nie mogli podszywać się pod żadnego użytkownika. Twój system nie zna hasła.

Bezpieczne pochodzi z certyfikatów SSL oraz pewnej formy uwierzytelnienia. Chcę, aby moi użytkownicy podali hasło, dzięki czemu mogę obliczyć z niego skrót.

Ponadto algorytm mieszający znajduje się na serwerze w bezpieczniejszym obszarze. Umieszczając go na kliencie, dość łatwo jest uzyskać kod źródłowy dla Javascript, nawet jeśli jest to ukryty plik skryptów z odnośnikami.

— Jon Raynor
źródło

3

To najlepsza odpowiedź. Powinieneś zaszyfrować na warstwie transportowej. Bez tego reszta nie jest bezpieczna. Tak, możesz napisać funkcję szyfrowania ... ale ta funkcja byłaby widoczna dla (złośliwych) użytkowników końcowych. Użyj SSL.

— pc1oad1etter

Bezpieczeństwo algorytmu mieszającego nie powinno zależeć od tego, czy jest tajny. Algorytmy mieszania dla bezpieczeństwa powinny być funkcjami jednokierunkowymi: nawet jeśli masz kod, trudno go cofnąć. Przeciwnie, powinieneś używać dobrze znanej biblioteki skrótów zaprojektowanej tylko dla haseł. Jeśli nie jest to dobrze znane, prawie na pewno jest wadliwe lub źle traktowane.

— leewz

6

Rozwiązanie jest prostsze niż to. Certyfikaty klienta. Tworzę certyfikat klienta na moim komputerze. Kiedy rejestruję się na stronie internetowej, uzgadniamy z wykorzystaniem mojego certyfikatu klienta i certyfikatu serwera.

Żadne hasła nie są wymieniane, a nawet jeśli ktoś włamie się do bazy danych, będzie miał tylko klucz publiczny mojego certyfikatu klienta (który powinien zostać zasolony i zaszyfrowany przez serwer, aby zwiększyć poziom bezpieczeństwa).

Certyfikat klienta może być przechowywany na karcie inteligentnej (i przesyłany do bezpiecznego skarbca online za pomocą hasła głównego).

Piękno tego wszystkiego polega na tym, że usuwa się pojęcie phishingu ... nigdy nie wpisujesz hasła do strony internetowej, po prostu uzgadniasz tę stronę. Otrzymują tylko Twój klucz publiczny, który jest bezużyteczny bez klucza prywatnego. Jedyną podatnością jest znalezienie kolizji podczas uzgadniania, co zadziałałoby tylko raz na jednej stronie internetowej.

Microsoft próbował dostarczyć coś takiego w systemie Windows za pomocą Cardspace, a później podał go jako otwarty standard. OAuth jest nieco podobny, ale opiera się na pośredniczącej „stronie wydającej”. Z drugiej strony karty informacyjne mogą być wydawane samodzielnie. To jest prawdziwe rozwiązanie problemu z hasłem ... całkowite usunięcie hasła.

OAuth jest jednak krokiem we właściwym kierunku.

— Michael Brown
źródło

5

Chociaż certyfikaty klienta są rozsądnym podejściem w niektórych przypadkach użycia, nie są czymś, co można łatwo dodać do logowania do witryny. Wymagają dużej współpracy ze strony użytkowników i zależą od tego, jak bezpieczny jest klucz prywatny użytkownika. Korzystanie z klucza prywatnego może być bezpieczne lub wygodne, ale nie jednocześnie.

— x4u

5

wydaje się, że większość odpowiedzi całkowicie pomija punkt haszowania hasła po stronie klienta.

chodzi o to, aby nie zabezpieczyć dostępu do serwera, na który się logujesz, ponieważ przechwycenie skrótu nie jest bardziej bezpieczne niż przechwycenie hasła w postaci zwykłego tekstu.

chodzi o to, aby zabezpieczyć hasło użytkownika , które jest zwykle o wiele cenniejsze niż dostęp do indywidualnej strony logowania, ponieważ większość użytkowników ponownie użyje hasła do wielu witryn (nie powinni, ale w rzeczywistości to robią, więc nie należy ich wymachiwać) ).

ssl doskonale nadaje się do ochrony przed atakami mitm, ale jeśli aplikacja logowania zostanie przejęta na serwerze, ssl nie ochroni twoich użytkowników. jeśli ktoś złośliwie uzyska dostęp do serwera WWW, prawdopodobnie będzie w stanie przechwycić hasła w postaci zwykłego tekstu, ponieważ w większości przypadków hasła są mieszane tylko przez skrypt na serwerze. wtedy atakujący może wypróbować te hasła w innych (zwykle bardziej wartościowych) witrynach przy użyciu podobnych nazw użytkowników.

bezpieczeństwo to głęboka obrona, a haszowanie po stronie klienta po prostu dodaje kolejną warstwę. pamiętaj, że chociaż ochrona dostępu do własnej witryny jest ważna, ochrona poufności haseł użytkowników jest znacznie ważniejsza ze względu na ponowne użycie hasła w innych witrynach.

— kruche
źródło

2

Przyjęta odpowiedź całkiem dobrze podziela Twój punkt widzenia. Chociaż „większość odpowiedzi” tego nie robi, a ponieważ twoja odpowiedź tak naprawdę nie wnosi dużej wartości, nie ma sensu wskrzeszać tego pytania.

— Frank

jest to prawdopodobnie bardziej komentarz niż odpowiedź (przepraszam, że nie zastanawiam się, jak dodać do wątku komentarza z zaakceptowaną odpowiedzią) i chociaż mój punkt widzenia jest podzielany w zaakceptowanej odpowiedzi, najwyraźniej nie był wystarczająco jasny, ponieważ odpowiedzi na to wydają się nadal go strzepać. dziękuję za opinie

— crutchy

@Frank zaakceptowana odpowiedź graniczy z tym, że jest zbyt długa, aby zawracać sobie głowę czytaniem. zawiera zbyt wiele szczegółów na temat tego, jak można to wdrożyć, i pod koniec omija korzyści. Posiadanie TL; DR w innej odpowiedzi jest korzystne.

— Jules

2

@Jules: Właśnie dlatego istnieje edycja.

— Robert Harvey

1

@JarrodRoberson Myślę, że mylisz się, że nie jesteś już bezpieczny i niepewny ? Jeśli zdarzy się MITM, dostęp do strony jest już zrezygnowany, prawda? Chyba że użyjesz certyfikatu klienta zamiast hasła, co byłoby zbyt skomplikowane dla zwykłych użytkowników. Moim zdaniem, hashowanie po stronie klienta zapobiega naruszeniu tego samego hasła w innych witrynach, przy założeniu, że każdy algorytm hashujący jest unikalny. To może nie być bardziej bezpieczne, ale też nie jest w żaden sposób mniej bezpieczne? Dlaczego więc tak mocno na to naciskasz? Natknąłem się na to z meta i jest to najlepsza odpowiedź, jaką do tej pory widziałem.

— zypA13510

1

Jest to zdecydowanie możliwe, a właściwie nie trzeba czekać na stronę internetową.

Spójrz na SuperGenPass . To jest bookmarklet.

Po prostu rozpoznaje pola haseł, łączy to, co wpisujesz z domeną witryny, haszuje je, modyfikuje w taki sposób, aby uzyskać tylko „dozwolone” znaki w haśle, i dopiero wtedy twoje hashowane hasło jest wysyłane przewodowo.

Korzystając z domeny witryny w tym procesie, otrzymujesz unikalne hasło dla każdej witryny, nawet jeśli zawsze użyjesz tego samego hasła.

Nie jest to bardzo bezpieczne (base64-MD5), ale jeśli chcesz, doskonale rozpowszechniasz implementację opartą na sha-2.

Jedynym minusem jest zmiana domeny. W takim przypadku musisz poprosić witrynę o zresetowanie hasła, ponieważ nie będziesz w stanie samodzielnie go odzyskać ... jednak nie zdarza się to często, więc uważam to za akceptowalny kompromis.

— Matthieu M.
źródło

Właśnie o tym myślałem, czytając pytanie; jest praktycznie bezużyteczne dla stron, aby przeprowadzały własne haszowanie po stronie klienta, ale rozszerzenie przeglądarki, które to robi (używając soli w oparciu o domenę) skutecznie niweczy ryzyko związane z ponownym użyciem hasła. Oczywiście, część zabawy przychodzi, gdy próbujesz zalogować się z innej maszyny ...

— Aaronaught

3

nie jest to już bardziej bezpieczne niż jakikolwiek inny schemat, który przekazuje hasło w sposób wyraźny. To sprawia, że hasło jest unikalne, ale nadal nie jest szyfrowane , ale jeśli mam serwer w środku, mogę po prostu pobrać skomplikowane, ale wciąż jasne hasło i używać go tak długo, jak chcę, to się nie zmienia. Hash nie jest jakąś magiczną kulą, nie jest nawet szyfrowaniem, nazywane są hashami kryptograficznymi, ale to nie znaczy, że są szyfrowaniem. Nie ma znaczenia, czy moje hasło to passwordi / lub SHA-256 passwordz jakąś solą znaną klientowi, mężczyzna w środku załącznika może go przechwycić.

@Jarrod Roberson: możesz oczywiście użyć hasła, ale nie możesz go użyć ponownie na innym moim koncie, o to właśnie chodzi. Dlatego jeśli jedna z witryn, do których się podłączam, została skradziona, a dane przechowywane w bezpiecznym miejscu, moje pozostałe konta są bezpieczne.

— Matthieu M.,

@Aaronaught: właśnie tam świeci. Ponieważ wysłane hasło pochodzi wyłącznie z domeny internetowej, na którą się logujesz i hasła głównego, możesz zalogować się z dowolnego komputera (i przeglądarki), o ile masz bookmarklet. Dlatego jest nieco wygodniejszy niż certyfikat.

— Matthieu M.,

6

@Jarrod: To nie jest środek bezpieczeństwa dla witryny , to środek bezpieczeństwa dla użytkownika . Gdyby wszyscy korzystali z takiego schematu, ponowne użycie hasła nie byłoby problemem. Schemat MITM może wykorzystywać hasło z hasłem klienta, aby uzyskać dostęp do tej witryny, ale tylko do tej witryny. Na tym polega poprawa. Zwykle można oczekiwać, że będziesz w stanie uzyskać dostęp do wielu kont po prostu złamując jedno hasło, ponieważ to hasło prawdopodobnie zostanie ponownie użyte; w takim przypadku złamane hasło jest praktycznie gwarantowane, że jest ważne tylko dla witryny lub bazy danych, w której zostało odnalezione.

— Aaronaught

0

Podoba mi się odpowiedź X4u, ale moim zdaniem coś takiego powinno być zintegrowane ze specyfikacją przeglądarki / HTML - ponieważ w tej chwili jest to tylko połowa odpowiedzi.

Oto problem, który mam jako użytkownik - nie mam pojęcia, czy moje hasło zostanie zaszyfrowane na drugim końcu, gdy będzie przechowywane w bazie danych. Linie między mną a serwerem mogą być zaszyfrowane, ale nie mam pojęcia, co stanie się z moim hasłem, gdy dotrze do miejsca docelowego - może być zapisane jako zwykły tekst. Administrator bazy danych może sprzedać bazę danych i zanim się zorientujesz, cały świat zna twoje hasło.

Większość użytkowników ponownie wykorzystuje hasła. Ludzie nietechniczni, ponieważ nie wiedzą nic lepszego. Techniczni ludzie, ponieważ po dotarciu do 15. hasła większość osób nie ma szans na ich zapamiętanie, chyba że je zanotuje (co wszyscy wiemy, że to zły pomysł).

Jeśli Chrome, IE lub cokolwiek, z czego korzystam, może powiedzieć mi, że pole hasła zostanie natychmiast zakodowane po stronie klienta przy użyciu soli wygenerowanej przez serwer i skutecznie piaskownicy samego hasła - to wiedziałbym, że jako użytkownik mógłbym ponownie użyć hasło o mniejszym ryzyku. Nadal chciałbym zaszyfrowanych kanałów, a także nie chcę, aby podczas transmisji dochodziło do opadania okapów.

Użytkownik musi wiedzieć, że jego hasło nie jest nawet dostępne do wysłania na serwer - tylko skrót. Obecnie nawet korzystając z rozwiązania X4U, nie mają możliwości dowiedzenia się, że tak jest, ponieważ nie wiadomo, czy ta technologia jest używana.

— Chris Nevill
źródło

1

jest zintegrowany z przeglądaniem uwierzytelniania przeglądającego przeglądarkę, a zobaczysz kroki w przód i tył podjęte w http, aby uzyskać zaszyfrowane hasło, z dodatkowymi informacjami i zweryfikowane na serwerze.

— gbjbaanb

-1

Myślę, że jest to dobra metoda do użycia podczas budowania czegoś takiego jak framework, CMS, oprogramowanie forum itp., Gdzie nie kontrolujesz serwerów, na których może być zainstalowany. Oznacza to, że TAK, zawsze powinieneś zalecać używanie SSL do logowania i aktywności w logowaniu, ale niektóre strony używające twojego frameworka / cms nie będą go miały, więc nadal mogą z tego skorzystać.

Jak zauważyli inni, korzyścią tutaj jest NIE to, że atak MITM nie mógł pozwolić komuś innemu na zalogowanie się do tej konkretnej witryny tak jak Ty, ale raczej, że atakujący nie byłby wtedy w stanie użyć tej samej kombinacji nazwy użytkownika / hasła, aby zaloguj się na dziesiątki innych witryn, na których możesz mieć konta.

Taki schemat powinien zawierać sól losową lub kombinację soli specyficznych dla witryny i nazwy użytkownika, aby ktoś, kto uzyska hasło, nie mógł użyć go dla tej samej nazwy użytkownika w innych witrynach (nawet w witrynach korzystających z tego samego schematu mieszania ) ani przeciwko innym użytkownikom witryny, którzy mogą mieć to samo hasło.

Inni sugerują, że użytkownicy powinni tworzyć unikalne hasła dla każdej używanej witryny lub używać menedżerów haseł. Chociaż teoretycznie jest to dobra rada, wszyscy wiemy, że w prawdziwym świecie można polegać na szaleństwach. Odsetek użytkowników, którzy robią jedną z tych rzeczy, jest niewielki i wątpię, aby to się zmieniło w najbliższym czasie.

Tak więc program do zamykania haseł javascript jest co najmniej tym, co programista frameworku / cms może zrobić, aby ograniczyć szkody osób przechwytujących hasła w transporcie (co obecnie jest łatwe w sieciach Wi-Fi), jeśli zarówno właściciel witryny, jak i użytkownicy końcowi są zaniedbywani o bezpieczeństwie (którym prawdopodobnie są).

— matthewv789
źródło