Nie i absolutnie, kurwa, nie.Kontekst artykułu polega na logowaniu się do danych uwierzytelniających Google za pomocą hasła. „Wielka trójka”, a także kilka innych, oferuje depozyt kluczy i odzyskiwanie, ale witryny używają kluczy bezpośrednio - jeśli używasz klucza dostępu w Best Buy, nie będą na przykład sprawdzać w Google (chyba że użyjesz „logowań społecznościowych”) kurs). W tym kontekście wyczyszczenie konta przez Google oznacza po prostu, że w przypadku awarii telefonu sytuacja może stać się niebezpieczna. Są to w zasadzie klucze yubikey z opcją odzyskiwania - więc nieco mniej bezpieczne, ponieważ istnieje klucz prywatny w escrow, co rozwiązuje 50% problemu z yubikeys (pozostała cena i obsługa aplikacji ból).Każdy system, który wydaje się być w stanie przechowywać klucze, wydaje się wymagać zaufania wielkiej trójki (Apple, Google, Microsoft), aby nie usuwać konta bez ostrzeżenia. W moim przypadku, jeśli Apple usunie moje konto iCloud i pęk kluczy, stracę dostęp do wszystkiego, co jest zabezpieczone hasłem. Porównaj to z tym, co dzieje się teraz, jeśli zniszczę mojego głównego Yubikey: idę do swojego banku, pokażę im dwa formularzy identyfikacyjnych, użyj mojego klucza fizycznego, aby odzyskać kopię zapasową Yubikey z sejfu i ruszaj dalej życie.
Dopóki nie wystąpią poważne i trwałe konsekwencje dla przedsiębiorstw świadczących usługi infrastrukturalne, które działają jednostronnie, nie ma mowy, żebym z tego skorzystał. KeyPass/BitWarden może generować dowolnie silne hasła. Możesz kupić dowolną liczbę kluczy Webauthn od różnych dostawców. Dzięki kluczom jedno (automatyczne, niepodlegające negocjacjom) usunięcie dzieli Cię od trwałego zablokowania dostępu do całego Twojego życia online.
Jeśli chcesz przekazać tę władzę firmie, bądź moim gościem. Poczekam, aż zostanie to potraktowane jak odcięcie świadczenia usług przez wodociągi lub elektrownie bez wyraźnego powodu: duże i dotkliwe kary.
Nie jestem pewien, czy rozumiem, jak wymaga tego przepływ pracyJeśli kopiujesz i wklejasz hasła (lub wpisujesz je z pamięci, co powoduje inne problemy na dużą skalę), jesteś podatny na ataki typu phishing. Zatem hasła byłyby dla Ciebie dużym ulepszeniem bezpieczeństwa.
chwytając za telefon,
dotknięcie aplikacji,
zrobienie zdjęcia ekranu i
stukając, co zrobić z tymi informacjami......jest operacją „łatwiejszą” niż wprowadzanie hasła z pamięci, automatyczne uzupełnianie za pomocą menedżera haseł lub kopiowanie i wklejanie za pomocą menedżera haseł.
Mogą istnieć inne korzyści, ale w żadnym wypadku nie jest to łatwiejsze.
W przypadku mojego konta Google ponownie zarejestrowałem klucze YubiKeys, których używałem jako 2FA, jako klucze dostępu. W przypadku 2FA uwierzytelnieniem było hasło Google + klucz sprzętowy FIDO U2F. W przypadku kluczy jest to klucz sprzętowy FIDO2 + PIN FIDO2 klucza.
Żadna z „wielkiej trójki” firm technologicznych nie będzie opiekunem Twoich kluczy. Klucze są przechowywane na urządzeniu. Jeśli nie chcesz synchronizować swojego hasła za pośrednictwem jakiejś usługi, umieść to samo hasło na wielu urządzeniach. Masz tylko jedno urządzenie A teraz go nie ma? To ten sam problem, co menedżery haseł bez synchronizacji. Na koniec będziesz musiał ponownie uwierzytelnić się w różnych usługach, tak jak w każdym podobnym przypadku zablokowania. Większość ludzi synchronizuje swoje klucze tak samo, jak hasła. I nie, jeśli Google zamknie Twoje konto, nie będzie mogło wyłączyć kluczy, które już masz na swoich urządzeniach. Stracisz usługę synchronizacji, ale zamiast tego możesz zacząć korzystać z innej.
Kluczy dostępu nie można wyłudzić, nie można ich zapomnieć, nie można ich zdobyć w wyniku wycieku danych, a ponadto są z natury unikalne i bezpieczne. To naprawdę duże ulepszenia. Są również łatwiejsze w użyciu, ponieważ po umieszczeniu ich na urządzeniu uwierzytelnianie jest proste.
Używam do tego Yubikey, a nie Androida czy iOS. Oznacza to, że nie jestem zobowiązany wobec Google/Apple do zarządzania moim kluczem ani nie muszę się martwić, że moje konto zostanie naruszone i w ten sposób wycieknie klucz.
Dla porównania do logowania do konta Google, od jakiegoś czasu używam tego Yubikey do uzyskiwania dostępu do mojego konta Microsoft.
Microsoft działa we wszystkich głównych przeglądarkach na komputerach stacjonarnych (z wyjątkiem Safari na MacOS, kiedy ostatnio sprawdzałem). Wygląda na to, że Google potrzebuje przeglądarki Chrome.
Microsoft ma opcję poniżej pola nazwy użytkownika, aby zalogować się w inny sposób, następnie wybierz Windows Hello lub Klucz zabezpieczeń, włóż klucz do portu USB, wprowadź kod PIN i naciśnij przycisk na górze. Następnie zapyta Cię, które konto (jeśli masz zapisanych wiele kont) i od razu się zalogujesz. Nie musisz nawet pamiętać swojej nazwy użytkownika ani adresu e-mail.
Google wymaga podania nazwy użytkownika/adresu e-mail, a następnie prosi o włożenie klucza. Następnie musisz wprowadzić PIN, który Cię zaloguje.
Z punktu widzenia użyteczności Microsoft jest lepszy, ponieważ nie musisz pamiętać swojego adresu e-mail. Dla tłumu Ars jest to prawdopodobnie negatywne. Ale jeśli wspierasz 70-letnich dziadków, im mniej rzeczy muszą pamiętać, tym lepiej. Nie potwierdziłem, ale wadą systemu MS jest to, że Yubikey obsługuje tylko określoną liczbę przechowywanych danych uwierzytelniających, podczas gdy z tego, co widziałem w moich badaniach, metoda Google zasadniczo polega na tym, że Yubikey generuje klucz prywatny specjalnie dla tej witryny na wewnętrznym kluczu prywatnym, Twoim PIN-ie i niektórych informacjach dostarczonych przez witrynę i przeglądarkę, za każdym razem, gdy konieczne jest uruchomienie uwierzytelnianie. Obydwa wydają się używać wewnętrznego klucza prywatnego specyficznego dla Yubikey, Twojego PIN-u, niektórych informacji o domenie dostarczanej przez przeglądarkę i specyficznych informacje dostarczane z odwiedzanej witryny w celu przeprowadzenia uzgadniania, co uniemożliwia powodzenie ataków MITM, ponieważ nie mogą one tego wszystkiego sfałszować dane.
Nie jestem pewien, czego brakuje w Firefoksie w implementacji Google w porównaniu z implementacją Microsoftu, dlaczego nie obsługuje nowego systemu kluczy dostępu. A może po prostu Google nie żąda hasła, ponieważ Firefox nie zaimplementował części Bluetooth, która ma efekt uboczny braku obsługi tokenów Yubikeys/sprzętowych, ponieważ Firefox nie jest o to pytany przez login Google strona.
--
Jeśli zgubisz hasło i nie masz zapasowego klucza, rozwiązaniem zabezpieczającym jest zalogowanie się w sposób, w jaki logowałeś się przed podaniem hasła. Zwykle hasło + OTP. Chociaż oznacza to, że witryna obsługuje mniej bezpieczny system uwierzytelniania, jedną z korzyści jest to, że tak nie jest regularne używanie hasła, dzięki czemu prawdopodobieństwo jego wycieku lub przechwycenia przez phishing/MITM jest mniejsze atak.
--
Z punktu widzenia bezpieczeństwa klucze można postrzegać jako portfel haseł z ograniczoną obsługą witryny. Jeśli korzystasz z Yubikey, portfel jest urządzeniem sprzętowym w Twojej kieszeni, chronionym kodem PIN. Jeśli korzystasz z hasła do systemu Android/iOS, portfel jest synchronizowany w systemie chmurowym i chroniony hasłem do konta oraz danymi biometrycznymi. Jeśli zgubisz urządzenie, będzie to podobne do utraty pliku z hasłami.
Kiedy już rozwiążą wszystkie problemy, może to potencjalnie zmienić wiele rzeczy w krajobrazie bezpieczeństwa, ponieważ osoby nieświadome bezpieczeństwa to zrobią nie musisz już opierać się wymaganiom dotyczącym bezpiecznych haseł ani zastanawiać się, jak prawidłowo korzystać z portfela haseł oraz jak uzyskać do niego dostęp/synchronizować go na wielu urządzenia. Zasadniczo stają się portfelem haseł, klucze generują naprawdę bezpieczne, naprawdę losowe hasła dla każdej witryny, w której są używane, i są tworzone z myślą o odporności na phishing.
Jak to może zostać zminusowane? To w 100% prawda.
Jego Kto, nie Co Na pierwszej stronie. Żadnej miłości do Google na pierwszej stronie, tak że ich wsparcie zwróciło tłum przeciwko standard branżowy.
To jest głupie.
Jeszcze raz, czytelnicy, nie zwracajcie uwagi na tych komentatorów.
Używanie hasła nie powinno być odpowiedzią na coś, co ma zastąpić hasła.
To trochę śmieszne. Jak inaczej uwierzytelniłbyś się w istniejącej usłudze aby zaktualizować mechanizm uwierzytelniania? Oprócz omówionej już metody QR i Bluetooth. I chociaż powierzchnia ataku po stronie serwera niekoniecznie zostaje zmniejszona poprzez umożliwienie logowania za pomocą hasła, a nie wymaganie go, to jednak znacznie zmniejsza powierzchnię ataku po stronie klienta, ponieważ ściśle angażujesz się w wymianę kluczy, włączoną przez uwierzytelnianie na poziomie systemu operacyjnego. I to jest zwycięstwo dla wszystkich.
Jeśli dojdziesz do tego stopnia, że nie możesz ufać żadnej funkcji zabezpieczeń swojego systemu operacyjnego, równie dobrze możesz po prostu wyrzucić swoje urządzenia komputerowe i zamieszkać na tropikalnej wyspie lub coś takiego. Na jakiś punkt należy obdarzyć jakimś fragmentem oprogramowania pewnym poziomem zaufania.
Myślę, że panuje tu duże zamieszanie, ponieważ zrzucono na nas cały stos technologii i przedstawiono go jako fakt dokonany. Pozwólcie, że jako ignorant spróbuję to zdekonstruować przez analogię do tego, co rozumiem: pary kluczy SSH. Zachęcam innych, aby wytykali dziury w tym, co robię źle.1. Klucze uwierzytelniające publiczne/prywatne. Działa to mniej więcej tak samo jak SSH. Witryna zna tylko Twój klucz publiczny, a Ty podpisujesz wiadomości potwierdzające, że posiadasz klucz prywatny.
2. Ochrona przed phishingiem. Klucze są specyficzne dla witryny, więc witryna phishingowa otrzymuje inny klucz. SSH ma do tego klucze hosta, zakładam, że keypass używa czegoś wspólnego z kluczami hosta TLS? Twoja przeglądarka używa tego, aby wybrać, którego klucza użyć? Lub po prostu według nazwy DNS?
3. Sposoby odblokowania kluczy w celu sprawdzenia, czy używa ich właściwy użytkownik. SSH ma hasła, zakładam, że tu właśnie pojawia się kwestia biometryczna/Bluetooth? SSH może również odblokowywać klucze za pomocą kart inteligentnych, więc zakładam, że biometria przypomina trochę inny tryb odblokowania?
4. Synchronizowanie kluczy pomiędzy urządzeniami. Prawdopodobnie w tym miejscu pojawiają się „ekosystemy” chmur, takie jak synchronizacja haseł iCloud i Chrome? W przypadku protokołu SSH nie ma obsługi, ale możesz przygotować własny za pomocą rsync lub czegoś innego?
Co zrobiłem źle?
Jeśli powyższe jest w dużej mierze słuszne, mogę sobie wyobrazić zbudowanie otwartego stosu, który zasadniczo robi to samo, co SSH, używając stosu plików w ~/.ssh i rsync do przemieszczania się między urządzeniami. To podejście „rowerowe”, w którym wszystkie ruchome części są odsłonięte i łatwe do zrozumienia, co się dzieje.
Nie jest to tylko zrzucanie na ludzi – jest to aktualizacja FIDO2, która sama w sobie jest drugą wersją standardu. U2F to FIDO1; to jest CTAP 2.2 ([edytuj: poprawiono z mojego WAG 2.4, który był błędny, dzięki Nadal niepoprawny!]), część FIDO2/WebAuthn. To naprawdę nie jest nic skomplikowanego, jeśli chodzi o... złagodzili wymagania Authenticatora, aby klucz prywatny mógł być (musi być...) bezpiecznie skopiowany, i dodali kilka funkcji JavaScript, aby ułatwić życie. Logowanie bez hasła? Zawsze było to możliwe dzięki FIDO2. To właśnie jest fajna część - FIDO1 może być tylko MFA. Dodajesz do przeglądarki klucz prywatny zapisany w TPM lub bezpiecznym elemencie? Zawsze było to możliwe i zostało wcześniej zaimplementowane w przeglądarkach Chrome, Firefox i Safari. Nowością jest to, że można go zsynchronizować i uzyskać do niego dostęp za pośrednictwem mechanizmu BT/QR. Wcześniej nazywano je (i oznaczano na stronach internetowych) „kluczami specyficznymi dla platformy”, w przeciwieństwie do kluczy przenośnych, które były urządzeniami sprzętowymi. Teraz są to klucze dostępu.
Ponieważ wydaje się, że celem systemu kluczy jest pozbycie się haseł, pozwólcie, że wymienię niektóre zalety haseł:
- są wystarczająco proste do zrozumienia dla każdego, kto jest w stanie obsługiwać urządzenie elektroniczne
- łatwo je zapamiętać, jeśli włożysz choć trochę wysiłku i regularnie z nich korzystasz
- działają na wszystkich systemach operacyjnych od razu po wyjęciu z pudełka
- nie wymagają dostępu do Internetu (niektóre systemy są offline nie bez powodu)
- nie wymagają współpracy osób trzecich
- nie wymagają obecności smartfona ani innego gadżetu
- nie wymagają Bluetooth, Wi-Fi, kamer ani baterii
- można je - w sytuacji awaryjnej - przechowywać bez konieczności korzystania z prądu
- można je łatwo przenieść na inną osobę bez użycia jakiegokolwiek urządzenia
- jeśli nie jesteś niepełnosprawny i nie korzystasz ze smartfona, uwierzytelnienie za pomocą hasła zajmie tylko kilka sekund
Twoje punkty #1, #2 i #10 są po prostu błędne – zapytaj każdego, kto pracuje w dziale pomocy technicznej, jak często musi resetować hasło, ponieważ ktoś zapomniał hasła, zostawił włączony klawisz Caps Lock (lub źle ułożył rękę na klawiaturze) lub machnął nim palcami krówki wystarczająco dużo razy, aby został zablokowany na zewnątrz. Tak, tak, wiem, że osobiście zawsze wszystko układasz perfekcyjnie, ale zaufaj mi, każdy, kto otrzymuje telefony do pomocy technicznej, ma… mniej optymistyczny… pogląd na ludzkość. Dodam też, że wspieram wielu niewidomych użytkowników i wpisywanie haseł masywnie jest to dla nich do bani, ponieważ wiele witryn ma wymagania dotyczące złożoności, które są trudne dla użytkowników czytników ekranu, a jeśli nie jesteś biegłą maszynistką, mówienie tego na głos nie jest świetne. To nisza, ale wiele osób tworzących systemy uwierzytelniania również musi dobrze wspierać, i jest to jeden z powodów, dla których mnie interesuje technologię od „Czy chcesz zalogować się przy użyciu swojego hasła?” „Tak” jest dla wielu co najmniej o jeden rząd wielkości szybszy i łatwiejszy niż jakakolwiek forma hasła + MFA użytkownicy.
Punkt 3 dotyczy WebAuthn MFA, ale zawsze hasła – coś w rodzaju Yubikey działa wszędzie tam, gdzie masz USB/NFC, ale możesz trzeba ustawić kod PIN lub użyć kluczy biometrycznych w przypadku narzędzi wdrażających klucze, takich jak Google.com, które wymagają czegoś więcej niż prostego uzyskiwać.
Punkty #5, #6, #7 i #8 dotyczą także wszystkich form WebAuthn – zarówno MFA, jak i kluczy dostępu. Punkt nr 4 jest prawdziwy, z wyjątkiem pierwszej rejestracji urządzenia podczas synchronizacji istniejącego klucza. Po pierwszej synchronizacji kluczy nie potrzebujesz połączenia sieciowego. Jeśli nie chcesz synchronizować, możesz także kupić kilka kluczy biometrycznych Yubikey, które ponownie działają w pełni offline, gdziekolwiek masz USB lub NFC.
Pozostaje punkt 9, który jest złą praktyką i należy go unikać, jeśli to w ogóle możliwe. Nowoczesne systemy oferują takie rozwiązania, jak uwierzytelnianie oparte na rolach, w przypadku którego ludzie nigdy nie udostępniają haseł, ale daną rolę może przyjąć wiele osób, lub takie rozwiązania, jak starsze lub delegowane konta, w przypadku których nigdy już nie będziesz udostępniać haseł, ale dasz jednej lub, jeszcze lepiej, wielu osobom wymaganym w połączeniu możliwość zrobienia czegoś takiego, jak zresetowanie hasła lub przejęcie kontroli Twoje pliki.
To, że coś jest nowe i nie wiesz, jak to działa, nie oznacza, że jest złe lub należy tego unikać. Klucze to dla większości z nas duża zmiana – z wyjątkiem domeny .gov, ponieważ PIV/CAC sięga tam poprzedniego stulecia, nawet jeśli w kilku innych miejscach przyjęli go – ale oprócz korzyści związanych z bezpieczeństwem wprowadzono w nich szereg ulepszeń w zakresie użyteczności i istnieje jasna ścieżka rozwoju niektóre brakujące części (np. naprawdę chcę mieć możliwość zsynchronizowania hasła Apple/Google z Yubikey, aby móc wrzucić je do sejfu sprawa).
Oczywiście musi być dostępny nie tylko podczas synchronizacji, ale także podczas uwierzytelniania, ponieważ do tego służy. Musi być także dostępny podczas pierwszej rejestracji.I to właśnie próbuję ci wyjaśnić: łatwo byłoby uwierzytelnić się na istniejącym urządzeniu i używać go urządzenie, aby dodać kolejny klucz publiczny, który jest generowany na innym, nowym urządzeniu i przez niektórych wysyłany do starego urządzenia oznacza. Mógłbym na przykład utworzyć nową parę kluczy tajny/klucz publiczny na komputerze stacjonarnym, wysłać klucz publiczny do laptopa, zalogować się na nim i dodać klucz publiczny komputera stacjonarnego. Cały czas robię podobne rzeczy z SSH.
Nie ma tu żadnych przeszkód technicznych. Jeśli nie jest to możliwe w przypadku kluczy dostępu, jest to wybór.
Klucz prywatny jest niedostępny. Dlaczego by tego nie sprawdzić, zamiast w kółko powtarzać kłamstwa.
A teraz jestem bardziej zdezorientowany niż zanim zacząłem – wysłałem artykuł do mojej głównej/lepszej połowy CS, aby wyjaśnić pewne rzeczy, ale to może nie wystarczyć.
Hasła są łatwo przyswajalne. 2FA jest łatwe do wyjaśnienia. Hasła mają sens, ale kiedy już myślę, że uda mi się je zdobyć, czytam następny akapit i jeszcze bardziej się gubię.
Niebo pomóż mojemu rodzeństwu i rodzicom.
Dzięki za te słowa. Odpowiedzi Dana i innych osób (np. @Wbdpromowany komentarz cytujący mój) opiera się na zasadniczym błędnym odczytaniu komentarza.Zdajesz sobie sprawę, że zarówno 1Password, jak i Bitwarden pracują nad obsługą kluczy, prawda?Nie chcę powierzać mojemu dostawcy systemu operacyjnego (w moim przypadku Apple zarówno dla urządzeń mobilnych, jak i stacjonarnych) kluczami, a odpowiedź brzmi: „Ale ty JUŻ ZAUFAJ GOOGLE SWOIM HASŁEM.” Tak, dobrze, wprowadzam długie, losowe hasło z BitWarden/KeePass, podłączam Yubikey i naciskam przycisk. W żadnym momencie nie jest to zależne od mojego dostawcy systemu operacyjnego.
I oczywiście, w tej chwili istnieje możliwość nieużywania kluczy i używania hasła tak jak poprzednio, ale cały szum technologiczny zmierza w stronę „KONIEC WIĘCEJ HASŁÓW DLA KAŻDY” i jeśli powiem: „ale poczekaj, jeśli zostanę zablokowany na każdym innym koncie, ponieważ mój dostawca systemu operacyjnego uzna, że mnie nie lubi, co się stanie”, zostanę nazwany trollem i źle poinformowany. Jest też wiele skrajnych przypadków, w których to nie działa, i zamiast mówić: „tak, te są uzasadnionymi obawami w przyszłości opartej wyłącznie na kluczu dostępu, jakiej pragniemy”, istnieje ciągła krytyka każdego z nich pytający.
Firma 1Password posunęła się nawet do stwierdzenia, że klucze dostępu to „przyszłość uwierzytelniania”: https://www.future.1password.com/passkeys/
