Próbowałem przejść na korzystanie z passkey bez haseł, oto dlaczego w praktyce to się nie sprawdziło

Hasła zawsze były problemem w utrzymaniu. Albo je pamiętasz i ryzykujesz ich ponowne użycie, albo przechowujesz je gdzie indziej i polegasz na dostępności tego systemu w dokładnym momencie, kiedy potrzebujesz dostępu. Klucze dostępu stosują inne podejście, w którym uwierzytelnianie opiera się na kryptografii klucza publicznego, gdzie klucz prywatny pozostaje na twoim urządzeniu i nigdy go nie opuszcza.

Zdecydowałem się używać kluczy dostępu wszędzie tam, gdzie były obsługiwane i polegać na uwierzytelnianiu opartym na urządzeniu we wszystkich kontach. Pomysł polegał na tym, aby przestać zarządzać poświadczeniami jako czymś, o czym muszę w ogóle myśleć. To, co nastąpiło, pokazało, ile z obecnego ekosystemu wciąż oczekuje, że hasła będą istnieć gdzieś w tle.

Konfigurowanie rzeczy wydaje się proste

Prosta konfiguracja ukrywa późniejszą złożoność

Na nowoczesnym urządzeniu włączenie klucza dostępu jest proste. Otwierasz ustawienia konta, wybierasz opcję, potwierdzasz swoją tożsamość, a system zapisuje dane uwierzytelniające. Nie ma żadnego ciągu do zapisania ani skopiowania, a proces bardziej przypomina odblokowywanie telefonu niż logowanie się do usługi.

Ta część działa dobrze, nie przeszkadza i nie przyciąga uwagi, co dokładnie powinno robić uwierzytelnianie.

Rzeczy się zmieniają, gdy używasz więcej niż jednego urządzenia

Synchronizacja szybko staje się niejasna

Pierwszy problem pojawia się, gdy przechodzisz poza jedno urządzenie. Klucze dostępu są opisywane jako dostępne na różnych urządzeniach, ale to zależy od tego, jak są przechowywane.

W jednym systemie klucz dostępu jest powiązany z systemem operacyjnym i synchronizowany przez jego konto w chmurze. W innym jest przypisany do profilu przeglądarki. Każdy model działa samodzielnie, ale nie łączą się w jeden spójny system. Utrudnia to odpowiedzenie na podstawowe pytanie bez zastanowienia: gdzie znajduje się te dane uwierzytelniające i jak mogę ich użyć gdzie indziej?

Logowanie czasami zależy od tego, co masz w pobliżu

Dostępność urządzeń kształtuje dostęp

Używanie kluczy dostępowych na różnych urządzeniach wprowadza procesy wymagające koordynacji między nimi. Logowanie na komputerze stacjonarnym często oznacza potwierdzenie tej akcji na telefonie, który już posiada poświadczenie.

Działa, ale zakłada, że telefon jest dostępny. Jeśli nie jest, proces staje się mniej przewidywalny, ponieważ niektóre usługi przechodzą na inne metody, podczas gdy inne pozostawiają cię z koniecznością znalezienia innej drogi. To uzależnienie staje się bardziej zauważalne z czasem, zwłaszcza gdy jedyne urządzenie, którego potrzebujesz, nie jest w zasięgu.

Odzyskiwanie nadal opiera się na starszych systemach

Ścieżki kopii zapasowych pozostają skoncentrowane na hasłach

Ścieżka odzyskiwania ujawnia, od czego faktycznie zależy system. Przetestowałem to, symulując utratę dostępu do mojego głównego urządzenia.

W teorii, klucze dostępu mogą być przywracane poprzez zsynchronizowane kopie zapasowe. W praktyce zależy to od pozostawania w ramach jednego ekosystemu. Przemieszczanie się między platformami komplikuje ten proces.

Większość usług nadal polega na tradycyjnych metodach odzyskiwania. Weryfikacja e-mail, kody SMS, kody zapasowe, a czasami opcja ponownego ustawienia hasła. Są one częścią normalnego procesu, a hasła nadal istnieją, choć są mniej widoczne. Poproszono mnie o zalogowanie się hasłem przed użyciem klucza bezpieczeństwa w innym systemie przez Google:

Wsparcie nie jest spójne w różnych usługach

Implementacja jest bardzo zróżnicowana

Klucze dostępu nie są wdrażane w ten sam sposób wszędzie. Niektóre usługi pozwalają w pełni na nich polegać. Inne traktują je jako dodatkową opcję obok istniejących metod.

To prowadzi do niespójnego działania, ponieważ to samo konto może zaakceptować klucz dostępu w jednej przeglądarce, a w innej wymagać hasła.

Z perspektywy użytkownika przyczyna jest mniej ważna niż rezultat. Doświadczenie zmienia się w zależności od tego, gdzie i jak się logujesz.

Interfejsy nie zawsze wyjaśniają rzeczy

Niejasność podczas procesów uwierzytelniania

Uwierzytelnianie zależy od przejrzystości i musisz wiedzieć, co jest używane do weryfikacji twojej tożsamości. Klucze dostępu wprowadzają komunikaty, które różnią się w zależności od platformy.

Niektórzy wspominają o kluczach dostępu bezpośrednio, a inni używają bardziej ogólnego języka, takiego jak klucz dostępu lub logowania. Różnica ma znaczenie, gdy coś nie działa zgodnie z oczekiwaniami. Kiedy logowanie się nie powodzi, trudniej jest zrozumieć dlaczego. System ukrywa złożoność, co jest pomocne większość czasu, ale także usuwa sygnały, które pomagają rozumować nad problemami.

Ponadto hasła są łatwe do przenoszenia między systemami, ale klucze dostępu są zaprojektowane inaczej. Klucz prywatny pozostaje na urządzeniu, a bezpośredni dostęp jest ograniczony. Zamiast eksportować dane uwierzytelniające, polegasz na synchronizacji w ramach platformy. Działa to, jeśli pozostajesz w tym środowisku, a staje się ograniczające, gdy próbujesz przemieścić się poza nie.

Mniej popularne konfiguracje pokazują luki

Przypadki graniczne ujawniają punkty tarcia

Doświadczenie jest płynniejsze na popularnych platformach, takich jak GitHub (chociaż ma też problemy, o których właśnie wspomniałem powyżej), ale staje się mniej niezawodne w mniej popularnych konfiguracjach. Logowanie się z systemu Linux o niestandardowej konfiguracji ujawniło problemy, które nie pojawiały się w innych miejscach.

Opcja klucza dostępu istniała, ale zależała od komponentów, które nie były w pełni zsynchronizowane. Proces się rozpoczynał, a następnie kończył niepowodzeniem bez użytecznego sprzężenia zwrotnego. Te przypadki nie są głównym celem projektowania klucza dostępu, ale mają znaczenie dla każdego, kto nie pozostaje w ramach jednego ekosystemu.

Konta współdzielone nie pasują jeszcze idealnie do kluczy dostępu

Wspólne loginy psują model

W mojej własnej konfiguracji wiele użytkowania jest nadal współdzielone. W przypadku haseł jest to w praktyce proste, nawet jeśli nie jest to zbyt bezpieczne. Tak właśnie rzeczy są używane w gospodarstwach domowych, niezależnie od tego, jak model konta powinien wyglądać na papierze. Klucze dostępu nie odpowiadają w łatwy sposób temu zachowaniu. Zostały zaprojektowane tak, aby były powiązane z konkretnym urządzeniem i tożsamością, co utrudnia bezpośrednie udostępnianie w naturalny sposób.

Niektóre ekosystemy, takie jak system haseł i kluczy Apple, umożliwiają udostępnianie poprzez iCloud Keychain, ale tylko między użytkownikami w ekosystemie Apple. W moim przypadku używam Bitwardena, który również obsługuje udostępnianie poprzez kolekcje i funkcje organizacyjne, ale znowu działa to płynnie tylko wtedy, gdy wszyscy zaangażowani korzystają z tej samej konfiguracji sejfu i kompatybilnych klientów. Poza tym udostępnianie staje się fragmentaryczne lub wymaga powrotu do starszych metod.

Częściowe przyjęcie odzwierciedla aktualną rzeczywistość

Klucze dostępu oparte są na solidnym modelu, ale w praktyce są nakładane na systemy, które wciąż w pewien sposób zależą od haseł, co trudno jest ominąć. Procesy pracy, mechanizmy odzyskiwania, a nawet podstawowe oczekiwania dotyczące logowania nadal zakładają, że gdzieś w tle istnieje hasło. Zamiast zastępować ten model, klucze dostępu często kończą współistnieć z nim w sposób, który wprowadza więcej złożoności, niż ją usuwa.

Po kilku tygodniach przestałem próbować wymusić w pełni bezhasłowe ustawienie. Zachowałem klucze dostępu tam, gdzie działały konsekwentnie, ale także przywróciłem hasła w miejscach, gdzie pojawiały się problemy lub stawało się to nieprzewidywalne. Pełna adopcja brzmi świetnie w teorii, ale w przypadku wielu usług i urządzeń nadal nie sprawdza się niezawodnie przy codziennym użytkowaniu.