Zoals gewoonlijk, neem alles wat met Steve Gibson te maken heeft met een vrachtwagenlading zout. Verplicht attrition.org link .

Laten we eens kijken naar Gibsons beschrijving van zijn protocol.

• De QR-code die wordt weergegeven bij de login prompt bevat de URL van de authenticatieservice voor de site. De URL bevat een veilig gegenereerd lang willekeurig nummer, zodat elke presentatie van de inlogpagina een andere QR-code weergeeft. (In crypto-kringen staat dit lange, willekeurige getal bekend als een “nonce”.)

• De SQRL-authenticatie-app van de smartphone hashes cryptografisch de domeinnaam van de site die door de gebruiker is ingetoetst s hoofdsleutel om een site-specifiek publiek sleutelpaar te produceren.

• De app ondertekent cryptografisch de volledige URL in de QR-code met behulp van de site-specifieke private key. Omdat de URL een veilig lang willekeurig nummer bevat (de nonce), is de handtekening uniek voor die site en QR-code.

• De app stuurt een veilige HTTPS POST-zoekopdracht naar de QR code URL, de authenticatieservice voor de site. De POST levert de site-specifieke openbare sleutel en de overeenkomende cryptografische handtekening van de URL van de QR-code.

• De authenticatiewebsite ontvangt en bevestigt de POST-query door een standaard HTTP “200 OK” zonder andere inhoud te retourneren. De SQRL-app bevestigt de succesvolle indiening van de door de gebruiker ondertekende QR-code.

• De authenticatiesite heeft de URL met de nonce die terugkwam van de inlogpagina via de gebruikersaccounts smartphone. Het heeft ook een cryptografische handtekening van die URL en de site-specifieke openbare sleutel van de gebruiker. Het gebruikt de openbare sleutel om te verifiëren dat de handtekening geldig is voor de URL. Dit bevestigt dat de gebruiker die de handtekening heeft gemaakt, de privésleutel heeft gebruikt die overeenkomt met de openbare sleutel. Na verificatie van de handtekening, herkent de authenticatiesite de nu geauthenticeerde gebruiker aan zijn site-specifieke publieke sleutel.

De Het grootste dat me opvalt is het gebruik van een ” hoofdsleutel ” door de gebruiker. Als ik het protocol correct lees, controleert die ene hoofdsleutel de volledige online identiteit van de gebruiker …

Vermoedelijk is deze hoofdsleutel opgeslagen in de telefoon van de gebruiker in een toepassingsdatabase. Dat opent een enorme gapende aanvalsvector in de vorm van malware die speciaal is ontworpen om de hoofdsleutel te stelen.

Laten we dus het verschil vergelijken tussen wat er gebeurt als een wachtwoord wordt gecompromitteerd en wat er gebeurt als de hoofdsleutel Ervan uitgaande dat u goede wachtwoordpraktijken volgt met lange, unieke en zeer willekeurige wachtwoorden die zijn opgeslagen in een wachtwoordbeheerder, hoeft u alleen maar één wachtwoord te wijzigen als dit wordt gecompromitteerd. Wat gebeurt er als uw hoofdsleutel wordt gecompromitteerd? zal op de een of andere manier alle sites moeten ophalen waarmee u zich heeft geauthenticeerd om te herkennen dat uw hoofdsleutel is gecompromitteerd. Het enige probleem is dat u geen andere manier heeft om u bij de site te verifiëren, zoals gebruikersnamen of e-mailadressen, hoe weet de site dat u in feite de hoofdsleutel probeert in te trekken?

Zoals alles dat uit Gibson komt, is dit SRQL-schema zeer gebrekkig en biedt het geen voordelen ten opzichte van conventionele methoden.

Comme nts

• ” Als je ‘ goede wachtwoordpraktijken volgt ” is een grote waarschuwing, en de meeste Netizens ‘ doen het niet.Een deel van SQRL ‘ s belofte is het verminderen van gebruikers ‘ behoefte om op de hoogte te blijven van best practices. Verder zal de SQRL-specificatie vragen om de hoofdsleutel versleuteld op te slaan met een hoofdwachtwoord en zal onmogelijk bruut te forceren zijn (afgestemd op ~ 60s voor één poging). Het verkrijgen van het wachtwoord is vaak niet triviaal, aangezien SQRL out-of-band authenticatie promoot (dwz keylogging op een gehackte machine zal ‘ t altijd helpen). Dus hoewel de gevolgen van een volledig compromis groot zijn, is de kans op een compromis enigszins laag.
• SQRL heeft misschien nog gebreken die moeten worden verholpen, maar het is beweert een aantal problemen op te lossen die worden aangetroffen in bestaande benaderingen van authenticatie, en elke kritiek op SQRL die beweert dat deze ” geen voordelen biedt ” moet weerleggingen van deze claims bevatten in plaats van te verwachten dat de bewering blindelings wordt geaccepteerd.
• > Zoals alles dat uit Gibson komt , dit SRQL-schema is zeer gebrekkig en biedt geen voordelen ten opzichte van conventionele methoden. — Dit lijkt ‘ niet te helpen bij het beantwoorden van de vraag, en ik heb eigenlijk het gevoel dat je problemen hebt met de technologie vanwege wie het bedacht heeft. Sommige van de punten die u als fouten noemde, worden feitelijk aangepakt door de ” specificatie “. SQRL zelf vermeldt bijvoorbeeld niet ‘ t hoe de hoofdsleutel is opgeslagen, maar Steve Gibson ‘ s opmerkingen erover zijn dat een mobiel client zou het bijvoorbeeld versleutelen met een hoofdwachtwoord met behulp van een scrypt die gemiddeld 60 seconden nodig heeft om uit te voeren.
• Gibson spreekt expliciet over de bescherming van de hoofdsleutel.
• Houd een tweede. U stelt uw SQRL-hoofdsleutel die wordt gestolen gelijk aan een van uw LastPass-sleutels die wordt gestolen. Zou het ‘ niet een betere analogie zijn om het gelijk te stellen aan uw volledige, gedecodeerde LastPass-wachtwoorddatabase die wordt gestolen?

Over het algemeen lijkt het protocol de beveiliging ten opzichte van bestaande technologie niet te verhogen. Als u op zoek bent naar de beste manier om uw identiteit online te beschermen, is dit zonder twijfel niet . Maar laten we de voor- en nadelen bekijken:

Voordelen

Het is onmogelijk om ” te delen ” een wachtwoord in de enge zin dat een kwaadwillende website de authenticatie die aan de ene site wordt verstrekt, niet kan gebruiken om in te loggen op een andere site.

Een brute-force aanval op het authenticatietoken is niet haalbaar.

Inloggegevens worden niet op uw computer opgeslagen. Dit beschermt u tegen een kleine subset van werkstationgerichte aanvallen. In het bijzonder bent u beschermd tegen aanvallen die uw wachtwoord van uw computer stelen. U bent echter niet beschermd tegen enige vorm van sessie-kaping of browser-overname-aanvallen, en u bent nu ook vatbaar voor telefoongerelateerde aanvallen. Daarover later meer.

Nadelen

Deze techniek is gevaarlijk gevoelig voor MITM-aanvallen en social engineering. Waarschijnlijk meer dan enig ander authenticatieschema dat wordt gebruikt, inclusief wachtwoorden. De authenticatiestap en de inloginitiatiestap zijn inherent losgekoppeld in die zin dat de telefoon correct wordt geverifieerd tegen elke gepresenteerde QR-code, ongeacht hoe of waar deze aan de gebruiker wordt gepresenteerd.

Dus, bijvoorbeeld, een phishing-site kan een authentieke QR-inlogcode weergeven die de aanvaller aanmeldt in plaats van de gebruiker. Gibson is ervan overtuigd dat gebruikers tijdens authenticatie de naam van de bank of winkel of site op de telefoon-app zullen zien en daarom voldoende waakzaam zullen zijn om aanvallen te dwarsbomen. De geschiedenis suggereert dat dit onwaarschijnlijk is, en de redelijkere verwachting is dat het zien van de juiste naam in de app de gebruiker ten onrechte zal geruststellen door te denken dat de site legitiem is omdat het in staat was om het bekende inlogverzoek aan de telefoon te activeren. De waarschuwing die gebruikers al hebben gekregen met betrekking tot wachtwoordbeveiliging, vertaalt zich niet noodzakelijkerwijs in nieuwe authenticatietechnieken zoals deze, wat deze app waarschijnlijk inherent minder resistent maakt tegen social engineering.

Deze techniek combineert zowel authenticatie als identiteit tot een fysiek object dat vaak verloren of gestolen wordt. In die zin is het ” lijkt meer op een paspoort dan op een wachtwoord. Iedereen die in het bezit is van uw telefoon, is plotseling exclusief in het bezit van uw identiteit: niet alleen kan de aanvaller u nabootsen, maar ook zonder een tweede kopie op een tweede telefoon ( onwaarschijnlijk), nu bent u niet meer in staat uzelf te identificeren.Verificatiesleutels kunnen niet worden ingetrokken, dus zonder out-of-band herstel van elke site kunt u uw identiteit niet herstellen. En zelfs als er sprake is van out-of-band herstel, wanneer geconfronteerd met twee gebruikers, een met de identiteit en een zonder, kan het moeilijk zijn in te zien waarom de exploitant van de site u zou moeten vertrouwen.

Deze techniek combineert al uw authenticatietokens tot een enkele sleutel tenzij u handmatig andere aanmaakt. Dit maakt van je one key een extra sappig doelwit voor aanvallers. Bovendien wordt de sleutel opgeslagen op uw telefoon, welke apparaten doorgaans een belachelijk poreuze interne beveiliging hebben. Het combineren van ongewoon sappige doelen met ondermaatse beveiliging maakt je niet veilig.

Alternatieven

Het meest problematische aspect van dit schema is hoe slecht het zich verhoudt tot de beschikbare alternatieven.

De veiligste, universeel geaccepteerde optie van vandaag is lastpass, keepass en andere dergelijke browser-geïntegreerde wachtwoordsystemen. Met name versleuteling aan de clientzijde verlicht de noodzaak om een derde partij te vertrouwen. En nog belangrijker: browserintegratie maakt phishing praktisch onmogelijk . LastPass of KeePass zal het wachtwoord alleen invullen als het wordt bediend vanaf het juiste domein, wat betekent dat de gebruiker geen toegang heeft tot zijn wachtwoord als hij een kwaadaardige site krijgt aangeboden.

Bovendien heeft LastPass onlangs een functie toegevoegd die gebruikers lastigvalt om wachtwoorden te wijzigen die niet wereldwijd uniek zijn. Dit helpt hergebruik van wachtwoorden te voorkomen, wat betekent dat het primaire voordeel van Gibsons techniek gemakkelijk kan worden bereikt door deze tool vandaag de dag op bestaande sites te gebruiken, zonder de extra onveiligheid die zijn plan met zich meebrengt.

Bestaande tweedefactorauthenticatieschemas die telefoons of soortgelijke apparaten gebruiken, helpen gebruikersaanmeldingen vandaag al te beschermen, zodat u niet onmiddellijk kwetsbaar bent voor identiteitsdiefstal als uw apparaat wordt gestolen. De toegevoegde De veiligheid van tweefactorauthenticatie ligt in het feit dat noch het apparaat, noch het wachtwoord kan worden gebruikt als het zonder het andere wordt gestolen. De techniek van Gibson is grotendeels bestand tegen opname in een tweefactorauthenticatie, waardoor dit beschermingsniveau niet beschikbaar.

TL; DR:

Gibsons authenticatietechniek creëert niet voldoende voordelen om de extra beveiligingskosten die het met zich meebrengt te overwinnen. Deze kosten vormen een fundamenteel onderdeel van het schema zelf en kunnen waarschijnlijk niet worden uitgewerkt zonder het hele ontwerp te schrappen.

Je zou kunnen zeggen dat het beter is dan niets, maar je kunt niet beweren dat het beter dan alles wat we al hebben.

Gibsons Updates

Gibson kondigde onlangs enige aanvullende bescherming tegen phishing aan omdat dit een grote kritiek was. Hun bescherming is deze: als u GEEN QR-codes, mobiele telefoon, enz. Gebruikt en in plaats daarvan een authenticatieagent op uw systeem hebt (bijvoorbeeld in de browser), dan kan de server controleren of de authenticatie antwoord komt van hetzelfde IP-adres als het verificatieverzoek. Dit is goed en wel, maar het hele doel van dit protocol is om uw identiteit naar uw mobiele telefoon te verplaatsen. Als de enige veilige manier om het protocol te gebruiken, is om de kern ervan niet te gebruiken functie, dan moeten we misschien opnieuw nadenken over wat we proberen te bereiken.

Theoretisch zou u kunnen uw mobiele telefoon blijven gebruiken als (en alleen als) uw mobiele telefoon wist dat het hetzelfde IP-adres gebruikte als uw computer. Wat het natuurlijk niet kan weten omdat het het IP-adres van uw computer niet kent.

Een betere oplossing

Zoals eerder vermeld, als de authenticatiemaatregel zich in uw browser bevindt, , dan wordt het hele phishing-probleem onmiddellijk opgelost zonder enige inspanning of verificatie door de gebruiker. Zelfs de minst capabele gebruiker kan “niet worden misleid om zich te authenticeren op de verkeerde site, omdat het authenticatietoken van de site is gekoppeld aan de domeinnaam en de browser heeft gewonnen” authenticatie naar het verkeerde domein niet toestaan. Dit is een techniek die vandaag al wordt gebruikt, is volledig automatisch en vereist geen medewerking van de site of enige intelligentie van de kant van de gebruiker.

Deze methode kan worden versterkt door een tweede authenticatiefactor te vereisen (zoals een in de tijd variërende sleutel op een mobiele telefoon) die, nogmaals, al beschikbaar en in gebruik is, wat u (met name) beschermt tegen fouten van de kant van de bestemmingssite of het bedrijf.

Wat betreft de bezorgdheid dat authenticatie aan de browserzijde kwetsbaar is voor aanvallen op client-werkstations: hoewel het waar is, is het ook waar dat als uw browser gecompromitteerd is, er geen het gebruik van die browser is veilig , ongeacht het authenticatiemechanisme dat u gebruikt.Malwareschrijvers kunnen (en doen dit al) wachten tot u zich zelf authenticeert met behulp van uw superveilige techniek, en vervolgens het benodigde verkeer stilletjes naar ” eigen uw account, allemaal zonder dat u iets verkeerds ziet. Noch SQRL, noch enig ander authenticatiesysteem kan de gebruiker van een gecompromitteerde browser beschermen, net zo min als deursloten u kunnen beschermen tegen een huisbrand. Brandwerende sloten kopen is geen oplossing.

Where Next

Als u “op zoek bent naar een absolute garantie voor bescherming tegen nabootsing , kijk dan naar het Fido U2F-token. Deze standaard schijnt waar SQRL tekortschiet, en geeft je gegarandeerde immuniteit tegen MITM-aanvallen (bijv. phishing). Dit gebeurt door niet alleen de gebruiker te authenticeren, maar ook het kanaal, zodat je “gegarandeerd dat (a) uw account” niet kan worden geauthenticeerd zonder het token, en ook (b) dat uw token alleen kan worden gebruikt om een verbinding met de machine waaraan het is gekoppeld, te authenticeren. Zie dit antwoord voor meer informatie.

Reacties

• Over het eerste punt : voor zover ik begrijp, is hier over nagedacht en een optie is om de website waarop u zich laat authenticeren verantwoordelijk te laten zijn voor de omleiding. Dus bij het inloggen wordt u doorgestuurd naar de pagina van de echte bank ‘, niet naar de aanvaller. Over het tweede punt, hetzelfde gebeurt vandaag met gebruikers van tools zoals LastPass. Tenzij u een beveiligingsmechanisme instelt (bijvoorbeeld een pincode), worden al uw wachtwoorden ook gestolen. Waarom kan ‘ niet hetzelfde zijn voor SQRL? Voor zover ik uit de specificatie begrijp, kan de gebruiker ook een back-up maken van zijn identiteit, zelfs op papier (als een QR-code).
• En over het derde punt: hetzelfde gebeurt met de meeste gebruikers die geen ‘ gebruik geen wachtwoordbeheerder door simpelweg een enkele gebruikersnaam / wachtwoord te gebruiken op verschillende websites. Of, met gebruikers van wachtwoordbeheerders, wiens ” identiteit ” is verspreid over verschillende websites, maar is opgeslagen op één enkele locatie (LastPass ‘ servers, 1Password-database, enzovoort). Dus het ‘ is niet echt een SQRL-fout. Al met al, hoe meer ik over SQRL lees, hoe meer ik de voordelen ervan zie in vergelijking met de huidige alternatieven. Stel dat je over Steve Gibson zegt, maar SQRL lijkt me echt een goed alternatief.
• ” De waarschuwing is al in de hoofden van gebruikers met betrekking tot wachtwoordbeveiliging vertalen zich niet noodzakelijkerwijs naar nieuwe authenticatietechnieken zoals deze.. ” Dit is een uitstekend punt, en de strijd is al verloren gegaan door marketing. QR-codes worden gezien als een gemakkelijke manier om dingen voor elkaar te krijgen, niet als een mogelijke aanvalsvector. Gebruikersnaam / wachtwoord-paren werden in ieder geval EERST gebruikt als een authenticatiemechanisme, niet als een marketingtool.
• @jpkrohling: met betrekking tot wachtwoordmanagers, zou ik vermoeden dat de meeste gebruikers van dergelijke software hun hoofdwachtwoord NIET opslaan op hun mobiele apparaat, juist omdat ze beseffen hoe gevaarlijk dat is. Ik heb één fysieke kopie van mijn hoofdwachtwoord op een veilige locatie, maar geen elektronische kopieën. De aanvallen die toegang zouden geven tot mijn hoofdwachtwoord zijn anders dan die waarmee een sitewachtwoord in gevaar zou komen, en zijn veel minder waarschijnlijk. (Vooral omdat het aanvallen van mijn wachtwoorddatabase zou betekenen dat ik persoonlijk moet worden aangevallen, in plaats van een grote gecompromitteerde site.)
• @jpkrohling Noch LastPass noch KeePass slaat ergens een hoofdwachtwoord op. Het ‘ wordt gebruikt om uw wachtwoorddatabase te ontgrendelen, maar het is niet ‘ opgeslagen. Dit is fundamenteel anders dan het hebben van een enkele sleutel die zelf overal wordt gebruikt.

SQRL zeker is niet zonder gebreken, maar het is zeker superieur aan de meeste primaire authenticatieoplossingen die tegenwoordig veel op internet worden gebruikt in termen van beveiliging en (en dit is belangrijk) bruikbaarheid. Sta me toe het uit te leggen.

Misvattingen

Laat me eerst een paar van de misvattingen ophelderen die aanwezig zijn in sommige van de andere antwoorden op deze vraag. Veel van deze antwoorden zijn verouderd en werden geschreven voordat wijzigingen in de SQRL-documentatie die de problemen aanpakken die erin worden gepresenteerd, terwijl anderen onnodige nadruk lijken te leggen op tekortkomingen in SQRL die ook aanwezig zijn in veel andere veelgebruikte bestaande authenticatieoplossingen, terwijl de voordelen ervan worden genegeerd. Dus laten we hier een paar misvattingen uit de weg ruimen, zullen we?

Mythe: SQRL vereist het scannen van QR-codes om te werken

Dit is gewoon niet waar. QR-codes zijn handig waardoor SQRL gemakkelijker te gebruiken is op computers waarop de gebruiker geen SQRL-clientsoftware heeft ingesteld. Op de website van SQRL staat het volgende:

Drie manieren om te gaan….smartphone optioneel:

Hoewel de oorspronkelijke inspiratie voor de ontwikkeling van dit systeem een smartphone was die een QR-code scant op de inlogpagina van een website, maakt een kleine toevoeging aan dat model nog twee belangrijke bedieningsmodi mogelijk: maak van de afbeelding van de QR-code ook een klikbare link naar dezelfde URL die in de QR-code is gecodeerd. Dit levert drie manieren op om in te loggen:

• Scan de code met een smartphone: Gebruik de model hierboven beschreven, scant de smartphone van een gebruiker de QR-code die op de inlogpagina van een website verschijnt en wordt de gebruiker aangemeld bij die site.
• TAP DE CODE op een smartphone: Om in te loggen op een website OP de smartphone, wanneer de visuele SQRL-code ook een URL-achtige link is (met sqrl: // als het schema) De SQRL-app die op de smartphone is geïnstalleerd, ontvangt die link en logt de gebruiker veilig in op de site op de telefoon.
• Klik op de code op een desktop- of laptopscherm : Om het SQRL-systeem op een desktop- of laptopsysteem te gebruiken, zou een desktop-SQRL-applicatie worden geïnstalleerd en zichzelf registreren om sqrl: // links te ontvangen. (Dit is vergelijkbaar met de manier waarop een e-mailprogramma zich registreert om mailto: links te ontvangen.) Hierdoor kan dezelfde oplossing worden gebruikt door gebruikers op hun desktop als op hun smartphones. Wanneer een website een SQRL-code aanbiedt, klikt de gebruiker gewoon op de code met zijn muiscursor en de lokaal geïnstalleerde SQRL-app zal verschijnen, om zijn SQRL-wachtwoord vragen, het domein bevestigen en vervolgens inloggen.

Mythe: de SQRL-hoofdsleutel is volledig onversleuteld en onbeschermd op uw telefoon opgeslagen

Ik weet niet zeker waarom sommige mensen dit hebben gemaakt veronderstelling, aangezien het mij duidelijk lijkt dat dit niet het geval zou zijn. De SQRL-hoofdsleutel wordt op ongeveer dezelfde manier beschermd als u een wachtwoorddatabase zou beschermen: met een sterk hoofdwachtwoord. Als u de telefoon van een gebruiker steelt, krijgt u niet automatisch toegang tot zijn online identiteit, tenzij u ook zijn hoofdwachtwoord had. Meer details over sleutelbeheer worden uitgelegd op de pagina op SQRL Client- Side Key Management op de website van SQRL.

Mythe: als uw hoofdsleutel wordt gestolen, kunt u uw inloggegevens niet wijzigen

Dit is ook onjuist. SQRL biedt een ingebouwde manier om de echte accounthouder in staat te stellen zijn inloggegevens bij te werken in het geval van een gecompromitteerde sleutel. Deze functie staat bekend als Identity Lock:

“Identity Lock” voorkomt identiteitsverandering & staat herstel toe: Dit is ook significant genoeg om een eigen gedetailleerde beschrijvingspagina te verdienen: “ Het identiteitsvergrendelingsprotocol ” (pagina 4 in het linkblok onderaan deze pagina.) de identiteit van de gebruiker is vastgesteld met een webserver, de SQRL c lient is niet in staat om die identiteit te wijzigen. Dit betekent dat als het ergste gebeurde, en een zeer zwak en gemakkelijk te raden wachtwoord werd gebruikt, of de telefoon of desktop van een gebruiker werd gehackt om hun identiteit te verkrijgen, de hoofdsleutel en het wachtwoord, geen enkele kwaadwillende derde partij kan de online identiteit van de gebruiker wijzigen om ze te blokkeren van hun eigen online accounts. En bovendien, door vervolgens een normaal offline “Identity Unlock Key” te laden, kan de ware eigenaar van zijn identiteit met pensioen gaan en zijn verloren of gestolen online identiteit vervangen door in wezen terug te nemen van elke aanvaller, waardoor hun eerdere identiteit onbruikbaar wordt.

Aannemelijk: SQRL is kwetsbaarder voor phishing dan bestaande authenticatieoplossingen

Oké, dus dit is eigenlijk gedeeltelijk waar. Bij gebruik van SQRL door het scannen van een QR-code is er inderdaad zeer weinig bescherming tegen phishing. Tenzij de gebruiker ervoor zorgt dat de website die in de URL-balk van zijn browser wordt weergegeven, dezelfde is als de website die wordt weergegeven door de SQRL Client-app, zou hij een inlogsessie voor de aanvaller kunnen autoriseren. Dit is nog steeds beter dan wachtwoorden, waarbij ze “zouden de phisher permanente toegang geven tot hun account (en alle andere accounts die ze elders hebben die hetzelfde wachtwoord delen) totdat ze hun wachtwoord wijzigen, maar niet zo goed als andere oplossingen die integreren met de browser van de gebruiker, zoals U2F-sleutels , WebAuthn, clientcertificaten en (onder bepaalde voorwaarden) wachtwoordbeheerders.

Wanneer u echter een SQRL-client gebruikt op hetzelfde apparaat waarmee u zich aanmeldt, heeft SQRL enige bescherming tegen phishing aanwezig. Deze beveiligingen worden uitgelegd op de website van SQRL, onder de sectie over Hoe SQRL phishingaanvallen kan dwarsbomen .Er is ook de mogelijkheid om SQRL te integreren met browsers (mogelijk via plug-ins) om een veel sterkere bescherming te bieden tegen phishingaanvallen; vergelijkbaar met oplossingen zoals WebAuthn en clientcertificaten.

Over het algemeen zou ik SQRL rangschikken op ongeveer hetzelfde niveau als wachtwoordmanagers voor phishing-bescherming. Het kan een sterke bescherming bieden tegen phishing wanneer het wordt geïnstalleerd op hetzelfde apparaat waarop de gebruiker inlogt, maar biedt minimale bescherming wanneer het op een ander apparaat wordt geïnstalleerd.

Vergelijking met alternatieven

Laten we nu SQRL vergelijken met bestaande veelgebruikte authenticatieoplossingen.

Wachtwoorden

SQRL is in veel opzichten veel beter dan wachtwoorden. Het is niet alleen handiger om te gebruiken als ze eenmaal zijn ingesteld. omdat gebruikers zich geen zorgen hoeven te maken over het onthouden of opnieuw typen van meerdere verschillende wachtwoorden voor elke site, maar het beschermt ook tegen hergebruik van wachtwoorden, zwakke wachtwoorden, keylogging en, tot op zekere hoogte, phishing.

Nadelen SQRL heeft vergeleken met wachtwoorden dat het moeilijker te implementeren is voor websitebeheerders, niet zo vaak wordt gebruikt, meer tijd nodig heeft om in eerste instantie op te zetten, enige inspanning vereist om over te zetten naar een nieuw apparaat en een enkel storingspunt biedt voor alle gebruikersaccounts als de hoofdsleutel wordt gestolen (hoewel deze laatste poin Dit is ook het geval voor wachtwoorden als een gebruiker op elke site hetzelfde wachtwoord gebruikt).

Wachtwoordmanagers

In veel opzichten lijkt SQRL sterk op wachtwoordmanagers. Ze bieden allebei een enkel, gecentraliseerd vertrouwensanker dat dient als een soort authenticatieproxy tussen gebruikers en individuele services. Er zijn echter een paar manieren waarop SQRL superieur is aan wachtwoordmanagers.

Het belangrijkste voordeel dat ik denk dat SQRL ten opzichte van wachtwoordmanagers heeft, is dat het gemakkelijker en veiliger is om te gebruiken op niet-vertrouwde of slechts gedeeltelijk vertrouwde computers. Stel dat een gebruiker zich wil aanmelden bij een website met een computer in een openbare bibliotheek. Met een wachtwoordbeheerder moet hij het wachtwoord voor die site op zijn telefoon openen en het handmatig opnieuw typen op de computer, of zijn wachtwoordbeheerder en wachtwoorddatabase op de bibliotheekcomputer, ontgrendel de database met zijn hoofdwachtwoord en log vervolgens in. Het eerste scenario is onhandig voor de gebruiker en geeft het wachtwoord van de gebruiker in platte tekst voor die ene site weer aan de niet-vertrouwde computer (en aan malware op de niet-vertrouwde computer, inclusief keyloggers). Het tweede scenario is nog erger, omdat het beide onhandig is en de volledige, gedecodeerde wachtwoorddatabase en het hoofdwachtwoord van de gebruiker aan de niet-vertrouwde computer blootstelt. Met SQRL hoeft de gebruiker alleen een QR-code op het scherm van de niet-vertrouwde computer te scannen, wat veel handiger is voor de gebruiker, en slechts één inlogsessie (zonder herbruikbare inloggegevens zoals een wachtwoord) aan de niet-vertrouwde computer blootstelt .

Een ander voordeel dat SQRL heeft ten opzichte van wachtwoordbeheerders is dat het gemakkelijker is om te herstellen van het worstcasescenario: de wachtwoorddatabase / hoofdsleutel van de gebruiker wordt gestolen. Met een wachtwoordbeheerder niet hoef je alleen je wachtwoord op elke site te wijzigen, je zou je ook zorgen moeten maken dat de aanvaller je wachtwoorden wijzigt (waardoor je mogelijk geen toegang meer krijgt tot je account). De aanvaller heeft ook het voordeel dat hij beschikt over een lijst met alle sites die je hebt account ingeschakeld, waardoor misbruik van de diefstal van een wachtwoorddatabase veel gemakkelijker wordt. Met SQRL is het gestolen van uw hoofdsleutel nog steeds een vreselijke situatie, maar de aanvaller heeft geen lijst met sites waarop u een account heeft (in plaats daarvan moet u raden ), en kan uw wachtwoord niet wijzigen om u buiten te sluiten van uw account. Zodra u uw identiteitsontgrendelingssleutel heeft geladen, is het ook een beetje handiger om uw inloggegevens op elke site te wijzigen, aangezien de SQRL-client dit automatisch voor u kan doen voor elke site die u bij het inloggen bezoekt. ( via elk “wachtwoord wijzigen” -formulier.)

Ten slotte denk ik dat SQRL een klein maar belangrijk voordeel heeft ten opzichte van wachtwoordbeheerders met betrekking tot het doel om wachtwoorden volledig te vervangen, en dat is dat sites de mogelijkheid hebben om af te dwingen gebruik van SQRL in plaats van traditionele wachtwoorden. Zolang gebruikers nog steeds de optie hebben van slechte beveiliging en hetzelfde wachtwoord op elke site hergebruiken, is dat iets dat nog steeds zal gebeuren. Als SQRL op grote schaal wordt gebruikt, kunnen sites het gebruik ervan wachtwoorden. Dat kan niet worden gedaan met wachtwoordbeheerders, omdat ze afhankelijk zijn van het gebruik van wachtwoorden om te werken.

In termen van nadelen kan ik eigenlijk geen situatie bedenken waarin SQRL zou per se slechter zijn dan wachtwoordmanagers in termen van veiligheid. Het belangrijkste nadeel van SQRL is dat het ondersteuning nodig heeft van website-exploitanten, terwijl wachtwoordbeheerders geen speciale ondersteuning van bestaande services nodig hebben. Dit betekent dat u nu wachtwoordmanagers kunt gaan gebruiken, maar SQRL zal moeten wachten tot sites het implementeren voordat het kan worden gebruikt. Dit is een aanzienlijke belemmering voor adoptie.

Clientcertificaten

Het belangrijkste voordeel dat SQRL heeft ten opzichte van clientcertificaten is er een van gemak. Clientcertificaten zijn momenteel moeilijk in te stellen, moeilijk over te dragen tussen computers en hebben privacyproblemen wanneer hetzelfde certificaat op verschillende sites wordt gebruikt. Hoewel we theoretisch een systeem zouden kunnen bouwen met behulp van clientcertificaten die deze problemen zouden oplossen, zou er ook het probleem zijn van een slechte integratie met website-UIs en webservers, die moeilijker op te lossen zijn. Ik zal hier niet teveel in detail treden, aangezien er al een uitstekend artikel is over de bruikbaarheidsproblemen van clientcertificaten op browserauth.net.

In termen van beveiliging hebben clientcertificaten het nadeel dat een CA vereist is. Dit is (potentieel) duur en vereist vertrouwen in de externe CA. Bovendien, als u ervoor kiest CAs te negeren en in plaats daarvan uw certificaten zelf te ondertekenen, heeft u te maken met het intrekken van certificaten. Clientcertificaten hebben ook dezelfde beveiligings- en gemaksproblemen als wachtwoordbeheerders wanneer gebruikers willen inloggen op een niet-vertrouwde computer; ze moeten hun certificaat overbrengen naar de niet-vertrouwde computer, wat zowel ongemakkelijk is als hun hoofdidentiteit mogelijk blootstelt aan malware op die computer.

Kortom, totdat iemand met een betere, gebruiksvriendelijke oplossing komt met clientcertificaten die (in ieder geval de meeste van) deze problemen oplossen, ik geloof niet dat clientcertificaten een serieuze concurrent zijn van SQRL (of, wat dat betreft, van wachtwoorden).

2-Factor Authentication

Ik dacht dat ik dit zou zeggen: SQRL en 2-factor authenticatie zijn niet wederzijds exclusief. SQRL is een vervanging voor de eerste factor in 2FA: wachtwoorden. Andere aanvullende maatregelen zoals OTP-codes of FIDO U2F-sleutels kunnen nog steeds worden gebruikt met SQRL.

WebAuthn

Nu hier waar dingen interessant worden. WebAuthn is een nieuwe (nou ja, nieuwer dan SQRL) W3C-standaard die is ontworpen om een standaard API te bieden die websites kunnen gebruiken om gebruikers te verifiëren met openbare sleutels op internet. Net als SQRL, het ondersteunt het gebruik van de telefoon van de gebruiker om een inlogsessie op een extern apparaat te verifiëren , naast een paar andere verificatiemethoden (zoals beveiligingssleutels van de tweede factor) .

Dit is waar SQRL eindelijk zijn match ontmoet, tenminste vanuit een beveiligingsperspectief. WebAuthn biedt niet alleen dezelfde bescherming tegen hergebruik van wachtwoorden, zwakke wachtwoorden en keylogging als SQRL, maar het biedt ook een nog sterkere bescherming tegen phishing door integratie met de browser van de gebruiker zelfs bij het autoriseren van een login sessie voor een pc waarop de gebruiker de clientsoftware van de authenticator niet eerder heeft ingesteld. Dit is mogelijk omdat WebAuthn in die situatie rechtstreeks met de browser van de gebruiker communiceert met behulp van tweerichtingscommunicatieprotocollen zoals Blutooth of NFC in plaats van te communiceren met de website die de gebruiker gebruikt via een eenrichtings-QR-code.

Vanuit het oogpunt van bruikbaarheid zijn de zaken een beetje ingewikkelder. Aan de oppervlakte wint WebAuthn tenminste weer. Omdat het een W3C-standaard is die al implementaties heeft in meerdere browsers kunnen gebruikers in theorie WebAuthn meteen gaan gebruiken zonder software van derden te hoeven installeren. In de praktijk richten de meeste bestaande WebAuthn-implementaties zich echter op het gebruik ervan als een vorm van tweede factor authenticatie, of als een manier om een gebruiker opnieuw te authenticeren. die zich eerder op hetzelfde apparaat hebben aangemeld via een andere inlogmethode (meestal een wachtwoord). Als primaire authenticatiefactor ontbreekt het WebAuthn nog steeds vrij weinig aan haalbare implementaties.

Andere kleine overwegingen zijn onder meer het feit dat SQRL een gebouw t-in-methode voor het roteren van de sleutels van accounts in het geval van een gestolen hoofdsleutel, terwijl WebAuthn afhankelijk is van websites om hun eigen systeem voor het intrekken van sleutels te implementeren, en het feit dat WebAuthn bepaalde optionele hardware nodig heeft (zoals Bluetooth of NFC) om om te authenticeren bij een externe machine, terwijl SQRL op elke machine met een werkende display kan werken.

Over het algemeen denk ik dat het zeer waarschijnlijk is dat WebAuthn SQRL uiteindelijk overbodig zal maken. SQRL heeft voorlopig misschien wat ademruimte, maar WebAuthn heeft veel meer steun van browserverkopers, site-operators en andere externe organisaties (zoals de W3C). Zodra WebAuthn een paar implementaties heeft gekregen die het gebruik ervan als primaire authenticatiefactor mogelijk maken, verwacht ik dat het het web zeer snel zal gaan overnemen.

Voorbehoud

SQRL is nog in actieve ontwikkeling, dus het materiaal dat in dit antwoord wordt gepresenteerd, is onderhevig aan verandering. Naarmate de ontwikkeling vordert, verwacht ik dat enkele van de kwetsbaarheden en onzekerheden in dit antwoord zullen worden aangepakt. De meeste discussie vindt momenteel plaats in de SQRL-nieuwsgroep op grc.com.

SQRL is een handige oplossing voor het probleem van de gebruikersnaam / wachtwoord paradox. (dwz de afweging gemak / veiligheid) zonder een derde partij . Het biedt een eenvoudig alternatief voor het meest populaire authenticatiemodel (gebruikersnaam & wachtwoord), met vrijwel geen concessies aan de beveiliging. Het is praktisch net zo veilig als alle gangbare authenticatiemodellen die tegenwoordig worden gebruikt, zolang u zich nog steeds bewust bent van de beveiliging . Als u SQRL gebruikt, betekent dit niet dat u de beste beveiligingspraktijken niet kunt volgen, zoals door dit te combineren met meervoudige authenticatie voor belangrijke accounts.

Het is belangrijk om het punt van SQRL niet te missen. SQRL zelf biedt niet per se betere of slechtere beveiliging. Als de computer / telefoon zelf wordt gecompromitteerd, of als de gebruiker wordt misleid wordt phishing, dan is dit een side-channel aanval in plaats van een directe fout van SQRL zelf. Elke conventionele authenticatiemethode heeft dit probleem van side-channel-aanvallen De onbreekbare eenmalige pad is ook kwetsbaar voor side-channel-aanvallen zoals het compromitteren van de pad zelf, of slechte omringende beveiliging of implementaties.

Als je luisterde naar het oorspronkelijke voorstel van het idee op Steve Gibsons podcast , gevolgd door de Q & A “s, zijn veel van de zorgen die over deze stackthread zijn geuit, beantwoord. Steve zei het zelf ook dat dit zeer “eenvoudige” en “ingenieuze” (zijn woorden) idee zou moeten worden “doorgelicht” en “gehamerd” door beveiligingsexperts, aangezien alleen de tijd zal uitwijzen of dit een veilige oplossing is.

Concluderend, de meeste argumenten tegen SQRL vallen buiten het domein van SQRL zelf, en zijn in plaats daarvan problemen met mensen die een slechte beveiliging toepassen. SQRL introduceert geen nieuwe classificatie van problemen die onze traditionele authenticatiemethoden al niet hebben.

SQRL is uitstekend als het op de juiste manier wordt gebruikt door mensen die bewust zijn van veiligheid. U moet begrijpen dat er altijd een afweging is tussen gemak en veiligheid , en deze oplossing is waarschijnlijk de beste balans van de twee die ik heb gezien.

Reacties

• Bedankt Ansichart. Maar kunnen ‘ t bestaande authenticatieoplossingen eenvoudigweg dezelfde of superieure beveiligingskenmerken behouden als SQRL en vervolgens automatisering gebruiken om hun gebruikersgemak te vergroten? Welke fundamentele eigenschap van SQRL ‘ s gebruikersgemak is niet te wijten aan automatisering? Ik vraag het omdat als een gebruiker twee zwarte dozen heeft die hetzelfde doen; een met het label ” Oudere ” en de andere met het label ” SQRL ” en ze kunnen beide worden ontworpen / geautomatiseerd, hebben dezelfde interface / knoppen aan de buitenkant van de doos – welke toegevoegde waarde biedt SQRL?
• Het lost het probleem van de wachtwoordparadox op zonder een derde partij te hoeven gebruiken.
• Ik begrijp het. Dus als iemand ‘ het risico van eenmalige aanmelding van derden niet wil en ‘ zijn wachtwoorden niet wil genereren / opslaan met als wachtwoordbeheerder kan SQRL een stapje hogerop komen. Maar als SQRL een mobiele black-box is die om een wachtwoord vraagt om de hoofdsleutel te ontgrendelen die wordt gebruikt om SQRLIDs opnieuw te genereren / op te slaan en vervolgens back-channel-koppeling uit te voeren van client ‘ s cookie / QR session_id met server ‘ s opgenomen SQRLID om in te loggen – hoe is dit een andere mobiele black-box dan een mobiele wachtwoordbeheerder met auto-login via hetzelfde back-channel; of een twee-partij mobiele client cert-plug-in met auto-generatie & login via hetzelfde back-channel?
• Ik heb een aantal belangrijke bewerkingen van mijn oorspronkelijke bericht gedaan na enige tweede overwegingen en nadere lezing van wat anderen hebben gezegd, want ik heb het misschien overdreven. Ik veronderstel dat als de mobiele telefoon de centrale sleutel is, het probleem verschuift en het belangrijker zou worden om een sterkere beveiliging op je telefoon te hebben. Steve Gibson brengt dit ook ter sprake in de Q & A podcast.

Ik ben het tot op zekere hoogte eens met de andere opmerkingen, maar ik denk dat er enkele voordelen zijn:

Om SQRL voor u in te schakelen, moet u uw hoofdsleutel maken en deze op uw telefoon opslaan . GEDAAN. Vanaf dat moment kunt u inloggen op ELKE website die “SQRL” gebruikt.En dat zou een anonieme login zijn – zolang u besluit geen verdere informatie te verstrekken.

Dat is VEEL eenvoudiger dan werken met je eigen certificaat; of het aanmaken van expliciete gebruikersaccounts (waarbij u waarschijnlijk wordt gevraagd om een geldig e-mailadres op te geven). Misschien zou ik diezelfde master key niet gebruiken voor mijn bank-, amazon-, … rekeningen – maar vooral voor deze “ik zou hier iets willen posten” situaties … perfect. Niet meer “laat Google of Facebook of welke site dan ook weten dat je hier wilt posten”.

Reacties

• I ‘ Ik weet niet zeker of dit echt een geldig punt is – als je ‘ anonieme logins wilt toestaan, waarom zou je dan in de eerste plaats moeite doen om in te loggen? Een simpele captcha zou voldoende zijn om spam te voorkomen.
• Omdat U de anon-login bent, weigert u om informatie over uw identiteit te verstrekken; niemand kan het vervalsen.
• Het klinkt bijna als een halfbakken re-hash van Windows CardSpace.
• Of een captcha, als je inlogt op een gebruiker die nog nooit heeft ingelogd ervoor.
• ” Om SQRL voor u in te schakelen, moet u uw hoofdsleutel maken en deze op uw telefoon opslaan. ” Eigenlijk hoef je ‘ dat niet te doen, je hebt alleen wat software op je pc nodig die sqrl: // URLs kan openen.

SQRL biedt geen baanbrekende verbeteringen. QR-codes zijn een optisch streepjescodeformaat dat handig is voor de distributie van korte inhoud – niets meer.

Elke “auto-login” -situatie die SQRL probeert op te lossen, kan in plaats daarvan gewoon een clientcertificaat gebruiken dat is opgeslagen op de mobiele telefoon.

Hypothetisch zou een QR-barcode op een HTTPS-pagina een door de server ondertekende of gecodeerde versie van het clientcertificaat (of een vergelijkbare referentie) kunnen retourneren zoals eerder bekend bij de server, maar waarom? Voor het verlopen van de inloggegevens? De site kan een verlopen inloggegevens eenvoudigweg afwijzen.

Dus het grootste beveiligingsprobleem heb ik hiermee protocol is: Het vierkante wiel opnieuw uitvinden .

Update

Als ik nieuwe antwoorden en opmerkingen lees, wil ik erop wijzen hoe gemakkelijk het is om zoiets als SQRL te doen via eenvoudige automatisering van volwassen bestaande technologie :

1. Website vraagt om CAPTCHAs of soortgelijke “ik” een menselijke “verificatie. Zodra de gebruiker heeft voldaan (POSTed), retourneert de website een HTTP 403.7 - Client Certificate Required of een vanilla 403-fout.
2. Aangepaste 403-paginas zijn eenvoudig genoeg om in te stellen en kunnen behoorlijk mooi en gebruiksvriendelijk zijn. Kan zelfs de hieronder vereiste functionaliteit opstarten op een manier die vergelijkbaar is met de “Adobe Reader vereist” -prompts op veel websites.
3. Aangepaste 403-pagina bevat enige opmaak waarop een aangepaste browserplug-in reageert. Laten we deze aangepaste plug-in “S403L-compatibel” noemen in de geest van “SQRL-conformiteit”.
4. De S403L-plug-in genereert een standaard clientcertificaat, dat is beveiligd in de gebruikelijke gecodeerde browsercertificaatcache (of een derde- partycache als de sleutelopslagversleuteling van je browser niet goed is). De plug-in maakt een standaard-CSR voor het clientcertificaat en stuurt de CSR naar de URL die is opgegeven in de 403-opmaak. (bijv. <s403l ref="https://www.example.com/S403L" />)
5. De S403L-compatibele server gebruikt de session_id van de gebruiker (opgehaald uit cookies of queryreeks) om continuïteit te creëren met Stap 1 en retourneert vervolgens de CSR zoals ondertekend door de server. Algemene serverauthenticatie accepteert elk clientcertificaat dat is ondertekend door de server (en dus voldoet aan de registratiecriteria die in stap 1 zijn vereist).
6. De S403L-plug-in slaat dat ondertekende clientcertificaat op in de cache van de browser. Van daarna kan de standaardbrowser zonder plug-in-assistentie “automatisch inloggen” op de server op de standaard SSL / TLS-manier totdat het certificaat verloopt.

De “mobiele” en “visuele” aard van SQRL is een soort misleiding, aangezien het geen losstaande tweefactorauthenticatie biedt en je nu twee computers nodig hebt om op internet te navigeren in plaats van één. Tenzij u de USB-webcam van uw desktop op zijn eigen monitor richt.

De wisselwerking tussen wachtwoorden en certificaten is goed gedefinieerd in de beveiligingsgemeenschap: wachtwoorden passen in een menselijk brein; certificaten passen niet in een menselijk brein ( meestal ) maar kan gekke entropie en goede PKI-beheerfuncties hebben (vervalt , intrekking, beleidsextensies, enz.). SQRL past netjes in geen van beide kamp; en als het afdrijft naar het minder-menselijke meer-computerkamp zoals het lijkt, heeft het jaren van ontwikkeling en veiligheidsanalyse om bestaande X.509-functies te herhalen.

Opmerkingen

• > kan in plaats daarvan gewoon een clientcertificaat gebruiken dat op de mobiele telefoon is opgeslagen.— behalve dat deze technologie al jaren bestaat op zowel mobiel als desktop, en ‘ niet zo wijdverspreid is als je zou willen. En in tegenstelling tot het clientcertificaat, vereist SQRL ‘ niet dat u uw echte identiteit aantoont om een ” SQRL-identiteit “. Als u dat wilt, kunt u zoveel identiteiten aanmaken als u wilt. Dit betekent dat het voordeel ten opzichte van clientcertificaten is dat u anonimiteit geniet van het auth-protocol ‘ s kant.
• @jpkrohling Het is een algemene misvatting dat clientcertificaten vereisen identiteitsverklaring om te gebruiken. Dat is een vereiste van commerciële ondertekenende autoriteiten om hun wereldwijd uitwisselbare vertrouwensketens te gebruiken. In de praktijk kan een clientcertificaat eenvoudigweg een anonieme CSR zijn die door de client is gemaakt en is ondertekend door een specifieke server, nadat aan de gewenste criteria is voldaan (CAPTCHAs, eerdere account, enz). Certificaten kunnen ook een ingebouwde vervaldatum hebben. Type 40-L QR-streepjescodes kunnen desgewenst het 1KB X.509-clientcertificaat verzenden / opslaan.
• Oké, waar, mijn fout. Vanuit dit perspectief zou de client (bijvoorbeeld mobiele app) een clientcertificaat kunnen genereren voor elke website die de gebruiker registreert. Dit klinkt duurder dan het hashen van informatie, maar kan een interessante oplossing zijn. In elk geval ben ik nog steeds niet ‘ het eens met uw beweringen dat SQRL erger dan nutteloos is.
• Ik was misschien hard tegen die bewoording en zal het verwijderen. Maar ik ‘ zie SQRL niet als iets anders dan een meer sexy manier om onderhandelde klantreferenties te verspreiden; en een die niet ‘ t enkele van de subtiele problemen heeft opgelost die worden aangepakt door volwassen authenticatieschemas. Een wachtwoordbeheerder is vervelend (ik ‘ doe geen moeite met browserintegratie omdat ik ‘ paranoïde ben) maar ik weet dat alleen ik en één website deel elk eenmalig wachtwoord in mijn gecodeerde sleutelopslag. Ik ‘ hoef me geen zorgen te maken over mooie nieuwe hash / auth-schemas, alleen de kwaliteit van de PRNG / TRNG die mijn wachtwoordbeheerder gebruikt om wachtwoorden te genereren.
• @LateralFractal wat maakt het uit of het ‘ nieuw is of niet? SQRL maakt gebruikersvriendelijke authenticatie mogelijk waarbij de eerste partij zijn geheim niet onthult aan de tweede partij of een derde partij die mogelijk de ‘ beveiliging van de tweede partij in gevaar heeft gebracht. Het ‘ is een poging om een reëel probleem op te lossen dat tot dusverre niemand anders heeft kunnen oplossen.

Ik wil graag ingaan op de eerste vraag: “een van de problemen die ik kan bedenken is als de QR-lezer gecompromitteerd is, om www.google.com weer te geven in plaats van www.nsa-super-secret-place.gov/123 “:

De hoofdsleutel wordt samen met het websiteadres (FQDN) gebruikt als de seed voor HMAC. Dus hoewel de QR-code een geheel andere URL kan coderen, onthult het protocol NIET de authenticatiecode die normaal gesproken naar www.google.com zou worden gestuurd (in het voorbeeld).

Ten tweede vergeten veel van de bijdragers de belangrijkste doelstellingen bij het uitwerken van dit idee:

1. anonimiteit door geen gebruik te maken van derden
2. gebruiksgemak
3. het is niet nodig om geheime inloggegevens in te typen op niet-vertrouwde computers

Ik geloof dat de protocollen deze volledig aanpakken!

Er zijn echter compromissen die feitelijk komen uit het eerste doel. Als er geen derde partij betrokken is bij de authenticatie, hoe kan men dan hun authenticatiegegevens intrekken? Bovendien is de beveiliging van de hoofdsleutel een voor de hand liggende zorg. Ik stel me voor dat dit goed wordt beschermd door toekomstige mobiele apparaten in een HSM-achtige chip. Tot die tijd is de sleutel slechts een mobiel apparaat met een bestandspin, beschermd door een wachtwoord, hoewel PBDKF2 ervoor zorgt dat het erg traag is om het daadwerkelijk brute kracht te geven.

Opmerkingen

• Nogmaals, wat is ‘ er nieuw aan dit idee? Het lijkt mij een primitieve variant op de inmiddels ter ziele gegane Windows CardSpace.
• Ja, je hebt gelijk over CardSpace. Dan is er U-Prove, ook eigendom van Microsoft. De vraag is hoe je CardSpace of U-Prove zou gebruiken op een computer die je niet vertrouwt (internetcafé of vriendencomputer). Dat is wat Steve heeft toegevoegd.
• Ah, oké, dat ‘ is wat ik miste. Ik ben het nog steeds eens met @TerryChia dat dit een niet-starter is zonder een intrekkingsmechanisme voor de gebruikerssleutels.
• @Xander Er is een intrekkingsmechanisme voor de gebruikerssleutels. grc.com/sqrl/idlock.htm