Pytanie:
Jakie są wady bezstanowych generatorów haseł?
Cookiecutter
2019-07-30 00:13:01 UTC
view on stackexchange narkive permalink

Czy ktoś ma praktyczne doświadczenie w pracy z bezstanowymi generatorami haseł (menedżerami), takimi jak Getpass?

Wygląda na to, że wykonuje większość pracy menedżerów haseł w chmurze, ale opiera się bardziej po stronie bezpieczeństwa, ponieważ nie ma serwerów z hasłami, do których można by się dostać.

Istnieje wiele menedżerów haseł korzystających z pamięci lokalnej.Możesz zsynchronizować je za pomocą własnego wyboru usługi w chmurze (Dropbox, Box, iCloud, Drive, OneDrive itp.) Lub wcale.To zależy od Ciebie
„bardziej opiera się na bezpieczeństwie” - to nie jest uczciwa ocena.Wszyscy skłaniają się ku bezpieczeństwu - tego typu narzędzie ma funkcję, która ogranicza jeden rodzaj ryzyka.
Jeśli nie zależy od stanu, od czego to zależy?Czy zawiera lukę w zabezpieczeniach?
Używam Keepass.Jedną z miłych zalet jest to, że nie przechowuje po prostu moich haseł.Potrafię przechowywać wiele innych danych dotyczących określonego konta, w tym „załączniki”.Oczywiście bezstanowego menedżera haseł nie można używać do niczego innego niż hasła, co dla mnie jest dość dużym ograniczeniem
@Alexander Dropbox niedawno zmienił swój darmowy plan na ograniczenie do 3 urządzeń, kiedyś był idealny do synchronizacji Keepass.iCloud to tylko Apple, Dysk Google to meh, OneDrive jest oparty na Microsoft.
@JMK jest też mega.nz (właściciel został spalony przez FBI w przeszłości i nauczył się lekcji. Teraz jest to usługa paranoiczna, skupiona na prywatności danych użytkowników: nie chcą wiedzieć, co przechowujesz na ichtak, aby nie można ich obwiniać za jej udostępnianie. Jeśli robot indeksujący znajdzie klucz prywatny, automatycznie usunie powiązane dane, nie zaglądając do nich).
Ponadto, jeśli nie ufasz usługom w chmurze, możesz zsynchronizować lokalną bazę danych haseł (np. Z KeePass) między urządzeniami za pomocą programu do synchronizacji, takiego jak Syncthing lub Resilio Sync.
@JMK Udaje mi się utrzymać dokładnie 3 urządzenia i zsynchronizować mój plik KeePass przez dropbox.Ale jest jeszcze jedna wada: klient Androida nie przesyła automatycznie zmienionych plików.Są klienci zewnętrzni, którzy to robią.Dopóki się nie zepsują.
Sześć odpowiedzi:
Benoit Esnard
2019-07-30 00:24:47 UTC
view on stackexchange narkive permalink

Od lat korzystam z bezstanowego generatora haseł i myślę, że ma wiele wad:

  • Jeśli ktoś włamie się do hasła głównego, wszystkie hasła zostaną naruszone. Dla porównania, standardowe menedżery haseł wymagają, aby atakujący zarówno złamał klucz główny , jak i uzyskał dostęp do magazynu haseł.
  • Jeśli witryna ma politykę haseł, możesz nie można wygenerować hasła, które je szanuje.
  • Jeśli jedno z haseł wymaga aktualizacji z jakiegoś powodu, musisz gdzieś zachować ten stan. Na przykład musisz pamiętać o wygenerowaniu hasła dla „StackExchange2” zamiast „StackExchange”.
  • Jeśli masz już hasła, których nie możesz zmienić (z różnych powodów), generator haseł statycznych nie pomoże.

Z tych wszystkich powodów uważam, że zdecydowanie powinieneś używać standardowych menedżerów haseł.

Dziękuję Ci!Więc przełączyłeś się na standardowego menedżera haseł?Wydaje mi się, że wszystko oprócz ostatniego punktu można rozwiązać, wiążąc te dane ze zmienną witryny internetowej
Największą zaletą bezstanowego menedżera haseł jest to, że nie musisz przechowywać dodatkowego pliku.Jeśli mimo wszystko będziesz musiał utrzymywać dodatkowy plik dla wszystkich tych zmiennych specyficznych dla witryny, to w pewnym sensie pokonuje sens używania bezstanowego menedżera haseł.
@LieRyan rzeczywiście.Korzystając z jednego z nich, musisz ręcznie zsynchronizować wszystkie swoje komputery i urządzenia, przenosząc pliki.W najlepszym wypadku w skrajnych przypadkach uciążliwe, w najgorszym poważny problem z bezpieczeństwem i prawdopodobnie niemożliwy (biorąc pod uwagę ograniczenia w bezpiecznych środowiskach dotyczące wprowadzania plików zewnętrznych).
Lat con może być najgorszym z nich wszystkich.Może dobrze byłoby posortować to na górze i podkreślić to bardziej, ponieważ ludzie używają naprawdę okropnych haseł, także dla menedżerów haseł, a podczas gdy menedżer haseł musiałby zostać przejęty (bez bazy danych haseł hasło główne jest bezużyteczne), tutaj kompromitacja klucza byłaby katastrofalna, plus to, że klucz może być brutalnie wymuszony przez dowolnego właściciela witryny, jeśli sobie tego życzy (i jeśli dokonają prawidłowego założenia co do ustawień haszowania hasła, które nie są tajne zgodnie z zasadą Kerckhoffa).
@Luc, ale ostatnia wada nie jest tak duża, ponieważ w większości przypadków zaszyfrowane hasła są przechowywane gdzieś online.I cokolwiek to jest, jest zabezpieczone albo samym hasłem głównym, albo drugim hasłem - które użytkownik musi zapamiętać razem z hasłem głównym (więc w końcu w efekcie wystarczy dłuższe hasło główne, które po kradzieżyumożliwia dostęp do wszystkich haseł)
Używam własnego bezstanowego menedżera haseł (https://vks.ai/ppm) i nie miałem żadnych problemów.Tylko fakt, że gdyby rzeczywiście moje hasło główne zostało kiedykolwiek naruszone, a ludzie są na tyle zaawansowani technicznie, aby je nadużywać.Ale to ryzyko, które jestem gotów podjąć.Rozwiązanie kwestii: do tej pory nigdy nie miałem problemu, w którym moja metoda nie spełniała zasad dotyczących haseł (i używam jej od kilku lat).Fajną rzeczą w StackExchange, a następnie StackExchange2 jest to, że zwykle pamiętasz numer.Ale jeśli tego nie zrobisz, możesz łatwo użyć brutalnej siły w 3 próbach (najwyższa, jaką osiągnąłem, to 5).
@PascalVKooten, możesz rozważyć trzymanie się takiego, który przeszedł odpowiednią kontrolę ... przy obecnej implementacji tęczowe tabele można skonfigurować dla poszczególnych witryn, aby złamać hasło główne
@Qwerty01 Złamanie byłoby zbyt wolne lub zbyt kosztowne - to jest idea powolnej funkcji haszującej, takiej jak scrypt i długie hasło główne.Dzięki temu nie ma sensu próbować ataku tęczy.
@PascalVKooten Istotą tęczowej tabeli jest jednorazowe wykonanie kosztownych obliczeń - jedyną rzeczą, która obecnie uniemożliwia innym, jest to, że Twoja implementacja nie jest wystarczająco szeroko stosowana, aby była opłacalna.
@Qwerty01 Tabele tęczowe są używane tylko wtedy, gdy można ponownie wykorzystać obliczenia, co nie ma miejsca w tym przypadku.Należy jednak pamiętać, że ludzie nie będą próbowali tworzyć tęczowych tabel dla wolnych funkcji mieszających, ponieważ byłoby to po prostu niedrogie.Tak, pomysł brzmi świetnie ... ponowne użycie obliczeń ... ale powolne funkcje haszujące są po prostu zbyt drogie, aby to zrobić (chyba że założysz bardzo krótkie hasła główne).
@PascalVKooten _możesz_ użyć go ponownie w swojej implementacji ... sól, której używasz, to nazwa witryny, więc każdy inny korzystający z tej witryny będzie miał tę samą sól.
@Qwerty01 Tak, ale sól rzeczywiście nie jest tajemnicą.W pełni opiera się na haśle głównym w celu zapewnienia bezpieczeństwa.Powiedzmy więc, że znasz nazwę mojej witryny (i wszyscy jej używają), nadal musisz wykonać tyle kosztownych obliczeń, że nie jest to tego warte.
Pozwól nam [kontynuować tę dyskusję na czacie] (https://chat.stackexchange.com/rooms/96816/discussion-between-qwerty01-and-pascalvkooten).
Re: punkt 3, LessPass (inny bezstanowy menedżer haseł) obsługuje posiadanie opcji, które są zaszyfrowane i używane jako część generacji;jedną z takich opcji jest liczba, którą można zwiększać.Rozwiązują problem „konieczności zapamiętywania”, umożliwiając prowadzenie bazy danych nazw użytkowników / witryn / opcji, ale samo generowanie hasła jest bezstanowe, a baza danych jest tylko wygodą
* „Standardowe menedżery haseł wymagają złamania zarówno zaszyfrowanych haseł, jak i klucza głównego.” * - Nie rozumiem tego.Z pewnością tylko klucz główny musi zostać naruszony (plus może jakikolwiek MFA), ponieważ użytkownik musi tylko wprowadzić klucz główny (+ MFA), aby uzyskać dostęp do zaszyfrowanych haseł.W przeciwnym razie wygląda na to, że standardowe menedżery haseł, z których korzystałeś, wymagają od użytkownika zapamiętania wszystkich haseł, aby uzyskać dostęp do swoich haseł.A może chodziło Ci o to, że osoba atakująca musi zarówno złamać klucz główny, jak i uzyskać dostęp do bazy danych?
@8bittree: Gdybym powiedział ci mój klucz główny, nie możesz nic zrobić, chyba że masz już dostęp do mojej bazy danych zaszyfrowanych haseł: nie możesz odszyfrować czegoś, czego nie masz.Dlatego oba są konieczne!
@BenoitEsnard Zamieszanie dotyczy prawdopodobnie tego, co stanowi „standardowy” menedżer haseł.Lepiej byłoby być bardziej dosadnym, np.„menedżer haseł oparty na plikach”, aby odróżnić go od „menedżera haseł opartego na chmurze”, takiego jak 1Password, w którym uzyskuje się zdalny dostęp do bazy danych.
@BenoitEsnard To ma większy sens.Zaproponowałem zmianę, która moim zdaniem sprawia, że sformułowanie jest bardziej zrozumiałe.
@BenoitEsnard, ale większość ludzi nie kopiuje ręcznie pliku ze swojego menedżera haseł na wszystkie używane urządzenia za każdym razem, gdy rejestrują się na nowej stronie?Plik przechowujesz najprawdopodobniej gdzieś w Internecie, skąd możesz uzyskać do niego dostęp za pomocą hasła głównego.Więc tylko jedna rzecz musi być zagrożona lub masz dużo kłopotów z przesyłaniem plików przez USB.
Sjoerd
2019-07-30 13:04:40 UTC
view on stackexchange narkive permalink

Oto dwa rzadziej wymieniane problemy.

  • Określenie witryny jest trudne. Chcesz użyć innego hasła dla a.github.io i b.github.io, ale chcesz użyć tego samego hasła dla microsoft.com i live.com lub wikipedia.org i wikimedia.org.
  • Zmiana czegokolwiek łamie hasła. Po zwolnieniu menedżera haseł i ludzie zaczną go używać, nie możesz nic w nim zmienić lub użytkownicy nie mogą się już logować. Sposób obsługi domen musi pozostać taki sam, nawet jeśli domeny zmieniają własność. Sposób szyfrowania haseł musi pozostać taki sam, nawet jeśli w algorytmie wykryta zostanie luka.

Zobacz także post na moim blogu na ten temat.

Jeśli wydasz opcjonalną nową wersję, ludzie będą musieli zmienić swoje hasła raz na wszystkich stronach, aby korzystać z nowej wersji.To nie byłoby zabawne, ale można by to zrobić.- Prawdopodobnie zrobiłbym to samo, gdyby moje hasło główne z menedżerem haseł opartym na plikach zostało naruszone (ponieważ plik jest zwykle dostępny gdzieś online)
Kolappan N
2019-07-30 08:47:55 UTC
view on stackexchange narkive permalink

1. Menedżery haseł zapewniają dodatkowe opcje

Główną różnicą między używaniem bezstanowego menedżera haseł a menedżerem haseł jest to, że menedżerowie haseł mogą przechowywać dodatkowe dane, takie jak

  • Bezpieczeństwo Pytania
  • Numery kart kredytowych / debetowych
  • Numery kart identyfikacyjnych
  • Klucze kryptograficzne
  • Hasła Wi-Fi
  • Klucze API itp ...

2. Istniejące hasła nie mogą być obsługiwane.

Menedżerowie haseł mogą obsługiwać istniejące hasła. Jednak bezstanowy menedżer haseł zmusi Cię do zmiany haseł do wszystkich istniejących witryn.

Jest to bardzo ważne, jeśli chcesz przechowywać hasła do dowolnego konta, na którym nie masz uprawnień do zmiany hasła. Może to być wspólna biurowa skrzynka pocztowa, hasło serwera itp ...

3. Deterministyczne generatory haseł nie mogą uwzględniać różnych zasad dotyczących haseł.

Niektóre witryny wymagają obowiązkowych symboli w hasłach, ale niektóre witryny nie pozwalają na używanie symboli w hasłach. Niektóre strony internetowe, takie jak Payback, obsługują tylko numeryczny PIN.

Użytkownicy muszą albo poprawić wygenerowane hasło, albo zmienić ustawienia. W każdym razie muszą zachować w pamięci poprawki lub ustawienia, co nie jest dobre.

W przypadku # 3 należy również zapisać zasady dotyczące haseł podczas tworzenia hasła.Mam co najmniej jedno konto, na którym moje hasło narusza nowe zasady dotyczące haseł, ale stare jest nadal prawidłowe.
Daniel Darabos
2019-07-30 20:16:23 UTC
view on stackexchange narkive permalink

Oprócz tych, o których już wspomniano, jest jeszcze jeden problem: nie możesz zmienić swojego hasła głównego . Przełączenie się na nowe hasło główne wymagałoby zmiany hasła we wszystkich witrynach internetowych, na których korzystałeś z generatora.

MechMK1
2019-07-30 00:45:01 UTC
view on stackexchange narkive permalink

Problem polega na tym, że nie dodaje ono tak znaczących zabezpieczeń.

Zamiast używać hasła bezpośrednio, zamiast hasła używasz publicznie dostępnej funkcji. Posłużmy się przykładem z ich witryny internetowej jako demonstracji:

Login: andromeda
Strona internetowa: milkyway.com
Tajne słowo kluczowe: 2,52 m lat świetlnych stąd

Tworzy hasło: 3q_q(MFWaMGeao+[CX

Możesz powiedzieć 3q_q (MFWaMGeao + [CX to twoje hasło, ale tak naprawdę nie jest. W rzeczywistości jest 2,52 m lat świetlnych stąd , co nie jest zbyt entropiczne. Czy to lepsze niż zwykłe użycie 2,52 m lat świetlnych stąd ? Tak, ale nie aż tak dużo.

Zamiast tego użyj menedżera haseł offline i wygeneruj właściwie losowe hasło. To mniej więcej tyle pracy, ile potrzebujesz, i znacznie bardziej realne bezpieczeństwo.

Cóż, żeby być uczciwym, samo hasło „2,52 m lat świetlnych” nie jest Twoim hasłem.To „2,52 m lat świetlnych stąd” plus wiedza, że używasz Getpass.Przyznając, że drugi składnik jest dość łatwy do brutalnej siły, ponieważ jest to tylko niewielki mnożnik poprzedniego (ponieważ istnieje tylko kilka popularnych algorytmów generowania haseł
@Alexander https: // en.wikipedia.org / wiki / Kerckhoffs% 27s_principle
-1 „to nie zapewnia dodatkowego bezpieczeństwa” nie jest prawdą.Właściwości zabezpieczeń są podobne, a nawet nieco silniejsze niż ogólne haszowanie po stronie klienta (które i tak powinno robić każde oprogramowanie).Nie jest to idealne rozwiązanie, ale też nie jest bezużyteczne.
Zapewnia dodatkowe bezpieczeństwo, pod warunkiem, że Twoje hasło główne * jest * bardzo entropiczne.Bezstanowy menedżer haseł zapobiega (zbyt powszechnej) sytuacji, w której witryna przechowująca hasło w postaci zwykłego tekstu zostaje przejęta, a następnie to samo hasło jest używane do logowania się do innych często odwiedzanych witryn (tak, ponowne użycie hasła jest złe, alezwykły człowiek nie pamięta więcej niż 2 lub 3 haseł o dużej entropii).
@Luc Założę się, że bezpieczeństwo uzyskane dzięki użyciu getpass jest znacznie mniejsze niż przy użyciu faktycznie losowego hasła.
@James_pic Zwalczanie ponownego użycia hasła ** to cały punkt ** korzystania z menedżera haseł.
@MechMK1 tak, i dopóki hasło główne ma wystarczającą entropię, bezstanowy menedżer haseł nadal liczy ponowne użycie hasła.
@James_pic Tak i nie.Jeśli założysz, że hasło / hasło jest wystarczająco silne, aby nie można go było złamać, równie dobrze możesz * użyć tego hasła * do wszystkiego i nie stracić zbyt wiele.Tak, istnieje niebezpieczeństwo, że strony internetowe używają haseł w postaci zwykłego tekstu, ale te szybko znikają.Nawet najgorsi przestępcy używają teraz przynajmniej MD5.
@MechMK1 "* Założę się, że bezpieczeństwo uzyskane dzięki użyciu getpass jest znacznie mniejsze niż użycie faktycznie losowego hasła. *" To nie jest zakład, po prostu masz rację.Losowe jest wyraźnie lepsze niż pochodne.Jednak część Twojej odpowiedzi „to nie zapewnia żadnego dodatkowego bezpieczeństwa” nie jest poprawna, a przynajmniej zawiera więcej niuansów.Używanie hasła w postaci zwykłego tekstu uniemożliwia jego ponowne użycie.Wysyłając solony hash (gdzie nazwa witryny jest solą), masz unikalny token logowania dla każdej witryny.Lepsze niż ponowne użycie hasła, więc zdecydowanie nie „bez dodatkowych zabezpieczeń”.
Więc to jest mój powód do przegłosowania, czuję, że jest to złe do tego stopnia, że może być szkodliwe.Ktoś może nie chcieć używać menedżera haseł (z powodów wykraczających poza zakres tego komentarza), ale może nie mieć problemu z bezstanowym generatorem pwd.Możesz ich zniechęcić i po prostu powiedzieć im, aby zamiast tego używali tekstów jawnych.Więc to nie jest sprawa osobista, a jeśli odpowiedź została zmieniona, aby to odzwierciedlić (zakładając, że rozumiesz logikę mojego punktu), zmieniłbym również głosowanie (zakładając, że widziałem edycję).
@Luc Zmieniłem sformułowanie, aby to odzwierciedlić.Stwierdziłem, że nie dodaje tak dużego bezpieczeństwa, ale nadal jest lepsze niż używanie hasła o niskiej entropii.
Ben
2019-07-31 22:01:44 UTC
view on stackexchange narkive permalink

Jeszcze jedno, o którym nie wspomniałem wprost (pisząc wszystkie istniejące odpowiedzi, również warto zwrócić uwagę):

Jeśli atakujący zdobędzie jedno z Twoich wygenerowanych haseł, może teraz spróbować złamać z niego hasło główne, uzyskać dostęp do wszystkich kont.

Stosunkowo łatwo jest uzyskać jedno hasło o niskiej wartości, czy to poprzez phishing, wycieki haseł w postaci zwykłego tekstu (najwyraźniej nawet Google nie jest na to odporne), keyloggery na publicznym komputerze, otwarte WiFi w witrynach, które nie używają protokołu HTTPS, itp. Cały sens korzystania z menedżera haseł polega na tym, że złe zabezpieczenia jednej witryny nie powinny zapewniać żadnej korzyści atakuje Cię w innej witrynie.

Jasne, wystarczająco silne hasło główne może zapobiec temu problemowi. Ale „tradycyjny” menedżer haseł w ogóle nie ma takiego wektora ataku.

+1 To jedyna wada, która naprawdę ma znaczenie.Wszystkie inne to zwykłe niedogodności.
Zasadniczo zgadzam się, ale ** jeśli ** hasło główne jest wystarczająco silne _ i_ menedżer haseł używa dobrej funkcji jednokierunkowej (najlepiej funkcji haszowania haseł, takiej jak scrypt lub coś podobnego), to nie powinno być łatwe / w stanie złamać-siła.To powiedziawszy, jest to ta sama dyskusja na temat tego, dlaczego zwykle haszujemy hasła na serwerach.Jedyna różnica polega na tym, że: kontrolujesz / znasz czynniki, które przyczyniają się do tego i możesz (teoretycznie) oszacować, czy atak siłowy zakończy się sukcesem.


ⓘ
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 4.0, w ramach której jest rozpowszechniana.
Loading...