Pytanie:
Jeśli dostawca widzi ostatnie 4 znaki mojego hasła, czy może je w całości zobaczyć?
rhymsy
2015-09-17 19:51:51 UTC
view on stackexchange narkive permalink

Mam kilka domen / witryn internetowych, a także e-maile z Bluehost. Za każdym razem, gdy potrzebuję pomocy, potrzebują ostatnich 4 znaków mojego głównego hasła do konta. Nie mogą mi powiedzieć, jak przechowują hasło, więc jestem zaintrygowany tym, jak mogą bezpiecznie przechowywać moje hasło (a) i nadal widzieć ostatnie 4 znaki. Czy widzą pełne hasło w postaci zwykłego tekstu?

Wszystkie scenariusze są możliwe.
Dotyczy to renomowanego hosta internetowego, więc chociaż nie możemy być pewni, że zostało to zrobione w sprytny sposób, możemy (prawdopodobnie) założyć, że robią to przynajmniej trochę bezpiecznie. Jednak naprawdę nie ma na to bezpiecznego sposobu.
Następnym razem, gdy będziesz potrzebować wsparcia, podaj inne 4 cyfry. Jak powiedział @Begueradj, wszystkie scenariusze są możliwe. Obejmuje to teatr bezpieczeństwa.
@emory W zależności od stopnia bezpieczeństwa istnieje szansa, że ​​celowe podanie niewłaściwych 4 cyfr może spowodować zablokowanie konta pytającego.
@immibis dobra uwaga. zadzwoń do nich i poproś o pomoc przy użyciu poświadczeń innego użytkownika. Następnie, gdy poproszą o ostatnie 4, wymyśl coś. Jeśli zdecydują się udzielić wsparcia, jest duża szansa, że ​​nie mają systemu do 4 ostatnich weryfikacji i proszą o to wszystko na pokaz.
@immibis, sugerujesz, że ** każda osoba ** może zablokować konto innej osoby, po prostu dzwoniąc i podając niewłaściwe informacje?
Wygląda na to, że traktuję ostatnie cztery cyfry mojego hasła jako efektywny dwuskładnikowy kod PIN uwierzytelniania i skonstruuję hasło, które będzie silne * bez * tych ostatnich czterech cyfr. IE, „popraw zszywkę do akumulatora dla koni 7684” jako hasło.
Gdybym doświadczył tego, co opisujesz, przestałbym używać Bluehost JAK NAJSZYBCIEJ.
@Chipperyman, zdecydowanie nie możemy niczego zakładać. Mogą mieć dużą bazę klientów, a także podawać numery kart kredytowych, po prostu nie wiesz.
@emory, jak do licha poprosiłbyś o część twojego hasła „na pokaz”? Jedyne, co pokazuje, to ich całkowita niekompetencja w kwestii bezpieczeństwa.
@Octopus w taki sam sposób, w jaki zdjęcie butów na lotnisku chroni lotnictwo, recytowanie 4 cyfr przedstawicielowi serwisu, który może ich zweryfikować lub nie, może „chronić” bluehost. Niektórzy użytkownicy utożsamiają niedogodności z bezpieczeństwem. Daj im to, czego chcą.
@emory, nie, absolutnie nie. nie jest to niewygodne, jest to zła praktyka bezpieczeństwa.
@Octopus nikt nie sugeruje, że jest to dobra praktyka bezpieczeństwa.
Ostatnie cztery znaki to oczywiście „3456”, „w0rd” lub „apple”
Dla wszystkich głoszących jest to „niemożliwa zła decyzja” - z biznesowego punktu widzenia może to być całkowicie uzasadniony przypadek użycia. Jeśli ich baza danych haseł zostanie zhakowana, będzie to szkodliwe dla firmy. Każdy Użytkownik zostanie poinformowany o naruszeniu bezpieczeństwa, zmień hasło - jeśli niezabezpieczony zapisał 4 cyfry, hasła zostaną złamane szybciej. Zatem szkody dla reputacji będą nieco większe, ale ponieważ jest to scenariusz o niskim prawdopodobieństwie i wysokim ryzyku, ogólny wpływ na budżet ryzyka może być naprawdę niewielki. A korzyść z tego, że użytkownicy nie zapomną o dodatkowym kodzie, może być większa.
Jako były pracownik Bluehost mogę powiedzieć, że nie znają całego hasła. Jest tylko pole, w którym agent wpisuje ostatnie cztery cyfry hasła, a następnie system porówna je z hasłem, które ma w pliku. Jeśli pasuje, zmieni kolor na zielony i zostanie zarejestrowany, jeśli nie, zmieni kolor na czerwony i oznaczy również dziennik. Nawet jeśli znali hasło, wszystko, co robi pracownik, jest rejestrowane na koncie i można je następnie sprawdzić, jeśli przypuszcza się, że coś się wydarzyło. Jeśli chodzi o przechowywanie hasła i szyfrowanie, bije mnie, ale nigdy o żadnym nie słyszałem
@Mansav Mimo to jedynym sposobem, który może zadziałać, jest przechowywanie hasła w postaci niezaszyfrowanej.
@Daniel technicznie mogą mieć 2 skróty, jeden dla całego hasła i jeden dla ostatnich 4 znaków. Wciąż zmniejszyłoby to bezpieczeństwo, ale nie tak bardzo.
Mogliby przechowywać ostatnie 4 znaki jako osobną wartość w bazie danych (w postaci skasowanej lub zaszyfrowanej) - co ułatwia weryfikację.
Mogli po prostu pomnożyć wszystkie wartości, a następnie zapisać je w postaci zwykłego tekstu.Oczywiście oznacza to, że wiele haseł będzie ważnych, ale myślę, że to dobry kompromis.Coś innego niż mnożenie mogło zostać użyte do uzyskania skrótu, który spowoduje wiele kolizji.
Dziewięć odpowiedzi:
Steve Sether
2015-09-17 20:12:43 UTC
view on stackexchange narkive permalink

Istnieje kilka możliwości.

  1. Mogą przechowywać pełne hasło w postaci zwykłego tekstu i wyświetlać tylko ostatnie 4 znaki osobie obsługującej.

  2. Mogą dwukrotnie zaszyfrować hasło. Raz zaszyfrowano pełne hasło i ponownie tylko ostatnie 4. Następnie osoba pomocy technicznej wpisuje ostatnie 4, aby sprawdzić, czy pasuje ono do zaszyfrowanej wartości. Problem z tym polega na tym, że ułatwia brutalne wymuszanie pełnych haseł, ponieważ ostatnie 4 znaki są w osobnym skrócie, zmniejszając entropię.

  3. Mogą haszować pełne hasło, i przechowywanie ostatnich 4 inplaintext. Oczywiście znacznie ułatwia to brutalne wymuszenie hasła, jeśli osoba atakująca uzyskująca dostęp do bazy danych haseł zna 4 ostatnie cyfry.

  4. Coś innego, gdzie ostatnie 4 znaki są przechowywane w niektórych sposób, który można odkryć, na przykład szyfrowanie, o którym wspomina Mike Scott. Jeśli można odkryć sekret odblokowania 4 znaków, jest to tak samo złe jak zwykły tekst.

Wszystkie scenariusze są bardzo złe i znacznie zmniejszają bezpieczeństwo systemu. Nie można wiedzieć, którego scenariusza używają, ale każdy z nich nie zwraca uwagi na naruszenia bezpieczeństwa. Radziłbym zachować ostrożność, jeśli jest to witryna, w której zależy Ci na naruszeniu Twojego konta.

Jest jeszcze co najmniej jedna opcja. Mogą zaszyfrować pełne hasło, a także zapisać ostatnie cztery znaki za pomocą szyfrowania symetrycznego, aby ich oprogramowanie mogło je odszyfrować dla osoby obsługującej. Wciąż źle, ale nie całkiem _ tak źle.
Większość dobrych witryn po prostu wychodzi i mówi na przykład: „Nikt stąd ** nigdy ** nie poprosi Cię o podanie hasła”. To znaczy, oczywiście, nawet cztery ostatnie cyfry ...
Właśnie sprawdziłem formularz zmiany hasła na moim koncie Bluehost. Niestety, serwis pozwala na używanie haseł o długości zaledwie 8 znaków, co oznacza, że ​​te ostatnie cztery cyfry mogą dramatycznie osłabić niektóre hasła. (Zgaduję, że przy dostatecznie długich hasłach pozwolenie na wykrycie ostatnich czterech znaków nie zmniejsza na tyle entropii, aby była praktycznym problemem?)
Pod każdym względem przechowywanie skrótu ostatnich 4 jest równoważne również przechowywaniu zwykłego tekstu. Dzięki nowoczesnym procesorom graficznym możesz brutalnie wykorzystać tę przestrzeń w mgnieniu oka.
Dobry scenariusz: hasło jest podzielone. Pierwsze znaki są mieszane z solą, a ostatnie 4 z inną solą.
@Ismael: To nadal skraca czas przerwy od `O (2 ** (n + k))` do `O (2 ** n + 2 ** k)` ... co jest ** naprawdę bardzo złe **. Mniej więcej tak daleko od „dobrego scenariusza”, jak można sobie wyobrazić (wprawdzie nadal lepsze niż przechowywanie zwykłego tekstu)
@IsmaelMiguel Jeśli haszujesz cztery znaki, sól cię nie uratuje. Zakładając, że te postacie są wybrane z zestawu około 90, istnieje tylko 65 milionów możliwości i można je dość szybko wymusić brutalnie (chyba że używają czegoś takiego jak bcrypt ze współczynnikiem pracy, który jest wystarczająco duży, aby spowolnić operacje do punkt, w którym użytkownik zauważa opóźnienie).
Co się stanie, jeśli ostatnie cztery znaki są przechowywane przy użyciu skrótu z dużą liczbą kolizji, ponieważ zostanie on użyty do prostej weryfikacji jednokrotnej? Jeśli ten hash zostanie brutalnie wymuszony, wygeneruje wiele fałszywych wyników, które nie pomogą zbytnio uzyskać pełnego hasła.
@MikeScott Jak inaczej można przechowywać hash składający się z 4 znaków? Pomyślałem, że sugerowano, że ma to spowolnić operację tak, jak to tylko możliwe.
@IsmaelMiguel Nie zaprojektowałbyś swojego systemu w taki sposób, że w ogóle przechowywałbyś kryptograficzne skróty czterech ciągów znaków - nie ma właściwego sposobu, aby to zrobić, więc po prostu tego nie rób.
@MikeScott Dobra dobra dobra dobra dobra dobra dobra dobra dobra dobra. Ale jak ochroniłbyś 4-znakowy pin?
Warto zauważyć, że najmniej bezpieczna opcja jest również najłatwiejsza, a więc niestety najbardziej prawdopodobna.
Jeśli dobrze to zrozumiałem, prawdopodobnie pozwalają one tylko na „wprowadzenie” czterocyfrowego hasła przez telefon. Zastanawiam się, czy to znacząco obniża bezpieczeństwo, ponieważ nie można wykonać tysięcy prób na sekundę przez telefon :). „Drugie” hasło może być przechowywane w bazie danych z dostępem tylko do odczytu. Zastanawiam się, jakie konsekwencje dla bezpieczeństwa miałby taki scenariusz.
Jeśli ostatnie 4 znaki są przechowywane jako cyfra kontrolna (podobnie jak opisana powyżej mieszanka o wysokiej kolizji), nie osłabi to znacząco skrótu rzeczywistego hasła, które można bezpiecznie przechowywać.
@Kevin:, jeśli pierwsze n-4 znaki hasła stanowią „dostatecznie dobre” hasło do jakiegoś celu, a ostatnie 4 nie dają żadnej wskazówki innym, to na pewno, ujawnienie ostatnich 4 znaków nie powoduje żadnych problemów w tym celu. Na przykład, jeśli losowo wygenerowałeś hasło za pomocą swojego menedżera haseł, może ono mieć już 4 znaki przesadne, a jeśli nie, to dodanie 4 znaków poza to, czego zwykle używasz, zapewni pewność.
... ale jest to nadal głupie ze strony dostawcy, ponieważ nie wyjaśnił on konsekwencji pytającemu. Zamiast tego mogli poprosić o oddzielne 4-znakowe „hasło”. Oczywiście, jeśli to zrobisz, nadal istnieje ryzyko, że użytkownicy dadzą ci 4 znaki z głównego hasła, nie jest łatwo przekonać ich, że jest inaczej. Możesz więc wygenerować go dla nich, ale wtedy go nie zapamiętają itp. Lub możesz zalogować się i nacisnąć przycisk, aby wygenerować tymczasowy kod pomocniczy, ale to nie pomaga osobom, których problem z obsługą jest zablokowany z ich konta ...
@IsmaelMiguel Musisz przechowywać pin w sprzętowym module TPM. To właśnie robią banki.
@Navin Czy to nie są tylko do odczytu? Poza tym, jak zmieniłbyś numer PIN, powiedzmy, swojego konta? (W moim przypadku zamiast karty kredytowej mam tę książkę, którą czyta bankomat, jak gigantyczną kartę z taśmą magnetyczną. Jak, twoim zdaniem, byłaby przechowywana?)
Niektóre banki wydają karty kredytowe z kodem PIN, które fizycznie blokują dostęp do chipa po pewnej ograniczonej liczbie prób. _Mogą_ mieć jeden taki chip na klienta i bezpiecznie przechowywać w nim ostatnie 4 znaki. Jednak prawdopodobnie nie.
I tak próby brutalnej siły @CommuSoft, nigdy nie są wykonywane przez zamierzony interfejs. Byłoby to o wiele za wolne. Problem pojawiłby się, gdy / gdyby ktoś uzyskał dostęp do bazy danych. Przechowywanie go oddzielnie od głównego skrótu nie pomaga, podobnie jak ustawienie go tylko do odczytu.
@ChrisMurray: Wiem o tym. O tylko do odczytu: popełniłem błąd, a co z bazą danych z dostępem tylko do zapisu dla połączenia przez serwer. Stworzyłoby to dodatkową barierę do obejścia.
@CommuSoft, Nie można zmusić go tylko do zapisu, ponieważ system wsparcia musi być w stanie zweryfikować podane hasło.
@ChrisMurray: Mam na myśli, że serwer bazy danych ma dwa połączenia: jedno z (serwerem WWW), które jest tylko do zapisu. Drugi dołączony do „intranetu”, który może odczytać zawartość. Najwyraźniej można spróbować włamać się do praw dostępu, ale utrudnia to przynajmniej o jeden krok. Najwyraźniej urządzenie, które ma tylko sposób zapisywania danych, tylko zwiększa entropię we wszechświecie.
Co jeśli mam hasło abcdef. Haszują wszystkie oprócz ostatnich czterech znaków (ab), a następnie haszują ostatnie cztery znaki (cdef). Oznacza to, że istnieją dwa haszysz, które mogą być całkowicie niezależne z różnymi solami. Po zalogowaniu sprawdź oba skróty, ale obsługa klienta sprawdza tylko jeden.
@the_lotus To też jest możliwe i równie złe. Można to zrobić na wiele różnych sposobów, ale wszystkie z nich wpłyną na proces haszowania. Nie znam żadnego sposobu, aby to zrobić w sposób, który nie zagraża bezpieczeństwu, a może to być nawet niemożliwe, chyba że polegasz na czymś takim jak TPM.
@CommuSoft Prowadzę firmę, która przetwarza wiele transakcji i właśnie tym się zajmuję! Serwer sieciowy może * zapisywać * tylko w bazie danych, która przechowuje numery SSN, prywatne klucze bitcoin itp. Tylko osoba z fizycznym dostępem może * czytać * z bazy danych.
„Wszystkie scenariusze są bardzo złe” Proszę podkreślić tę część odpowiedzi. Postaraj się, aby był jak najbardziej czarny, jak największy i jak najwięcej wielkich liter.
Inną opcją dla twojej listy jest to, że można to zrobić przy użyciu haseł szyfrowanych symetrycznie HSM +. Prawidłowo zaimplementowane, nie jest to niebezpieczne (na przykład wiele / wszystkie banki robią z kodami PIN do kart).
@GustavoRodrigues Zwiększyłoby to również prawdopodobieństwo fałszywie pozytywnego potwierdzenia tożsamości.
Widziałem też inne podejście (czasami używane w przypadku certyfikatów) - wszystkie kody PIN byłyby przechowywane na oddzielnym komputerze, połączonym tylko prostym łączem szeregowym. Jedyna możliwa operacja to „Wyślij PIN -> Odczytaj sukces / niepowodzenie”. O ile ktoś nie dotrze do komputera * fizycznie *, jest to tak bezpieczne, jak to tylko możliwe. I wszyscy wiemy, co można zrobić z komputerem, gdy już do niego dojdziecie :)
Pamiętaj, kiedy omawiając brutalne forsowanie 4 postaci, są one przekazywane ustnie przedstawicielowi serwisu; nie są próbowane automatycznie w tysiącach naraz.
@Daniel Zakładamy, że haker przeniknął do systemu, którego przedstawiciel serwisu używa do weryfikacji czterech znaków, najprawdopodobniej poprzez zdobycie podstawowej bazy danych. Tak więc prędkość brutalnego wymuszania jest ograniczona jedynie szybkością ich sprzętu i stopniem trudności wykorzystywanych algorytmów.
WhiteWinterWolf
2015-09-17 20:10:35 UTC
view on stackexchange narkive permalink

Zawsze trudno jest odpowiedzieć na takie pytania, ponieważ nie jesteśmy w tajemnicach Bluehost, więc możemy tylko zgadywać i przypuszczać.

Jednak zachowanie, które opisujesz, pozostaje możliwe bez przechowywania jasnego hasła:

  • Kiedy tworzysz nowe konto lub resetujesz hasło, hasło jest wysyłane do serwera, najprawdopodobniej w czytelnej formie chronionej przez TLS,
  • Serwer wygeneruje wtedy dwa różne skróty dla tego samego hasła:
    • Pierwszy hasz pobiera pełne hasło i służy do zwykłego uwierzytelniania,
    • Drugi skrót zajmuje tylko cztery ostatnie znaki hasła,
  • Kiedy kontaktujesz się z zespołem pomocy technicznej, podajesz im swoje ostatnie cztery znaki, wpisują je w oprogramowaniu, a następnie oprogramowanie wewnętrznie oblicza hash, sprawdza go i wyświetla wynik w technik wsparcia.
Dlaczego mieliby użyć do tego części Twojego hasła? Do tego służą zabezpieczające kody PIN.
@Octopus: Jak powiedziałem, nie jesteśmy w tajemnicach Bluehost, więc na pewno nie mogę odpowiedzieć „dlaczego”, mogę tylko zgadywać „jak”. I najprawdopodobniej nawet większość pracowników Bluehost nie mogłaby szczerze odpowiedzieć „dlaczego” ten system został tak zaprojektowany: w pewnym momencie kilka osób, menadżerów i kierowników projektów spotkało się w jednym pomieszczeniu i uznało, że to najlepsza opcja, tylko oni znaliby dokładne zalety i wady, które były omawiane podczas tego spotkania.
bishop
2015-09-19 00:40:16 UTC
view on stackexchange narkive permalink

BlueHost zaleca rozsądne zasady dotyczące silnych haseł, więc prawdopodobnie zatrudniają co najmniej jedną osobę, która wie, co robi.

Zakładając takie, BlueHost może używać implementacji Tajne udostępnianie Shamira lub odmiana na ten temat. Schemat Shamira jest teoretycznie bezpieczny, więc nie od razu wyciągałbym wniosku (tak jak inne odpowiedzi), że każdy schemat, który to robi, jest z natury mniej bezpieczny.

Z drugiej strony wdrożenie Shamira jest nietrywialne, więc każda z pozostałych odpowiedzi może mieć zastosowanie. Ponieważ bezpieczeństwo ostatecznie polega na zaufaniu , jeśli czujesz się niepewnie z tym schematem, proponuję znaleźć innego dostawcę!

Albo że mogli ** skopiować ** listę rozsądnych reguł od kogoś innego. Jak niestety w tym przypadku. Jest wyraźnie skopiowany ze [starej strony Microsoft dotyczącej haseł] (https://web1.tcdsb.org/CCRFProduction/images/Strong%20Passwords.pdf). Nawet nie dostosowali go do swojej sieci, jak zdanie „Sprawdzanie haseł nie rejestruje funkcji _w tej witrynie internetowej_” (odsyłacz do narzędzia sprawdzania haseł firmy Microsoft) lub dyskusja o pustych hasłach w różnych wersjach systemu Windows poza zakresem dla bluehost).
Biorąc pod uwagę te wskazówki i nawet nie przyznają, że ta zawartość pochodzi z artykułu firmy Microsoft z 2006 roku (czy byłoby tak trudno powiedzieć: „Microsoft zaleca następujące wskazówki dotyczące tworzenia bezpiecznych porad”?), Bardzo wątpię, czy otrzymali zgoda właściciela praw autorskich (prawdopodobnie Microsoft) na kopiowanie. Ale ważniejsze niż naruszenie praw autorskich (na tyle problematyczne, że firma może być zaangażowana), myślę, że możemy odwrócić wniosek biskupa i dojść do wniosku, że nie zatrudniają ani jednej osoby, która o tym wie (a przynajmniej nie 't).
Co sprawia, że ​​jestem jeszcze bardziej nieufny wobec bezpieczeństwa w tej firmie. Jeśli źle zrozumieli, co do _nieważnej_ porady dotyczącej hasła, ** skąd mogę mieć pewność, że zrobili to dobrze przy ważnych decyzjach? ** Zwłaszcza po tym, jak dowiedzieli się o ich wątpliwej praktyce „używania ostatnich 4 znaków hasła” w telefonie weryfikacja…
@Angel Niezłe badanie i zgodziłem się: nie mając innych dowodów świadomości bezpieczeństwa, wątpię w ich motywy i realizację.
Nie rozumiem, dlaczego byłoby to bezpieczniejsze. Jedynym sposobem, w jaki jest to bezpieczniejsze, jest zapewnienie pracownikowi działu pomocy „części”, która musi być z nich społecznie wyodrębniona. Poza tym, teraz po prostu brutalnie wymuszasz na 4 postaciach ze znanymi innymi częściami, aż uzyskasz pasujący sekret. Nawet w sytuacji, gdy potrzeba k + 2 części, z k częściami w systemie, k osobami z helpdesku i 1 sekretem znanym tylko przez klienta, otrzymasz co najwyżej k możliwych części, które możesz przetestować z innym sekretem dowiedzieć się, która część nie działa, a zatem musi być częścią klienta.
kasperd
2015-09-17 23:13:03 UTC
view on stackexchange narkive permalink

Nie mogę powiedzieć dokładnie, w jaki sposób przechowują hasło. Ale z twojego opisu ich procesu możemy pokazać, że hasło musi być przechowywane w niezabezpieczony sposób.

Zakładam, że kiedy proszą o ostatnie cztery znaki, faktycznie będą w stanie zweryfikować poprawność o tym, co im powiedziałeś (innymi słowy, po prostu nie blefują).

Oznacza to, że mają dane, które pozwolą im zweryfikować postacie, które im powiedziałeś w krótkim czasie. Te same dane mogą zostać użyte w ataku siłowym, aby złamać ostatnie cztery znaki hasła. Cztery postacie są z pewnością za krótkie, aby powstrzymać zdeterminowanego napastnika.

Gdy atakujący ma ostatnie cztery znaki, można przeprowadzić kolejny atak na wcześniejszych postaciach. W przypadku tego brutalnego ataku ostatnie cztery znaki hasła nie dodają żadnego zabezpieczenia, więc w najlepszym przypadku masz takie samo zabezpieczenie jak hasło o cztery znaki krótsze niż jest w rzeczywistości.

Może być możliwe obejście problemu luka w zabezpieczeniach poprzez wybranie bezpiecznego hasła, a następnie dodanie czterech dodatkowych znaków wybranych całkowicie niezależnie od hasła wybranego na początku. Będzie to bezpieczne, jeśli będą mogli zweryfikować tylko cztery ostatnie znaki, a nie sufiks o dowolnej długości.

Jeśli faktycznie są w stanie zweryfikować sufiks o dowolnej długości, a nie tylko o dokładnie czterech znakach, przechowywanie haseł byłoby jeszcze słabsze. Byłoby to równie niebezpieczne, jak przechowywanie go jako zwykłego tekstu, a w takim przypadku nie można go obejść, wybierając silniejsze hasło.

Rzeczywiście, jeśli możesz zweryfikować sufiks o dowolnej długości, oznacza to koniec gry. Potrzeba tylko 256 prób (lub mniej), aby zweryfikować ostatni bajt, następnie 256 kolejnych, aby zweryfikować ostatnie dwa bajty, znając ostatni bajt, i tak dalej, aż poznasz pełne hasło w 256 * n próbach. Jak powiedziałeś, równie dobrze może to być zwykły tekst, jeśli chodzi o atak offline na przechowywany hash.
hogarth45
2015-09-17 20:02:00 UTC
view on stackexchange narkive permalink

Jak wiesz, hasło powinno zostać zaszyfrowane przed zapisaniem, więc musisz zadać sobie pytanie o pogodę, czy nie, czy przechowują ostatnie 4 znaki w celu autoryzacji ustnej, a następnie haszują hasło przed zapisaniem, albo po prostu przechowując to jako zwykły tekst.
Myślę, że to drugie.

emory
2015-09-18 09:19:45 UTC
view on stackexchange narkive permalink

Nie sądzę, żeby to było prawdopodobne, a jedynie możliwe.

Za każdym razem, gdy OP potrzebuje wsparcia, proszą o 4 ostatnie cyfry swojego hasła. Solą i haszują to oraz przechowują sól i hash oraz wystarczającą ilość informacji, aby zrekonstruować wsparcie w specjalnej tabeli wsparcia.

Następnie, gdy OP się zaloguje (z pełnym hasłem), mogą przejrzeć tabelę wsparcia i obliczyć skróty. Następnie zatwierdzają zweryfikowane "wsparcie" i odrzucają sfałszowane "wsparcie".

To oczywiście zakłada, że ​​

  • wsparcie to coś, co można zobowiązać lub odrzucić w późniejszym czasie

  • proces proszenia o ostatnie 4 nie powoduje wycieku informacji (ktoś, kto pyta cię o ostatnie 4, nie kwalifikuje się, ponieważ nie możemy rzetelnie wyczyścić jego wspomnień) .

Nie wyobrażam sobie sytuacji, w której miałoby to sens biznesowy. Ale jeśli tak, myślę, że zamiast tego wystawiłbym moim użytkownikom specjalne 4-cyfrowe hasło „pomocnicze”.

A przechowywane, jeszcze niezweryfikowane „podpory” nadal są nieocenioną pomocą dla crackerów, jeśli można je ukraść wraz z zaszyfrowanymi pełnymi hasłami.
@BenVoigt tak, brutalne wymuszenie ostatnich 4 cyfr jest możliwe, więc ich solenie nie dodaje dużej wartości. Alternatywnie, jeśli atakujący może zaobserwować, które wsparcie zostało popełnione lub odrzucone, a atakujący może zautomatyzować żądania wsparcia bez wywoływania odcięcia, wówczas obserwator prawdopodobnie może brutalnie wymusić ostatnie 4.
Jeśli użytkownik wysyła kilka próśb o pomoc, a następnie zapomina hasła, prośby o pomoc są zatwierdzane lub odrzucane. Jeśli zostanie popełniony, atakujący może wysłać kilka żądań pomocy, a następnie udawać, że użytkownik „zapomniał hasła”. Jeśli zostanie odrzucony, atakujący może odrzucić żądania pomocy rzeczywistego użytkownika.
CoffeDeveloper
2015-09-23 15:52:32 UTC
view on stackexchange narkive permalink

Czy widzą pełne hasło? Tak, na pewno jest możliwe, że mogą odgadnąć hasło (jeśli 4 ostatnie cyfry to data lub części słowa. Jeśli hasło jest w całości zaszyfrowane, znajomość 4 cyfr wystarczy, aby przeprowadzić brutalny atak lub nawet próbując wykonać heurystykę na funkcji skrótu, aby zobaczyć, jak 4 cyfry propagują się z powrotem, znacznie zmniejszając zakres możliwych haseł.

Odgadnij to hasło: 

  ** ******* ange

Albo ten: 

  **** 1994

To jest również możliwe, że są hakerami i wykorzystują API obsługi klienta (jeśli istnieje), aby uzyskać dostęp do informacji o użytkownikach, zadanie to jest nawet łatwiejsze dzięki znajomości 4 cyfr.

Nie powinni tego robić, w żadnym wypadku nie dają część hasła do nieznajomego to dobra opcja nawet (SZCZEGÓLNIE, jeśli po zwolnieniu może próbować skrzywdzić użytkowników, a jest wiele przykładów historycznych), jeśli jest to część obsługi klienta.

Klient pomoc techniczna nie powinna mieć możliwości uzyskania dostępu do oryginalnego hasła i powinna działać za pośrednictwem interfejsu API ad-hoc, aby to zrobić nie robić złych rzeczy (nadal pomoc techniczna nie powinna mieć dostępu do pełnych danych).

Ponadto, jeśli obsługa klienta musi prosić 4 cyfry hasła, nie możesz wysłać do użytkowników e-maili z ostrzeżeniami typu „nigdy nie podawaj hasło, ponieważ nie prosimy o to ”, ponieważ w rzeczywistości o to prosisz, a przeszkolenie użytkowników w podawaniu danych osobowych może pomóc im dać się złapać na wiadomościach phishingowych.

Jeśli naprawdę chcą sprawdzić autentyczność użytkownika, powinni używaj takich rzeczy, jak kody SMS, tajne pytania lub po prostu klucze wysłane e-mailem.

Mimo to myślę, że wysłanie wiadomości e-mail lub SMS-a jest znacznie tańsze niż płacenie 1-2 minut komuś, kto robi to samo ( chyba że jest osobą naprawdę niedostatecznie opłacaną).

Jeśli usługa naprawdę wymaga sprawdzenia tożsamości użytkownika pod kątem czegoś ważnego, prawdopodobnie użyłbym strumienia z kamery internetowej, z którego operator może zobaczyć twarz użytkownika, a następnie poprosiłbym go o wykonanie określonych czynności (takich jak napisanie słowa na papierze i pokazanie go z powrotem), aby uniemożliwić komuś wykorzystanie nagranego wideo).

To oczywiście nie będzie lubiane przez użytkowników ze względu na prywatność ^^

Twoja odpowiedź nie jest odpowiedzią na pytanie. Na marginesie: nie sądzę, aby ktokolwiek tutaj opowiadał się za tym, że taki system jest najlepszą praktyką lub nawet ok, ale tak naprawdę nie jest to temat tutaj.
Teraz odpowiadam ^^, zapomniałem wstawić tę część, ponieważ byłem zajęty pisaniem „dodatkowej części” odpowiedzi. @Selenog
@Selenog iw tym momencie głos przeciw powinien zostać odwołany?
Falantar
2018-12-21 04:45:43 UTC
view on stackexchange narkive permalink

Jak powiedzieli inni, istnieje wiele sposobów, w jakie ten dostawca może zabezpieczyć „ostatnie cztery cyfry” hasła. Jednak KAŻDY raz, kiedy transmitujesz choćby część swojego hasła, otwierasz się na włamanie na swoje konto. Jedną z rzeczy, o których nikt nie wspomniał, są ostatnie 4 cyfry hasła, które wpisujesz w dzienniku czatu, prawdopodobnie nie zostaną zaszyfrowane. Oczywiście dzienniki czatu muszą być łatwo dostępne. Nawet jeśli przestrzegasz podstawowych zasad złożoności haseł, właśnie zmniejszyłeś efektywną długość hasła o 4 znaki. Teraz wyobraź sobie, że jest to hasło, którego używasz w innych miejscach z lżejszymi zabezpieczeniami (co niestety robi wiele osób).

TL: DR To absurdalna praktyka i za wszelką cenę trzymałbym się od nich z daleka

Powiedziałbym, że to widoczny idiotyzm.Niewidoczne idiotyzmy mogą być bardziej problematyczne (na przykład pozwolenie firmie programistycznej na to, co wynajmuje, do rozwijania swojego systemu relacji z klientami, zobaczenie zaszyfrowanych haseł przed ich zaszyfrowaniem).
rocccccc
2015-09-17 22:03:20 UTC
view on stackexchange narkive permalink

Mogą przechowywać skrót całego hasła oraz skrót ostatnich czterech znaków, po którym następuje 12 losowo generowanych znaków. Jeśli sposób generowania losowych znaków jest tak samo bezpieczny jak proces haszowania, powinno to być tak samo bezpieczne, jak samo przechowywanie hasła.

To by nie zadziałało. Jak samodzielnie zweryfikowałbyś ostatnie cztery postacie?
Czy to nie to samo, co zasolenie 4-znakowego hasła z ogona 12 znakami soli? Problem polega na tym, że 4 znaki są tak małe, że sól nie zapobiega przeszukiwaniu brutalnej siły. Więcej soli nadal nie zapobiega brutalnym poszukiwaniom.
Dowolna liczba dodatkowych znaków naprawdę zwiększa absurdalność tej odpowiedzi.


ⓘ
To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...