Jak zwykle weź wszystko, co dotyczy Stevea Gibsona z ciężarówką pełną soli. Obowiązkowy link attrition.org .

Przyjrzyjmy się opisowi protokołu Gibsona.

• Kod QR przedstawiony obok loginu zachęta zawiera adres URL usługi uwierzytelniania witryny. Adres URL zawiera bezpiecznie wygenerowaną długą losową liczbę, dzięki czemu każda prezentacja strony logowania zawiera inny kod QR. (W kręgach kryptograficznych ta długa, losowa liczba jest nazywana „nonce”).

• Aplikacja do uwierzytelniania SQRL na smartfonie szyfruje w sposób kryptograficzny nazwę domeny witryny wpisanej przez użytkownika ”, aby utworzyć parę kluczy publicznych specyficznych dla witryny.

• Aplikacja podpisuje kryptograficznie cały adres URL zawarty w kodzie QR przy użyciu klucza prywatnego właściwego dla witryny. Ponieważ adres URL zawiera bezpieczną, długą, losową liczbę (numer jednorazowy), podpis jest unikalny dla tej witryny i kodu QR.

• Aplikacja wysyła bezpieczne zapytanie HTTPS POST do kodu QR URL kodu, który jest usługą uwierzytelniającą dla witryny. POST zapewnia klucz publiczny właściwy dla witryny i pasujący podpis kryptograficzny adresu URL kodu QR.

• Uwierzytelniająca witryna internetowa odbiera i potwierdza zapytanie POST, zwracając standardowe HTTP „200 OK” bez innych treści. Aplikacja SQRL potwierdza pomyślne przesłanie kodu QR podpisanego przez użytkownika.

• Witryna uwierzytelniająca ma adres URL zawierający numer jednorazowy, który wrócił ze strony logowania za pośrednictwem adresu użytkownika smartfon. Zawiera również podpis kryptograficzny tego adresu URL oraz klucz publiczny użytkownika witryny. Używa klucza publicznego, aby sprawdzić, czy podpis jest ważny dla adresu URL. Potwierdza to, że użytkownik, który złożył podpis, użył klucza prywatnego odpowiadającego kluczowi publicznemu. Po zweryfikowaniu podpisu witryna uwierzytelniająca rozpoznaje uwierzytelnionego użytkownika na podstawie jego klucza publicznego właściwego dla witryny.

Największą rzeczą, która wyskakuje na mnie, jest użycie przez użytkownika ” klucza głównego „. Jeśli poprawnie czytam protokół, ten pojedynczy klucz główny kontroluje całą tożsamość online użytkownika …

Przypuszczalnie ten klucz główny jest przechowywany w telefonie użytkownika w bazie danych aplikacji. To otwiera ogromny wektor ataku w postaci złośliwego oprogramowania zaprojektowanego specjalnie do kradzieży klucza głównego.

Porównajmy więc różnicę między tym, co dzieje się, gdy hasło zostaje naruszone, a tym, co dzieje się, gdy klucz główny Zakładając, że postępujesz zgodnie z dobrymi praktykami dotyczącymi haseł długich, unikalnych i wysoce losowych haseł przechowywanych w menedżerze haseł, wszystko, co musisz zrobić, to zmienić jedno hasło, jeśli zostanie naruszone. Co się stanie, jeśli Twój klucz główny zostanie naruszony? będzie musiał w jakiś sposób uzyskać wszystkie witryny, z którymi się uwierzytelniłeś, aby rozpoznać, że ktoś włamał się do Twojego klucza głównego. Jedyny problem polega na tym, że nie masz żadnych innych sposobów uwierzytelnienia w witrynie, takich jak nazwy użytkowników lub adresy e-mail, skąd witryna będzie wiedziała, że to Ty próbujesz unieważnić klucz główny?

Jak wszystko, co pochodzi od Gibsona, ten schemat SRQL jest wysoce wadliwy i nie oferuje żadnych korzyści w porównaniu z konwencjonalnymi metody.

Comme nts

• ” Jeśli ' przestrzegasz dobrych praktyk dotyczących haseł ” to ogromne zastrzeżenie, a większość internautów ' tego nie robi.Częścią obietnicy SQRL ' jest zmniejszenie liczby użytkowników ' o przestrzeganie najlepszych praktyk. Ponadto specyfikacja SQRL wymaga, aby klucz główny był przechowywany w postaci zaszyfrowanej za pomocą hasła głównego i nie będzie można go brutalnie wymusić (ustawienie trwa ~ 60 sekund za jedną próbę). Uzyskanie hasła często nie jest trywialne, ponieważ SQRL promuje uwierzytelnianie poza pasmem (tj. Rejestrowanie kluczy na zhakowanej maszynie wygrywa ' t zawsze pomaga). Tak więc, chociaż konsekwencje pełnego kompromisu są wysokie, prawdopodobieństwo kompromisu jest dość niskie.
• SQRL może jeszcze mieć wady, które wymagają naprawy, ale twierdzi , że rozwiązuje wiele problemów występujących w istniejących podejściach do uwierzytelniania, a każda krytyka SQRL, która twierdzi, że ” nie przynosi żadnych korzyści powinno zawierać obalenia tych twierdzeń, zamiast oczekiwać, że zostanie ono zaakceptowane na ślepo.
• > Jak wszystko, co wychodzi od Gibsona , ten schemat SRQL jest wysoce wadliwy i nie oferuje żadnych korzyści w porównaniu z metodami konwencjonalnymi. — To nie ' wydaje się pomagać w odpowiedzi na pytanie, a wydaje mi się, że masz problemy z technologią, ponieważ ją wymyśliłeś. Niektóre z punktów, które wymieniłeś jako błędy, są w rzeczywistości rozwiązane w specyfikacji ” „. Na przykład sam SQRL nie ' wspomina o sposobie przechowywania klucza głównego, ale Steve Gibson ' komentuje to, że telefon komórkowy klient, na przykład, zaszyfrowałby go hasłem głównym przy użyciu skryptu, którego wykonanie zajmuje średnio 60 sekund.
• Gibson wprost rozwiązuje kwestię ochrony klucza głównego.
• Wstrzymaj druga. Możesz porównać kradzież klucza głównego SQRL z kradzieżą jednego klucza LastPass. Czy nie ' czy nie byłoby lepszą analogią zrównanie tego z całą odszyfrowaną bazą haseł LastPass kradzieżą?

Ogólnie rzecz biorąc, protokół nie wydaje się zwiększać bezpieczeństwa w porównaniu z istniejącą technologią. Jeśli szukasz najlepszego sposobu ochrony swojej tożsamości w Internecie, to bez wątpienia a nie . Ale przejdźmy do zalet i wad:

Zalety

Nie można ” udostępniać ” hasło w wąskim znaczeniu, że złośliwa witryna nie może” użyć uwierzytelnienia dostarczonego jednej witrynie do zalogowania się w innej witrynie.

Brute-force atak na token uwierzytelniania to niewykonalne.

Poświadczenia nie są przechowywane na Twoim komputerze. Chroni Cię to przed niewielkim podzbiorem Ataki skierowane na stacje robocze. W szczególności jesteś chroniony przed atakami polegającymi na kradzieży hasła z komputera. Nie jesteś jednak chroniony przed jakimkolwiek rodzajem przejęcia sesji lub przejęcia przeglądarki, a teraz jesteś także podatny na ataki związane z telefonami. Więcej o tym później.

Wady

Ta technika jest niebezpiecznie podatna na ataki MITM i inżynierię społeczną. Prawdopodobnie bardziej niż jakikolwiek inny używany schemat uwierzytelniania, w tym hasła. Etap uwierzytelniania i krok inicjacji logowania są z natury rozłączone w tym sensie, że telefon będzie poprawnie uwierzytelniał się na podstawie dowolnego przedstawionego kodu QR, bez względu na to, jak i gdzie zostanie on przedstawiony użytkownikowi.

Na przykład Witryna phishingowa może wyświetlać autentyczny kod QR logowania, który loguje atakującego zamiast użytkownika. Firma Gibson jest przekonana, że użytkownicy zobaczą nazwę banku, sklepu lub witryny w aplikacji telefonu podczas uwierzytelniania i dlatego będą wykazywać odpowiednią czujność, aby udaremnić ataki. Historia sugeruje, że jest to mało prawdopodobne, a bardziej rozsądnym oczekiwaniem jest to, że zobaczenie poprawnej nazwy w aplikacji fałszywie utwierdzi użytkownika w przekonaniu, że witryna jest legalna, ponieważ była w stanie wywołać znane żądanie logowania na telefonie. Przestroga, z którą już wcześniej zwrócono uwagę użytkowników na temat bezpieczeństwa haseł, niekoniecznie przekłada się na nowe techniki uwierzytelniania, takie jak ta, co sprawia, że ta aplikacja jest prawdopodobnie mniej odporna na inżynierię społeczną.

Ta technika łączy uwierzytelnianie i tożsamość w fizyczny obiekt, który jest często gubiony lub kradziony. W tym sensie to ” bardziej przypomina paszport niż hasło. Każdy, kto jest w posiadaniu Twojego telefonu, nagle staje wyłącznie w posiadaniu Twojej tożsamości: osoba atakująca może nie tylko podszywać się pod Ciebie, ale również bez drugiej kopii na drugim telefonie ( mało prawdopodobne), teraz straciłeś zdolność identyfikacji.Klucze uwierzytelniania nie są odwoływalne, więc bez odzyskiwania poza pasmem z każdej witryny nie można odzyskać swojej tożsamości. Nawet jeśli istnieje odzyskiwanie poza pasmem, w konfrontacji z dwoma użytkownikami, jednym posiadającym tożsamość, a drugim bez, może być trudno zrozumieć, dlaczego operator witryny miałby Ci ufać.

Ta technika łączy wszystkie twoje tokeny uwierzytelniania w jeden klucz , chyba że ręcznie utworzysz inne. To sprawia, że twój jeden klucz jest wyjątkowo soczystym celem dla atakujących. Ponadto klucz jest przechowywany w telefonie, którego urządzenia zwykle mają śmiesznie porowate zabezpieczenia wewnętrzne. Łączenie niezwykle soczystych celów z niespełniającymi normami zabezpieczeniami nie zapewnia bezpieczeństwa.

Alternatywy

Najbardziej problematycznym aspektem tego schematu jest to, jak słabo wypada on w porównaniu z dostępnymi alternatywami.

Najbezpieczniejszą obecnie powszechnie akceptowaną opcją jest lastpass, keepass i inne takie zintegrowane z przeglądarką systemy haseł. W szczególności szyfrowanie po stronie klienta zmniejsza potrzebę zaufania jakiejkolwiek stronie trzeciej. Co ważniejsze, integracja przeglądarki sprawia, że phishing jest praktycznie niemożliwy . LastPass lub KeePass wypełnią hasło tylko wtedy, gdy są obsługiwane z właściwej domeny, co oznacza, że jeśli zostanie wyświetlona złośliwa witryna, użytkownik nie będzie miał dostępu do swojego hasła.

Ponadto LastPass niedawno dodał funkcję co zmusza użytkowników do zmiany haseł, które nie są unikalne w skali globalnej. Pomaga to zapobiegać ponownemu używaniu haseł, co oznacza, że podstawową korzyść z techniki Gibsona można dziś łatwo uzyskać za pomocą tego narzędzia w istniejących witrynach, bez dodatkowej niepewności, jaką sugeruje jego schemat.

Istniejące schematy uwierzytelniania dwuskładnikowego, które używają telefonów lub podobnych urządzeń, już dziś pomagają chronić logowanie użytkowników w taki sposób, że nie narażają Cię natychmiast na kradzież tożsamości w przypadku kradzieży urządzenia. bezpieczeństwo uwierzytelniania dwuskładnikowego polega na tym, że ani urządzenie, ani hasło nie mogą być użyte w przypadku kradzieży bez drugiego. Technika Gibsona jest w dużej mierze odporna na włączenie do schematu dwuskładnikowego, co sprawia, że ten poziom ochrony niedostępna.

TL; DR:

Technika uwierzytelniania Gibsona nie daje wystarczających korzyści, aby przezwyciężyć dodatkowe koszty bezpieczeństwa, które również nakłada. Te koszty są podstawową częścią samego schematu i prawdopodobnie nie można ich obliczyć bez porzucenia całego projektu.

Można argumentować, że to lepsze niż nic, ale nie można argumentować, że jest to lepsze niż wszystko, co już mamy.

Aktualizacje Gibsona

Niedawno firma Gibson ogłosiła dodatkową ochronę przed phishingiem, ponieważ była to poważna krytyka. Ich ochrona jest następująca: Jeśli NIE używasz kodów QR, telefonu komórkowego itp., A zamiast tego masz w swoim systemie agenta uwierzytelniania (na przykład w przeglądarce), serwer może sprawdzić, czy uwierzytelnianie odpowiedź pochodzi z tego samego adresu IP co żądanie uwierzytelnienia. To dobrze i dobrze, ale cały cel tego protokołu polega na przeniesieniu Twojej tożsamości do telefonu komórkowego. Jeśli jedynym bezpiecznym sposobem korzystania z protokołu jest nieużywanie jego rdzenia to może powinniśmy ponownie przemyśleć, co próbujemy osiągnąć.

Teoretycznie mógłbyś nadal korzystać z telefonu komórkowego, jeśli (i tylko wtedy) Twój telefon komórkowy wiedział że używa tego samego adresu IP co Twój komputer. Którego oczywiście nie może wiedzieć, ponieważ nie zna adresu IP Twojego komputera.

Lepsze rozwiązanie

Jak wspomniano wcześniej, jeśli metoda uwierzytelniania znajduje się w Twojej przeglądarce, , cały problem z phishingiem zostanie natychmiast rozwiązany bez żadnego wysiłku ani weryfikacji ze strony użytkownika. Nawet najmniej zdolnego użytkownika nie można oszukać do uwierzytelnienia w niewłaściwej witrynie, ponieważ token uwierzytelniania witryny jest powiązany z nazwą domeny, a przeglądarka wygrała. t zezwalaj na uwierzytelnianie w złej domenie. Jest to technika, która jest już obecnie używana, jest całkowicie automatyczna i nie wymaga współpracy witryny ani żadnej inteligencji ze strony użytkownika.

Tę metodę można wzmocnić, wymagając drugiego czynnika uwierzytelniania (np. zmieniający się w czasie klucz w telefonie komórkowym), który znowu jest już dostępny i używany w dzisiejszych czasach, co chroni Cię (przede wszystkim) przed wpadkami ze strony docelowej witryny lub firmy.

Jeśli chodzi o obawy, że uwierzytelnianie po stronie przeglądarki jest podatne na ataki na stację roboczą klienta: chociaż jest to prawdą, prawdą jest również, że jeśli twoja przeglądarka jest zagrożona, to nie korzystanie z tej przeglądarki jest bezpieczne , niezależnie od używanego mechanizmu uwierzytelniania.Twórcy złośliwego oprogramowania mogą (i już to robią) czekać na uwierzytelnienie przy użyciu superbezpiecznej techniki, a następnie po cichu wysłać niezbędny ruch do ” własnego ” twoje konto, a wszystko to bez widocznych błędów. Ani SQRL, ani żaden inny system uwierzytelniania nie może ochronić użytkownika zaatakowanej przeglądarki, tak samo jak zamki do drzwi nie chronią Cię przed pożarem w domu. Kupowanie ognioodpornych zamków nie jest rozwiązaniem.

Gdzie dalej

Jeśli szukasz absolutnej gwarancji ochrony przed podszywaniem się , a następnie spójrz na token Fido U2F. Ten standard świeci tam, gdzie SQRL nie spełnia wymagań i zapewnia gwarantowaną odporność na ataki MITM (np. phishing). Robi to poprzez uwierzytelnianie nie tylko użytkownika, ale także kanału, więc „Gwarantujemy, że (a) Twoje konto nie może być uwierzytelnione bez tokena, a także (b) Twój token może być używany tylko do uwierzytelniania połączenia z maszyną, do której jest podłączony. Zobacz tę odpowiedź , aby uzyskać więcej informacji.

Komentarze

• O pierwszym punkcie : o ile rozumiem, zastanawialiśmy się nad tym i jedną z opcji jest zezwolenie stronie internetowej, na której się uwierzytelniasz, na odpowiedzialność za przekierowanie. Tak więc po zalogowaniu następuje przekierowanie na stronę ' prawdziwego banku, a nie atakującego. Co do drugiego punktu, to samo dzieje się dzisiaj z użytkownikami narzędzi takich jak LastPass. Jeśli nie skonfigurujesz mechanizmu ochrony (na przykład kodu PIN), wszystkie Twoje hasła również zostaną skradzione. Dlaczego ' t to samo może dotyczyć SQRL? Ponadto, o ile rozumiem ze specyfikacji, użytkownik może wykonać kopię zapasową swojej tożsamości nawet na papierze (jako kod QR).
• I co do trzeciego punktu: to samo dzieje się z większością użytkowników, którzy nie ' Nie używaj menedżera haseł, po prostu używając jednej nazwy użytkownika / hasła w kilku witrynach internetowych. Lub w przypadku użytkowników menedżerów haseł, których ” tożsamość ” jest rozpowszechniona na kilku witrynach internetowych, ale przechowywana w jednym miejscu (LastPass ' serwery, baza danych 1Password i tak dalej). Więc to ' nie jest tak naprawdę błędem SQRL. Podsumowując, im więcej czytam o SQRL, tym bardziej widzę korzyści płynące z tego w porównaniu z obecnymi alternatywami. Powiedz, że mówisz o Steve Gibsonie, ale SQRL naprawdę wydaje mi się dobrą alternatywą.
• ” Ostrożność, która już dotarła do głów Użytkownicy w zakresie bezpieczeństwa hasłem niekoniecznie przekładają się na nowe techniki uwierzytelniania, takie jak ta. . . ” To doskonała uwaga, a bitwa została już przegrana z marketingiem. Kody QR są postrzegane jako łatwy sposób na załatwienie spraw, a nie jako potencjalny wektor ataku. Przynajmniej pary nazwa użytkownika / hasło były PIERWSZE używane jako mechanizm uwierzytelniania, a nie narzędzie marketingowe.
• @jpkrohling: Jeśli chodzi o menedżerów haseł, sądzę, że większość użytkowników takiego oprogramowania NIE przechowuje swojego hasła głównego na swoim urządzeniu mobilnym, właśnie dlatego, że zdają sobie sprawę, jakie to niebezpieczne. Mam jedną fizyczną kopię mojego hasła głównego w bezpiecznym miejscu, ale nie mam kopii elektronicznych. Ataki, które umożliwiłyby dostęp do mojego hasła głównego, różnią się od tych, które mogłyby naruszyć hasło witryny, i są znacznie mniej prawdopodobne. (Przede wszystkim dlatego, że zaatakowanie mojej bazy haseł wymagałoby zaatakowania mnie osobiście, a nie dużej, zaatakowanej witryny).
• @jpkrohling Ani LastPass, ani KeePass nigdzie nie przechowuje hasła głównego. ' jest używany do odblokowywania bazy danych haseł, ale nie jest ' nie przechowywany. To zasadniczo różni się od posiadania pojedynczego klucza, który sam w sobie jest używany wszędzie.

SQRL z pewnością nie jest pozbawiony wad, ale z pewnością przewyższa większość podstawowych rozwiązań uwierzytelniających szeroko stosowanych obecnie w Internecie pod względem bezpieczeństwa i (i to jest ważne) użyteczności. Pozwólcie, że wyjaśnię.

Błędne przekonania

Najpierw pozwolę sobie wyjaśnić kilka błędnych przekonań obecnych w niektórych innych odpowiedziach na to pytanie. Wiele z tych odpowiedzi jest nieaktualnych i zostały napisane przed wprowadzeniem zmian w dokumentacji SQRL które rozwiązują przedstawione w nich problemy, podczas gdy inne wydają się kłaść nadmierny nacisk na błędy w SQRL, które są również obecne w wielu innych powszechnie stosowanych istniejących rozwiązaniach uwierzytelniania, ignorując ich zalety. Wyjaśnijmy więc tutaj kilka nieporozumień, my?

Mit: SQRL wymaga skanowania kodów QR do działania

To po prostu nieprawda. Kody QR to wygoda co sprawia, że SQRL jest łatwiejszy w użyciu na komputerach, na których użytkownik nie skonfigurował oprogramowania klienckiego SQRL. Witryna SQRL zawiera następujące informacje:

Three Ways to Go….smartfon opcjonalny:

Chociaż oryginalną inspiracją do opracowania tego systemu był smartfon skanujący kod QR na stronie logowania na stronie internetowej, niewielki dodatek do tego modelu umożliwia dwa bardziej znaczące tryby działania: Po prostu uczyń obraz kodu QR również klikalnym linkiem do tego samego adresu URL, który jest zakodowany w kodzie QR. Daje to trzy sposoby logowania:

• Zeskanuj kod smartfonem: Za pomocą opisanym powyżej, smartfon użytkownika skanuje kod QR pojawiający się na stronie logowania w witrynie, a użytkownik jest zalogowany w tej witrynie.
• TAP KOD na smartfonie: Aby zalogować się do witryny internetowej NA smartfonie, gdy wizualny kod SQRL jest również linkiem w stylu URL (używając sqrl: // jako schematu), Aplikacja SQRL zainstalowana na smartfonie otrzyma ten link i bezpiecznie zaloguje użytkownika do witryny w telefonie.
• Kliknij kod na ekranie komputera stacjonarnego lub laptopa : Aby używać systemu SQRL na dowolnym komputerze stacjonarnym lub laptopie, zostanie zainstalowana aplikacja komputerowa SQRL, która zarejestruje się, aby otrzymywać łącza sqrl: //. (Jest to podobne do sposobu, w jaki program pocztowy rejestruje się w celu otrzymywania mailto: links). Umożliwia to użytkownikom korzystanie z tego samego rozwiązania na komputerze stacjonarnym, którego używają na swoich smartfonach. Gdy jakakolwiek witryna internetowa oferuje kod SQRL, użytkownik po prostu klika kod kursorem myszy, a lokalnie zainstalowana aplikacja SQRL wyskakuje, monituje o hasło SQRL, potwierdza domenę, a następnie loguje się.

Mit: główny klucz SQRL jest przechowywany w telefonie w postaci niezaszyfrowanej i niezabezpieczonej

Nie jestem pewien, dlaczego niektórzy to zrobili założenie, ponieważ wydaje mi się oczywiste, że tak nie jest.Klucz główny SQRL jest chroniony w taki sam sposób, w jaki chronisz bazę danych z hasłami: silnym hasłem głównym. Kradzież telefonu użytkownika nie dawałaby automatycznie dostępu do jego tożsamości online, chyba że masz również jego hasło główne. Więcej szczegółów na temat zarządzania kluczami jest wyjaśnionych na stronie SQRL Client- Zarządzanie kluczami bocznymi w witrynie SQRL.

Mit: Jeśli Twój klucz główny zostanie skradziony, nie możesz zmienić swoich danych logowania

To również jest fałszywe. SQRL zapewnia wbudowany sposób umożliwiający prawdziwemu właścicielowi konta aktualizację danych logowania w przypadku złamania klucza. Ta funkcja jest znana jako Blokada tożsamości:

„Identity Lock” zapobiega zmianie tożsamości & umożliwia odzyskiwanie: To jest również na tyle znaczący, że zasługuje na własną stronę szczegółowego opisu: „ Protokół blokady tożsamości ” (strona 4 w bloku linków na dole tej strony). tożsamość użytkownika została ustalona na serwerze sieciowym, SQRL c lient nie może zmienić tej tożsamości. Oznacza to, że jeśli zdarzyło się najgorsze i użyto bardzo słabego i łatwego do odgadnięcia hasła lub ktoś włamał się na telefon lub pulpit użytkownika w celu uzyskania jego klucza głównego i hasła, żadna złośliwa strona trzecia nie może zmienić tożsamości online użytkownika , aby zablokować mu dostęp do jego własnych kont internetowych. Co więcej, poprzez załadowanie „klucza odblokowującego tożsamość”, który normalnie jest offline, prawdziwy właściciel swojej tożsamości może wycofać się i zastąpić utraconą lub skradzioną tożsamość online, w zasadzie odzyskać od dowolnego napastnika, przez co ich poprzednia tożsamość staje się bezużyteczna.

Prawdopodobne: SQRL jest bardziej podatny na phishing niż istniejące rozwiązania uwierzytelniające

OK, więc jest to faktycznie częściowo prawda. Podczas korzystania z SQRL poprzez skanowanie kodu QR ochrona przed phishingiem jest rzeczywiście bardzo niewielka. O ile użytkownik nie upewni się, że witryna wyświetlana na pasku adresu przeglądarki jest taka sama, jak ta wyświetlana w aplikacji SQRL Client, może on autoryzować sesję logowania dla atakującego. Jest to nadal lepsze niż hasła, gdzie dawaliby phisherowi stały dostęp do swojego konta (i wszelkich innych kont, które mają gdzie indziej i które mają to samo hasło) do czasu zmiany hasła, ale nie tak dobre, jak inne rozwiązania, które integrują się z przeglądarką użytkownika, takie jak klucze U2F , WebAuthn, certyfikaty klienta i (pod pewnymi warunkami) menedżery haseł.

Jednak gdy „używasz klienta SQRL na tym samym urządzeniu, na którym się logujesz”, SQRL ma pewne zabezpieczenia przed phishing w miejscu. Te zabezpieczenia są wyjaśnione w witrynie SQRL w sekcji Jak SQRL może udaremnić ataki phishingowe .Istnieje również możliwość integracji SQRL z przeglądarkami (prawdopodobnie za pomocą wtyczek) w celu zapewnienia znacznie silniejszej ochrony przed atakami phishingowymi; na równi z rozwiązaniami takimi jak WebAuthn i certyfikaty klienta.

Ogólnie rzecz biorąc, SQRL jest na poziomie mniej więcej na tym samym poziomie co menedżery haseł do ochrony przed phishingiem. Może zapewniać silną ochronę przed phishingiem, gdy jest zainstalowany na tym samym urządzeniu, na którym loguje się użytkownik, ale zapewnia minimalną ochronę, gdy jest zainstalowany na innym urządzeniu.

Porównanie z alternatywami

Teraz porównajmy SQRL z istniejącymi, szeroko stosowanymi rozwiązaniami uwierzytelniania.

Hasła

SQRL jest pod wieloma względami znacznie lepszy od haseł. Nie tylko jest wygodniejszy w użyciu po ustawieniu ponieważ użytkownicy nie muszą martwić się o zapamiętanie lub ponowne wpisanie wielu różnych haseł do każdej witryny, ale chroni to również przed ponownym użyciem haseł, słabymi hasłami, keyloggerem i, do pewnego stopnia, phishingiem.

Wady W porównaniu z hasłami SQRL jest trudniejszy do wdrożenia dla operatorów witryn, nie jest tak powszechnie używany, wymaga więcej czasu na początkową konfigurację, wymaga pewnego wysiłku, aby przenieść się na nowe urządzenie i zapewnia pojedynczy punkt awarii dla wszystkie konta użytkowników, jeśli klucz główny zostanie skradziony (chociaż ten ostatni punkt Dotyczy to również haseł, jeśli użytkownik używa tego samego hasła w każdej witrynie).

Menedżery haseł

Pod wieloma względami SQRL jest bardzo podobny do menedżerów haseł. Obie zapewniają pojedynczą, scentralizowaną kotwicę zaufania, która służy jako rodzaj uwierzytelniania proxy między użytkownikami a poszczególnymi usługami. Jest jednak kilka powodów, dla których SQRL jest lepszy od menedżerów haseł.

Myślę, że główną zaletą SQRL w porównaniu z menedżerami haseł jest to, że jest łatwiejszy i bezpieczniejszy w użyciu na niezaufanych lub tylko częściowo zaufanych komputerach. Załóżmy na przykład, że użytkownik chce zalogować się do witryny internetowej za pomocą komputera w bibliotece publicznej. Korzystając z menedżera haseł, musiałby albo uzyskać dostęp do hasła do tej witryny na swoim telefonie i ręcznie wpisać je na komputerze, albo pobrać menedżera haseł i bazę danych haseł na komputerze w bibliotece, odblokuj bazę danych za pomocą jego hasła głównego, a następnie zaloguj się. Pierwszy scenariusz jest niewygodny dla użytkownika i ujawnia hasło użytkownika w postaci zwykłego tekstu do tej witryny niezaufanemu komputerowi (i wszelkie złośliwe oprogramowanie na niezaufanym komputerze, w tym keyloggery). Drugi scenariusz jest jeszcze gorszy, ponieważ jest zarówno niewygodny, jak i ujawnia całą, odszyfrowaną bazę danych haseł użytkownika i hasło główne niezaufanemu komputerowi. Dzięki SQRL użytkownik musiałby tylko zeskanować kod QR na ekranie niezaufanego komputera, co jest znacznie wygodniejsze dla użytkownika i ujawnia tylko jedną sesję logowania (bez poświadczeń wielokrotnego użytku, takich jak hasło) na niezaufanym komputerze .

Kolejną zaletą SQRL nad menedżerami haseł jest to, że łatwiej jest odzyskać je z najgorszego scenariusza: kradzieży bazy danych haseł użytkownika / klucza głównego. Z menedżerem haseł nie można wystarczy zmienić hasło w każdej witrynie, musiałbyś także martwić się, że atakujący zmieni Twoje hasło (prawdopodobnie zablokuje Ci dostęp do konta). Atakujący ma również tę zaletę, że posiada listę wszystkich witryn, które masz konto włączone, co znacznie ułatwia wykorzystanie kradzieży bazy danych haseł. W przypadku SQRL kradzież klucza głównego jest nadal okropną sytuacją, ale osoba atakująca nie ma listy witryn, na których masz konto (musi zamiast tego odgadnąć ) i nie może zmienić hasła, aby Cię zablokować Twojego konta. Po załadowaniu klucza odblokowującego tożsamość zmiana danych logowania w każdej witrynie jest również nieco wygodniejsza, ponieważ klient SQRL ma możliwość zrobienia tego automatycznie dla każdej witryny odwiedzanej po zalogowaniu. (Nie ma potrzeby za pomocą jakichkolwiek formularzy „zmiany hasła”.)

Na koniec myślę, że SQRL ma jedną małą, ale ważną przewagę nad menedżerami haseł, jeśli chodzi o cel polegający na całkowitej zamianie haseł. używanie SQRL zamiast tradycyjnych haseł. Dopóki użytkownicy nadal mają możliwość słabego bezpieczeństwa i ponownego używania tego samego hasła w każdej witrynie, jest to coś, co nadal się zdarza. Jeśli SQRL zacznie zyskiwać na popularności, witryny mogą faktycznie zacząć wycofywać z użycia haseł. Tego nie da się zrobić z menedżerami haseł, ponieważ polegają one na używaniu haseł do działania.

Jeśli chodzi o wady, właściwie nie mogę sobie wyobrazić sytuacji, w której SQRL z konieczności byłoby gorsze niż menedżery haseł pod względem bezpieczeństwo. Główną wadą SQRL jest to, że wymaga wsparcia ze strony operatorów witryn, podczas gdy menedżerowie haseł nie wymagają specjalnego wsparcia ze strony istniejących usług. Oznacza to, że możesz zacząć używać menedżerów haseł już teraz, ale SQRL będzie musiał poczekać, aż witryny go wdrożą, zanim będzie można go używać. To istotna bariera w adopcji.

Certyfikaty klienta

Podstawową przewagą SQRL nad certyfikatami klienta jest wygoda. Certyfikaty klienta są obecnie skomplikowane w konfiguracji, trudne do przenoszenia między komputerami i powodują problemy z prywatnością, gdy ten sam certyfikat jest używany w różnych witrynach. Chociaż teoretycznie moglibyśmy zbudować system z użyciem certyfikatów klienta, który rozwiązałby te problemy, pojawiłby się również problem słabej integracji z interfejsami użytkownika i serwerami WWW, które są trudniejszymi do rozwiązania. Nie będę tu wdawać się w zbyt wiele szczegółów, ponieważ istnieje już doskonały artykuł na temat problemów z użytecznością certyfikatów klienta w Browserauth.net.

Pod względem bezpieczeństwa certyfikaty klienta mają tę wadę, że wymagają zaangażowania urzędu certyfikacji. Jest to (potencjalnie) kosztowne i wymaga zaufania niezależnemu urzędowi certyfikacji. Ponadto, jeśli zdecydujesz się zignorować urzędy certyfikacji i zamiast tego samodzielnie podpisać swoje certyfikaty, musisz zająć się kwestią unieważnienia certyfikatu. Certyfikaty klienta mają również te same problemy z bezpieczeństwem i wygodą, co menedżery haseł, gdy użytkownicy chcą zalogować się na niezaufanym komputerze; muszą przenieść swój certyfikat na niezaufany komputer, co jest zarówno niewygodne, jak i potencjalnie naraża ich tożsamość główną na szkodliwe oprogramowanie na tym komputerze.

Krótko mówiąc, dopóki ktoś nie wymyśli lepszego, przyjaznego dla użytkownika rozwiązania przy użyciu certyfikaty klienta, które rozwiązują (przynajmniej większość) tych problemów, nie sądzę, aby certyfikaty klienta były poważnym konkurentem dla SQRL (lub, jeśli o to chodzi, haseł).

Uwierzytelnianie dwuetapowe

Pomyślałem, że wspomnę o tym: SQRL i uwierzytelnianie dwuskładnikowe nie wykluczają się wzajemnie. SQRL zastępuje pierwszy czynnik w 2FA: hasła. Inne dodatkowe środki, takie jak kody OTP lub klucze FIDO U2F, mogą być nadal używane z SQRL.

WebAuthn

Teraz tutaj rzeczy stają się interesujące. WebAuthn to nowy (no cóż, nowszy niż SQRL) standard W3C zaprojektowany w celu zapewnienia standardowego interfejsu API, którego strony internetowe mogą używać do uwierzytelniania użytkowników za pomocą kluczy publicznych w sieci. Podobnie jak SQRL, obsługuje używanie telefonu użytkownika do uwierzytelniania sesji logowania na urządzeniu zewnętrznym , oprócz kilku innych metod uwierzytelniania (takich jak klucze bezpieczeństwa drugiego stopnia) .

W tym miejscu SQRL w końcu spełnia swoje odpowiedniki, przynajmniej z punktu widzenia bezpieczeństwa. WebAuthn nie tylko zapewnia takie same zabezpieczenia przed ponownym użyciem haseł, słabymi hasłami i rejestracją klawiszy, jak SQRL, ale także zapewnia jeszcze silniejszą ochronę przed phishingiem dzięki integracji z przeglądarką użytkownika nawet podczas autoryzacji logowania sesja dla komputera PC, na którym użytkownik nie skonfigurował wcześniej oprogramowania klienta wystawcy uwierzytelnienia. Jest to możliwe, ponieważ w takiej sytuacji WebAuthn komunikuje się bezpośrednio z przeglądarką użytkownika za pomocą dwukierunkowych protokołów komunikacyjnych, takich jak Blutooth lub NFC, zamiast komunikować się ze stroną internetową, z której korzysta użytkownik, za pomocą jednokierunkowego kodu QR.

Z punktu widzenia użyteczności sprawa jest nieco bardziej skomplikowana. Przynajmniej na pierwszy rzut oka WebAuthn znów wygrywa. Ponieważ jest to standard W3C, który ma już implementacje w wielu przeglądarkach , teoretycznie użytkownicy mogą natychmiast rozpocząć korzystanie z WebAuthn bez konieczności instalowania oprogramowania innej firmy. Jednak w praktyce większość istniejących wdrożeń WebAuthn skupia się na wykorzystaniu go jako formy uwierzytelniania drugiego stopnia lub jako sposobu ponownego uwierzytelnienia użytkownika którzy wcześniej logowali się na tym samym urządzeniu przy użyciu innej metody logowania (zwykle hasła). Jako główny czynnik uwierzytelniania w WebAuthn nadal brakuje realnych implementacji.

Inne drobne kwestie obejmują fakt, że SQRL ma budynek t-in do rotacji kluczy kont w przypadku kradzieży klucza głównego, podczas gdy WebAuthn polega na witrynach internetowych we wdrażaniu własnego systemu unieważniania kluczy, a WebAuthn wymaga pewnego opcjonalnego sprzętu (takiego jak Bluetooth lub NFC) w celu aby uwierzytelnić się na zdalnym komputerze, podczas gdy SQRL może działać na każdym komputerze z działającym wyświetlaczem.

Ogólnie myślę, że jest bardzo prawdopodobne, że WebAuthn ostatecznie sprawi, że SQRL stanie się przestarzały. SQRL może na razie mieć trochę swobody, ale WebAuthn ma znacznie silniejsze wsparcie ze strony dostawców przeglądarek, operatorów witryn i innych organizacji zewnętrznych (takich jak W3C). Spodziewam się, że gdy WebAuthn otrzyma kilka implementacji umożliwiających użycie go jako głównego czynnika uwierzytelniającego, zacznie bardzo szybko przejmować kontrolę nad siecią.

Ostrzeżenia

SQRL jest nadal w fazie rozwoju, więc materiał przedstawiony w tej odpowiedzi może ulec zmianie. Spodziewam się, że w miarę postępu prac zajmiemy się niektórymi lukami i niejasnościami w tej odpowiedzi. Większość dyskusji toczy się obecnie na grupie dyskusyjnej SQRL na grc.com.

SQRL to wygodne rozwiązanie problemu z nazwą użytkownika / password paradox. (czyli kompromis między wygodą a bezpieczeństwem) bez korzystania z innej firmy . Zapewnia prostą alternatywę dla najpopularniejszego modelu uwierzytelniania (nazwa użytkownika & hasło), z praktycznie brakiem kompromisów dla bezpieczeństwa. Jest praktycznie tak samo bezpieczny jak każdy z powszechnie stosowanych obecnie modeli uwierzytelniania, , o ile nadal jesteś świadomy bezpieczeństwa . Jeśli używasz SQRL, nie oznacza to, że nie możesz przestrzegać najlepszych praktyk bezpieczeństwa, takich jak łącząc to z uwierzytelnianiem wieloskładnikowym dla ważnych kont.

Ważne jest, aby nie przegapić sedna SQRL. SQRL sam w sobie nie musi zapewniać lepszego lub gorszego bezpieczeństwa. Jeśli sam komputer / telefon zostanie przejęty lub użytkownik zostanie oszukany w przypadku wyłudzenia informacji jest to atak typu side-channel zamiast bezpośredniej winy samego SQRL. Każda konwencjonalna metoda uwierzytelniania ma ten problem z atakami kanału bocznego Niezniszczalna jednorazowa podkładka jest również podatna na ataki typu side-channel takie jak kompromitacja samego padu lub złe otoczenie bezpieczeństwa lub implementacje.

Jeśli słuchałeś oryginalnej propozycji pomysłu na temat Stevea Gibsona „s podcast , po którym następuje Q & A ”, odpowiedzi na wiele problemów poruszonych w tym wątku stosu. Steve sam powiedział też, że ten bardzo „prosty” i „genialny” (jego słowa) pomysł musiałby zostać „zweryfikowany” i „wbity” przez ekspertów ds. Bezpieczeństwa, ponieważ tylko czas pokaże, czy jest to bezpieczne rozwiązanie.

Podsumowując, większość argumentów przeciwko SQRL wykracza poza domenę samego SQRL, a zamiast tego dotyczy problemów z ludźmi praktykującymi słabe zabezpieczenia. SQRL nie wprowadza nowej klasyfikacji problemów, których nasze tradycyjne metody uwierzytelniania już nie mają.

SQRL jest doskonały, jeśli jest odpowiednio używany przez osoby dbające o bezpieczeństwo. Musisz zrozumieć, że zawsze istnieje kompromis między wygodą a bezpieczeństwem , a tym rozwiązaniem jest prawdopodobnie najlepsza równowaga z dwóch, które widziałem.

Komentarze

• Dzięki Ansichart. Ale czy ' t istniejące rozwiązania autoryzacji mogą po prostu zachować takie same lub lepsze funkcje zabezpieczeń jak SQRL, a następnie użyć automatyzacji, aby zwiększyć wygodę użytkownika? Jaka podstawowa właściwość wygody użytkownika SQRL ' nie wynika z automatyzacji? Pytam, ponieważ jeśli użytkownik ma dwie czarne skrzynki, które robią to samo; jeden oznaczony jako ” Dojrzały „, a drugi oznaczony jako ” SQRL ” i oba mogą być zaprojektowane / zautomatyzowane, mają ten sam interfejs / przyciski na zewnątrz pudełka – jaką wartość dodaną zapewnia SQRL?
• Rozwiązuje problem paradoksu hasła bez konieczności korzystania z usług strony trzeciej.
• Rozumiem. Więc jeśli ktoś nie ' nie chce narażać strony trzeciej na ryzyko jednokrotnego logowania i wygrywa ', nie generuje / nie przechowuje swoich haseł za pomocą menedżer haseł, SQRL może przyspieszyć. Ale jeśli SQRL jest mobilną czarną skrzynką, która prosi o hasło do odblokowania klucza głównego używanego do regeneracji / przechowywania identyfikatorów SQRLID, a następnie wykonuje łączenie wstecznego kanału ' plików cookie / QR session_id z serwerem ' s nagrane SQRLID do logowania – jak to jest inna mobilna czarna skrzynka z mobilnego menedżera haseł z automatycznym logowaniem przez ten sam kanał zwrotny; czy też dwusystemowa wtyczka certyfikatu klienta mobilnego z automatycznym generowaniem & logowania za pośrednictwem tego samego kanału wstecznego?
• Dokonałem poważnej edycji mojego oryginalnego posta po kilku drugich rozważaniach i bliższym przeczytaniu tego, co mówili inni, ponieważ mogłem to przesadzić. Przypuszczam, że posiadanie telefonu komórkowego jako centralnego klucza rozwiązuje problem i sprawiłoby, że ważniejsze byłoby silniejsze zabezpieczenie telefonu. Steve Gibson porusza również tę kwestię w Q & podcastu.

SQRL nie zapewnia przełomowych ulepszeń. Kody QR to optyczny format kodu kreskowego przydatny do dystrybucji krótkich treści – nic więcej.

Każda sytuacja „automatycznego logowania”, którą SQRL próbuje rozwiązać, może po prostu użyć certyfikatu klienta przechowywanego w telefonie komórkowym.

Hipotetycznie kod kreskowy QR na stronie HTTPS mógłby zwrócić podpisaną przez serwer lub zaszyfrowaną wersję certyfikatu klienta (lub podobne poświadczenie) znaną wcześniej z serwera, ale dlaczego? Do wygaśnięcia poświadczeń? Witryna może po prostu odrzucić wygasłe dane uwierzytelniające bezpośrednio.

Więc największy problem z bezpieczeństwem protokół to: Nowe odkrycie koła kwadratowego .

Update

Czytając nowe odpowiedzi i komentarze, chciałbym wskazać, jak łatwo jest zrobić coś podobnego do SQRL poprzez prosta automatyzacja dojrzałej istniejącej technologii :

1. Witryna prosi o weryfikację typu CAPTCHA lub podobną metodą „jestem człowiekiem”. Gdy użytkownik zastosuje się (POST), witryna zwraca HTTP 403.7 - Client Certificate Required lub zwykły błąd 403.
2. Niestandardowe strony 403 są dość łatwe w konfiguracji i mogą być całkiem ładne i przyjazne dla użytkownika. Można nawet załadować wymaganą poniżej funkcjonalność w sposób podobny do podpowiedzi „Wymagany Adobe Reader” na wielu stronach internetowych.
3. Niestandardowa strona 403 zawiera pewne znaczniki, na które reaguje niestandardowa wtyczka przeglądarki. Nazwijmy tę niestandardową wtyczkę „zgodną z S403L” w duchu „zgodności z SQRL”.
4. Wtyczka S403L generuje standardowy certyfikat klienta, który jest zabezpieczony w zwykłej zaszyfrowanej pamięci podręcznej certyfikatów przeglądarki (lub trzeciej party cache, jeśli szyfrowanie magazynu kluczy przeglądarki jest do niczego). Wtyczka tworzy standardowy CSR dla certyfikatu klienta i wysyła CSR na adres URL określony w znaczniku 403 (np. <s403l ref="https://www.example.com/S403L" />)
5. Serwer zgodny z S403L używa identyfikatora sesji użytkownika (pobranego z plików cookie lub ciągu zapytania) do utworzenia ciągłości z krokiem 1, a następnie zwraca CSR jako podpisany przez serwer. Ogólne uwierzytelnianie serwera przyjmie każdy certyfikat klienta, który został podpisany przez serwer (a tym samym spełnił kryteria rejestracji wymagane w kroku 1).
6. Wtyczka S403L przechowuje podpisany certyfikat klienta w pamięci podręcznej przeglądarki. Od następnie standardowa przeglądarka bez pomocy wtyczek może „automatycznie logować się” do serwera w standardowym trybie SSL / TLS do czasu wygaśnięcia certyfikatu.

„Mobilny” i „wizualny” charakter SQRL jest czymś w rodzaju błędnej orientacji, ponieważ nie zapewnia oddzielnego uwierzytelniania dwuskładnikowego, a teraz do nawigacji w Internecie potrzebne są dwa komputery zamiast jednego. Chyba że skierujesz kamerę internetową USB swojego komputera na jej własny monitor.

Kompromisy między hasłami a certyfikatami są dobrze zdefiniowane w społeczności bezpieczeństwa: hasła mieszczą się w ludzkim mózgu; certyfikaty nie pasują ludzki mózg ( zwykle ), ale może mieć szaloną entropię i dobre funkcje zarządzania PKI (wygaśnięcie , unieważnienie, rozszerzenie zasad itp.). SQRL nie pasuje do żadnego obozu; i jeśli zmierza w kierunku mniej-ludzkiego obozu, bardziej komputerowego, jak się wydaje – ma lata rozwoju i analizy bezpieczeństwa, aby powtórzyć istniejące funkcje X.509.

Komentarze

• > może po prostu użyć certyfikatu klienta przechowywanego w telefonie komórkowym.— poza tym, że ta technologia istnieje od lat zarówno na urządzeniach mobilnych, jak i na komputerach stacjonarnych, i ' nie jest tak rozpowszechniona, jak by się tego chciało. W przeciwieństwie do certyfikatu klienta, SQRL nie ' wymaga od Ciebie udowodnienia swojej prawdziwej tożsamości, aby utworzyć ” SQRL Identity „. Jeśli chcesz, możesz utworzyć tyle tożsamości, ile chcesz. Oznacza to, że zaletą w porównaniu z certyfikatami klienta jest to, że masz anonimowość po stronie protokołu uwierzytelniania '.
• @jpkrohling Powszechnie uważa się, że certyfikaty klienta wymagają ujawnienia tożsamości. Jest to wymóg, zgodnie z którym komercyjne organy podpisujące muszą używać swoich globalnie wymienialnych łańcuchów zaufania. W praktyce certyfikat klienta może być po prostu anonimowym CSR utworzonym przez klienta i podpisanym przez określony serwer, po spełnieniu dowolnych kryteriów (CAPTCHAs, poprzednie konto, itp). Certyfikaty mogą również mieć wbudowaną datę ważności. Type 40-L Kody kreskowe QR mogą w razie potrzeby wysyłać / przechowywać certyfikat klienta X.509 o rozmiarze 1 KB.
• OK, prawda, moja wina. Z tego punktu widzenia klient (na przykład aplikacja mobilna) może generować certyfikat klienta dla każdej strony internetowej, którą rejestruje użytkownik. Brzmi to drożej niż haszowanie niektórych informacji, ale może być interesującym rozwiązaniem. W każdym razie nadal nie ' zgadzam się z twoimi twierdzeniami, że SQRL jest gorszy niż bezużyteczny.
• Być może byłam surowa w stosunku do tego sformułowania i usunę je. Ale nie ' nie postrzegam SQRL jako nic innego niż bardziej seksowny sposób rozpowszechniania negocjowanych danych uwierzytelniających klienta; i taki, który nie ' nie rozwiązał niektórych subtelnych problemów rozwiązywanych przez dojrzałe schematy uwierzytelniania. Menedżer haseł jest żmudny (nie ' nie zawracam sobie głowy integracją przeglądarki, ponieważ ' mam paranoję), ale wiem, że tylko ja i jeden strona internetowa udostępnia każde jednorazowe hasło w moim zaszyfrowanym magazynie kluczy. Nie ' nie muszę martwić się o wymyślne nowe schematy haszowania / uwierzytelniania, tylko jakość PRNG / TRNG, której mój menedżer haseł używa do generowania haseł.
• @LateralFractal kogo obchodzi, czy ' jest nowy czy nie? SQRL umożliwia przyjazne dla użytkownika uwierzytelnianie, w którym pierwsza strona nie ujawnia swojego sekretu drugiej stronie ani żadnej trzeciej stronie, która mogła naruszyć bezpieczeństwo drugiej strony '. Jest to ' próba rozwiązania rzeczywistego problemu, którego dotychczas nikt inny nie był w stanie rozwiązać.

Chciałbym odpowiedzieć na pierwsze pytanie: „jednym z problemów, które przychodzą mi do głowy, jest włamanie do czytnika QR, aby wyświetlić www.google.com zamiast www.nsa-super-secret-place.gov/123 „:

Klucz główny jest używany jako ziarno w HMAC wraz z adresem strony internetowej (FQDN). Więc chociaż kod QR może zakodować zupełnie inny adres URL, protokół NIE ujawni kodu uwierzytelniającego, który normalnie zostałby wysłany do www.google.com (w przykładzie).

Po drugie, wielu współautorów zapomina o kluczowych celach podczas pracy nad tym pomysłem:

1. anonimowość dzięki rezygnacji z korzystania z usług stron trzecich
2. łatwość użycia
3. nie ma potrzeby wpisywania tajnych danych uwierzytelniających na niezaufanych komputerach

Uważam, że protokoły w pełni je rozwiązują!

Istnieją jednak kompromisy, które w rzeczywistości pochodzą z pierwszego celu. Jeśli w uwierzytelnianiu nie jest zaangażowana żadna osoba trzecia, jak można odwołać jej dane uwierzytelniające? Ponadto oczywistym problemem jest bezpieczeństwo klucza głównego. Przewiduję, że będzie to dobrze chronione przez przyszłe urządzenia mobilne w chipie podobnym do HSM. Do tego czasu klucz jest tylko urządzeniem przenośnym z przypięciem do pliku, chronionym hasłem, chociaż PBDKF2 zapewnia, że w rzeczywistości brutalna siła jest bardzo powolna.

Komentarze

• Ponownie, co ' jest nowego w tym pomyśle? Wydaje mi się, że jest to prymitywna odmiana nieistniejącego już Windows CardSpace.
• Tak, masz rację co do CardSpace. Jest też U-Prove, również należące do Microsoft. Pytanie brzmi, w jaki sposób używałbyś CardSpace lub U-Prove na komputerze, któremu nie ufasz (kafejce internetowej lub komputerze znajomych). To właśnie dodał Steve.
• Ach, ok, tego ' mi brakowało. Nadal zgadzam się z @TerryChia, że to nie jest starter bez mechanizmu unieważniania kluczy użytkownika.
• @Xander Istnieje mechanizm odwoływania kluczy użytkowników. grc.com/sqrl/idlock.htm