Ta som vanligt allt som är relaterat till Steve Gibson med en lastbil salt. Obligatorisk attrition.org länk .

Låt oss ta en titt på Gibsons beskrivning av sitt protokoll.

• QR-koden som presenteras nära inloggningen prompt innehåller URL: en för autentiseringstjänsten för webbplatsen. URL: n innehåller ett säkert genererat långt slumptal så att varje presentation av inloggningssidan visar en annan QR-kod. (I kryptokretsar kallas detta långa slumpmässiga nummer som ett ”nonce.”)

• Smarttelefonens SQRL-autentiseringsapp kryper kryptografiskt domännamnet på den webbplats som användaren har skrivit in ”huvudnyckel för att producera ett platsspecifikt offentligt nyckelpar.

• Appen signerar kryptografiskt hela webbadressen i QR-koden med den platsspecifika privata nyckeln. Eftersom webbadressen innehåller ett säkert långt slumpmässigt nummer (nonce) är signaturen unik för den webbplatsen och QR-koden.

• Appen ger en säker HTTPS POST-fråga till QR kodens URL, vilket är autentiseringstjänsten för webbplatsen. POST tillhandahåller den platsspecifika offentliga nyckeln och den matchande kryptografiska signaturen för QR-kodens URL.

• Den autentiserande webbplatsen tar emot och bekräftar POST-frågan genom att returnera en standard HTTP ”200 OK” utan något annat innehåll. SQRL-appen bekräftar att den användarsignerade QR-koden har skickats.

• Den autentiserande webbplatsen har webbadressen som innehåller nonce som kom tillbaka från inloggningssidan via användarens Den har också en kryptografisk signatur för den webbadressen och användarens platsspecifika offentliga nyckel. Den använder den offentliga nyckeln för att verifiera att signaturen är giltig för URL: n. Detta bekräftar att användaren som producerade signaturen använde den privata nyckeln som motsvarar den offentliga nyckeln. Efter att ha verifierat signaturen känner den autentiserande webbplatsen igen den nu autentiserade användaren med sin platsspecifika offentliga nyckel.

det största som hoppar ut på mig är användarens ” huvudnyckel ”. Om jag läser protokollet korrekt kontrollerar den enda huvudnyckeln användarens hela onlineidentitet …

Förmodligen lagras denna huvudnyckel i användarens telefon i en applikationsdatabas. Vilket öppnar en enorm gapande attackvektor i form av skadlig kod som är utformad speciellt för att stjäla huvudnyckeln.

Så låt oss jämföra skillnaden mellan vad som händer när ett lösenord komprometteras jämfört med vad som händer när huvudnyckeln antas att du följer goda lösenordspraxis för långa, unika och mycket slumpmässiga lösenord lagrade i en lösenordshanterare, allt du behöver göra är att ändra ett enda lösenord om det blir äventyrat. Vad händer om din huvudnyckel komprometteras? måste på något sätt hämta alla de webbplatser du autentiserade med för att känna igen att din huvudnyckel har äventyrats. Det enda problemet är, eftersom du inte har några andra medel för att autentisera med webbplatsen som användarnamn eller e-postadresser, hur kommer webbplatsen att veta att det faktiskt är du som försöker återkalla huvudnyckeln?

Som allt som kommer ut ur Gibson är detta SRQL-system mycket bristfälligt och erbjuder inga fördelar jämfört med konventionella metoder.

Komma nts

• ” Om du ’ följer bra lösenordsrutiner ” är en enorm varning, och de flesta Netizens gör det inte ’.En del av SQRL ’ s löfte är att minska användarna ’ behöver hålla koll på bästa praxis. Vidare kommer SQRL-specifikationen att kräva att huvudnyckeln lagras krypterad med ett huvudlösenord och kommer att vara omöjlig att göra kraft (inställd för att ta ~ 60-talet för ett försök). Att få lösenordet är ofta inte trivialt eftersom SQRL främjar autentisering utanför bandet (dvs att nyckelloggning av en hackad maskin inte alltid hjälper dig ’). Så medan konsekvenserna av full kompromiss är höga är sannolikheten för kompromiss något låg.
• SQRL kan fortfarande ha brister som behöver åtgärdas, men det hävdar att lösa ett antal problem som finns i befintliga metoder för autentisering, och all kritik mot SQRL som hävdar att den ” ger inga fördelar ” bör innehålla motbevis för dessa påståenden istället för att förvänta sig att påståendet ska accepteras blindt. , detta SRQL-schema är mycket bristfälligt och erbjuder inga fördelar jämfört med konventionella metoder. — Det här ’ verkar inte hjälpa till att svara på frågan, och jag känner faktiskt att du har problem med tekniken på grund av vem som kom med den. Några av de punkter som du nämnde som brister adresseras faktiskt av ” spec ”. Till exempel nämner SQRL själv inte ’ t hur huvudnyckeln är lagrad, men Steve Gibson ’ s kommentarer om det är att en mobil klient, till exempel, skulle kryptera det med ett huvudlösenord med hjälp av en kryptering som i genomsnitt tar 60-talet att utföra.
• Gibson-explicitet adresserar skyddet för huvudnyckeln.
• Håll en andra. Du likställer att din SQRL-huvudnyckel blir stulen till en av dina LastPass-nycklar som stulits. Skulle det inte vara ’ att det skulle vara bättre att jämföra den med att hela din dekrypterade LastPass-lösenordsdatabas stjäls?

Sammantaget verkar protokollet inte öka säkerheten över befintlig teknik. Om du letar efter det bästa sättet att skydda din identitet online är det utan tvekan inte det . Men låt oss gå igenom för-och nackdelar:

Fördelar

Det är omöjligt att ” dela ” ett lösenord i snäv bemärkelse att en skadlig webbplats inte kan använda autentiseringen som tillhandahålls till en webbplats för att logga in på en annan webbplats.

Ett brute-force-angrepp mot autentiseringstoken är inte möjligt.

Inloggningsuppgifter sparas inte på din dator. Detta skyddar dig mot en liten delmängd av Arbetsstationsriktade attacker. Du är särskilt skyddad mot attacker som stjäl ditt lösenord från din dator. Du är inte skyddad mot någon form av sessionskapning eller attacker av webbläsarövertagande, och du är nu också mottaglig för telefonrelaterade attacker. Mer om det senare.

Nackdelar

Denna teknik är farligt mottaglig för MITM-attacker och socialteknik. Förmodligen mer än något annat autentiseringsschema som används, inklusive lösenord. Autentiseringssteget och inledningssteget för inloggning kopplas i sig ur i den meningen att telefonen autentiseras korrekt mot alla presenterade QR-koder, oavsett hur eller var den presenteras för användaren.

Så till exempel en nätfiskewebbplats kan visa en autentisk inloggnings-QR-kod som loggar in angriparen istället för användaren. Gibson är övertygad om att användare kommer att se namnet på banken eller butiken eller webbplatsen i telefonappen under autentisering och kommer därför att vara tillräckligt vaksamma för att motverka attacker. Historien antyder detta osannolikt, och den mer rimliga förväntningen är att det att se rätt namn i appen kommer att falskt försäkra användaren att tro att webbplatsen är legitim eftersom den kunde utlösa den välbekanta inloggningsförfrågan på telefonen. Den försiktighet som redan slås in i användarnas huvuden beträffande lösenordssäkerhet kan inte nödvändigtvis översättas till nya autentiseringstekniker som den här, vilket gör den här appen sannolikt i sig mindre motståndskraftig mot socialteknik.

Denna teknik kombinerar både autentisering och identitet till ett fysiskt objekt som ofta förloras eller blir stulet. I denna mening är det ” är mer som ett pass snarare än ett lösenord. Alla som har din telefon besitter plötsligt uteslutande din identitet: inte bara kan angriparen utge dig, utan utan en andra kopia på en andra telefon ( osannolikt), nu har du tappat förmågan att identifiera dig.Autentiseringsnycklar kan inte återkallas, så utan återhämtning utanför bandet från varje webbplats kan du inte återställa din identitet. Och även om det finns återhämtning utanför bandet, när det konfronteras med två användare, en med identitet och en utan, kan det vara svårt att se varför webbplatsoperatören borde lita på dig.

Denna teknik kombinerar alla dina autentiseringstoken till en enda nyckel om du inte skapar andra manuellt. Detta gör din en nyckel till ett extra saftigt mål för angripare. Dessutom lagras nyckeln på din telefon, vilka enheter har vanligtvis haft skrattretande porös intern säkerhet. Att kombinera ovanligt saftiga mål med undermålig säkerhet gör dig inte säker.

Alternativ

Den mest problematiska aspekten av detta schema är hur dåligt det jämförs med de tillgängliga alternativen.

Det säkraste allmänt accepterade alternativet idag är lastpass, keepass och andra sådana webbläsarintegrerade lösenordssystem. I synnerhet minskar kryptering på klientsidan behovet av att lita på någon tredje part. Och ännu viktigare är att webbläsarintegration gör phishing praktiskt taget omöjligt . LastPass eller KeePass fyller bara lösenordet om det serveras från rätt domän, vilket innebär att om användaren får en skadlig webbplats kommer den inte att ha tillgång till sitt lösenord.

Dessutom lade LastPass nyligen till en funktion vilket stänger av användare för att ändra lösenord som inte är globalt unika. Detta hjälper till att förhindra återanvändning av lösenord, vilket innebär att den primära fördelen med Gibsons teknik lätt kan uppnås med det här verktyget idag på befintliga webbplatser utan den extra osäkerhet som hans schema innebär.

Befintliga andra faktor autentiseringsscheman som använder telefoner eller liknande enheter hjälper till att skydda användarnas inloggningar idag gör det redan på ett sådant sätt att du inte omedelbart är sårbar för identitetsstöld om din enhet blir stulen. säkerheten för tvåfaktorsautentisering ligger i det faktum att varken enheten eller lösenordet kan användas om de blir stulna utan den andra. Gibsons teknik är till stor del motståndskraftig mot att ingå i ett tvåfaktorschema, vilket gör denna skyddsnivå tion ej tillgänglig.

TL; DR:

Gibsons autentiseringsteknik skapar inte tillräcklig fördel för att övervinna de extra säkerhetskostnader som den också medför. Dessa kostnader är en grundläggande del av själva systemet och kan sannolikt inte räknas utan att hela designen skrotas.

Du kan argumentera för att det är bättre än ingenting, men du kan inte argumentera för att det är bättre än vad vi redan har.

Gibsons uppdateringar

Gibson tillkännagav nyligen ytterligare skydd mot nätfiske eftersom detta har varit en stor kritik. Deras skydd är detta: Om du INTE använder QR-koder, mobiltelefon etc. och istället har en autentiseringsagent på ditt system (till exempel i webbläsaren), kan servern kontrollera att autentiseringen svaret kommer från samma IP som autentiseringsbegäran. Detta är bra och bra, men hela syftet med detta protokoll är att flytta din identitet till din mobiltelefon. Om det enda säkra sättet att använda protokollet är att inte använda det ska vi kanske tänka om vad vi försöker åstadkomma.

Teoretiskt skulle du kunna fortsätta använda din mobiltelefon om (och bara om) din mobiltelefon visste att den använde samma IP som din dator. Vilket naturligtvis inte kan veta för att den inte känner till datorns IP-adress.

En bättre lösning

Som anges tidigare, om autentiseringsmåttet finns i din webbläsare, , löses hela nätfiskeproblemet omedelbart utan ansträngning eller verifiering från användaren. Även den minst kapabla användaren kan inte luras att autentisera till fel webbplats eftersom webbplatsens autentiseringstoken är associerad med domännamnet och webbläsaren vann ” inte tillåta autentisering till fel domän. Detta är en teknik som redan används idag, är helt automatisk och kräver inte webbplatsens samarbete eller någon intelligens från användarens sida.

Denna metod kan stärkas genom att kräva en andra autentiseringsfaktor (till exempel en tidsvarierande tangent på en mobiltelefon) som återigen redan är tillgänglig och används idag, vilket skyddar dig (framför allt) mot skruvningar från destinationswebbplatsen eller företaget.

När det gäller farhågor om webbläsarsidan-autentisering är sårbar för klient-arbetsstationsattacker: medan det är sant är det också sant att om din webbläsare är äventyrad, då användningen av den webbläsaren är säker , oavsett vilken autentiseringsmekanism du använder.Skadliga programförfattare kan (och redan gör) vänta på att du autentiserar på egen hand med din supersäkra teknik och sedan tyst skicka den nödvändiga trafiken till ” äga ” ditt konto, allt utan att du ser något fel. Varken SQRL eller något annat autentiseringssystem kan skydda användaren av en komprometterad webbläsare, bara dörrlås kan skydda dig från en husbrand. Att köpa brandsäkra lås är inte en lösning.

Where Next

Om du letar efter en absolut garanti för skydd mot efterliknande , se sedan på Fido U2F-token. Den här standarden lyser där SQRL faller kort och ger dig garanterad immunitet mot MITM-attacker (t.ex. phishing). Det gör det genom att autentisera inte bara användaren utan också kanalen så att du ”garanteras att (a) ditt konto inte kan autentiseras utan token, och också (b) din token kan bara användas för att autentisera en anslutning till maskinen den är ansluten till. Se detta svar för mer information.

Kommentarer

• Om den första punkten : så vitt jag förstår var detta tänkt och ett alternativ är att låta webbplatsen som du autentiserar vara ansvarig för omdirigeringen. Så vid inloggningen omdirigeras du till den riktiga bankens ’ -sida, inte angriparen. Om den andra punkten händer detsamma idag med användare av verktyg som LastPass. Om du inte ställer in någon skyddsmekanism (till exempel PIN) blir alla dina lösenord också stulna. Varför kan ’ inte samma vara sant för SQRL? Såvitt jag förstår av specifikationen kan användaren säkerhetskopiera sin identitet även på papper (som en QR-kod).
• Och om den tredje punkten: detsamma händer med de flesta användare som inte ’ Använd inte en lösenordshanterare genom att helt enkelt använda ett enda användarnamn / lösenord på flera webbplatser. Eller med användare av lösenordshanterare vars ” identitet ” sprids på flera webbplatser men lagras på en enda plats (LastPass ’ servrar, 1Password-databas och så vidare). Så det är ’ inte riktigt ett SQRL-fel. Sammantaget, ju mer jag läser om SQRL, desto mer ser jag fördelarna med att jämföra med nuvarande alternativ. Säg att du säger om Steve Gibson, men SQRL verkar verkligen som ett bra alternativ för mig.
• ” Den försiktighet som redan slogs i huvudet på användare om lösenordsskydd inte nödvändigtvis översättas till nya autentiseringstekniker som den här. . . ” Detta är en utmärkt poäng, och striden har redan förlorats för marknadsföring. QR-koder ses som ett enkelt sätt att få saker gjorda, inte som en potentiell attackvektor. Användarnamn / lösenordspar användes åtminstone FÖRST som en autentiseringsmekanism, inte ett marknadsföringsverktyg.
• @jpkrohling: När det gäller lösenordshanterare skulle jag gissa att de flesta användare av sådan programvara INTE lagrar sitt huvudlösenord. på sin mobila enhet, just för att de är medvetna om hur farligt det är. Jag har en fysisk kopia av mitt huvudlösenord på en säker plats, men inga elektroniska kopior. De attacker som skulle ge åtkomst till mitt huvudlösenord skiljer sig från dem som skulle äventyra ett webbplatslösenord och är mycket mindre troliga. (Främst för att attackera min lösenordsdatabas skulle innebära att jag attackerar mig personligen snarare än en stor komprometterad webbplats.)
• @jpkrohling Varken LastPass eller KeePass lagrar ett huvudlösenord var som helst. Den ’ används för att låsa upp din lösenordsdatabas, men den är inte ’ lagrad. Detta skiljer sig i grunden från att ha en enda tangent som i sig själv används överallt.

SQRL verkligen är inte utan brister, men det är verkligen överlägset de flesta primära autentiseringslösningar som ofta används på webben idag när det gäller säkerhet och (och detta är viktigt) användbarhet. Låt mig förklara.

Missuppfattningar

Låt mig först reda ut några av de missuppfattningar som finns i några av de andra svaren på den här frågan. Många av dessa svar är föråldrade och skrevs innan ändringar i SQRL-dokumentationen som tar upp de problem som presenteras i dem, medan andra tycks lägga onödig tonvikt på brister i SQRL som också finns i många andra allmänt använda befintliga autentiseringslösningar, samtidigt som de ignorerar fördelarna. Så låt oss rensa upp några missuppfattningar här, ska vi?

Myt: SQRL kräver skanning av QR-koder för att fungera

Detta är helt enkelt inte sant. QR-koder är en bekvämlighet vilket gör SQRL enklare att använda på datorer som användaren inte har ställt in SQRL-klientprogramvara på. SQRL: s webbplats anger följande:

Three Ways to Go…smarttelefon valfritt:

Även om den ursprungliga inspirationen för utvecklingen av detta system var en smartphone som skannade en QR-kod på webbplatsens inloggningssida, möjliggör ett litet tillägg till den modellen ytterligare två viktiga driftsätt: gör QR-kodbilden också till en klickbar länk till samma URL som är kodad i QR-koden. Detta ger tre sätt att logga in:

• Skanna koden med en smartphone: Använda modellen som beskrivs ovan, skannar en användares smartphone QR-koden som visas på en webbplats inloggningssida och användaren är inloggad på den webbplatsen.
• TAP KODEN på en smartphone: För att logga in på en webbplats PÅ smarttelefonen, när den visuella SQRL-koden också är en URL-länk (med hjälp av sqrl: // som schemat) SQRL-appen som är installerad i smarttelefonen tar emot den länken och loggar användaren säkert in på webbplatsen på telefonen.
• Klicka på koden på en stationär eller bärbar datorskärm : För att använda SQRL-systemet på alla stationära eller bärbara datorer skulle en SQRL-applikation på skrivbordet installeras och registrera sig för att ta emot sqrl: // länkar. (Detta liknar hur ett e-postprogram registrerar sig för att ta emot mailto: länkar.) Detta gör att samma lösning kan användas av användare på skrivbordet som de använder på sina smartphones. När någon webbplats erbjuder en SQRL-kod klickar användaren bara på koden med sin muspekare och den lokalt installerade SQRL-appen kommer att dyka upp, be om sitt SQRL-lösenord, bekräfta domänen och logga sedan in dem.

Myt: SQRL-huvudnyckeln lagras helt okrypterad och oskyddad på din telefon

Jag är inte säker på varför vissa gjorde det här antagande, eftersom det verkar uppenbart för mig att detta inte skulle vara fallet. SQRL-huvudnyckeln är skyddad på samma sätt som du skyddar en lösenordsdatabas: med ett starkt huvudlösenord. Att stjäla en användares telefon ger dig inte automatiskt åtkomst till deras online-identitet om du inte också har deras huvudlösenord. Mer information om nyckelhantering förklaras på sidan på SQRL Client- Side Key Management på SQRL: s webbplats.

Myt: Om din huvudnyckel är stulen kan du inte ändra dina inloggningsuppgifter

Detta är också falskt. SQRL tillhandahåller ett inbyggt sätt som gör det möjligt för den äkta kontoinnehavaren att uppdatera sina inloggningsuppgifter i händelse av en komprometterad nyckel. Den här funktionen kallas Identity Lock:

“Identitetslås” förhindrar identitetsändring & tillåter återställning: Detta är också tillräckligt betydelsefull för att förtjäna sin egen detaljerade beskrivningssida: “ Identitetslåsprotokollet ” (sidan 4 i länkblocket längst ner på denna sida.) En gång en användarens identitet har fastställts med en webbserver, SQRL c lient kan inte att ändra den identiteten. Detta innebär att om det värsta hände och ett mycket svagt och lätt gissat lösenord användes, eller om en användares telefon eller skrivbord hackades för att få sin identitets huvudnyckel och lösenord, ingen skadlig tredje part kan ändra användarens online-identitet för att låsa dem från sina egna onlinekonton. Och dessutom, genom att sedan ladda in en vanligtvis offline ”Identity Unlock Key”, kan den sanna ägaren av deras identitet gå i pension och ersätta sin förlorade eller stulna online-identitet för att i princip ta tillbaka den från alla angripare, vilket gör deras tidigare identitet värdelös.

Plausibel: SQRL är mer sårbar för nätfiske än befintliga autentiseringslösningar

Okej, så detta är faktiskt delvis sant. När du använder SQRL genom att skanna en QR-kod finns det verkligen mycket lite skydd mot nätfiske. Såvida inte användaren är noga med att se till att webbplatsen som visas i webbläsarens URL-fält är densamma som den som visas i SQRL Client-appen, kan de godkänna en inloggningssession för angriparen. Detta är fortfarande bättre än lösenord, där de skulle ge phishern permanent tillgång till sitt konto (och alla andra konton de har någon annanstans som delar samma lösenord) tills de byter lösenord, men inte lika bra som andra lösningar som integreras med användarens webbläsare som U2F-nycklar , WebAuthn, klientcertifikat och (under vissa förhållanden) lösenordshanterare.

Men när du använder en SQRL-klient på samma enhet som du loggar in med har SQRL viss skydd mot nätfiske på plats. Dessa skydd förklaras på SQRL: s webbplats under avsnittet om Hur SQRL kan motverka nätfiskeattacker .Det finns också möjligheten att integrera SQRL med webbläsare (eventuellt via plugins) för att ge mycket starkare skydd mot nätfiskeattacker; i nivå med lösningar som WebAuthn och klientcertifikat.

Totalt sett rankade jag SQRL på ungefär samma nivå som lösenordshanterare för phishing-skydd. Det har potential att ge starkt skydd mot nätfiske när det är installerat på samma enhet som användaren loggar in på, men ger minimalt skydd när det installeras på en annan enhet.

Jämförelse med alternativ

Nu ska vi jämföra SQRL med befintliga allmänt använda autentiseringslösningar.

Lösenord

SQRL är mycket överlägsen lösenord på många sätt. Det är inte bara bekvämare att använda en gång inställd upp, eftersom användarna inte behöver oroa sig för att komma ihåg eller skriva om flera olika lösenord för varje webbplats, men det skyddar också mot återanvändning av lösenord, svaga lösenord, nyckelloggning och till viss del nätfiske.

Nackdelar SQRL har jämfört med lösenord är att det är svårare att implementera för webbplatsoperatörer, inte lika vanligt förekommande, kräver mer tid att ställa in initialt, kräver en del ansträngningar för att överföra till en ny enhet och ger en enda felpunkt för alla användarens konton om huvudnyckeln är stulen (även om den här sista poängen t är också fallet för lösenord om en användare använder samma lösenord på varje webbplats).

Lösenordshanterare

På många sätt liknar SQRL mycket lösenordshanterare. De ger båda ett enda, centraliserat förtroendeankare som fungerar som ett slags autentiseringsproxy mellan användare och enskilda tjänster. Det finns dock ett par sätt att SQRL är överlägsen lösenordshanterare.

Den största fördelen jag tror att SQRL har över lösenordshanterare är att det är enklare och säkrare att använda på opålitliga eller endast delvis betrodda datorer. Anta till exempel att en användare vill logga in på en webbplats med hjälp av en dator på ett offentligt bibliotek. Med en lösenordshanterare måste han antingen komma åt lösenordet för den webbplatsen på sin telefon och skriva in det igen manuellt eller ladda ner sitt lösenordshanteraren och lösenordsdatabasen till biblioteksdatorn, låsa upp databasen med hjälp av sitt huvudlösenord och logga sedan in. Det första scenariot är obekvämt för användaren och exponerar användarens lösenord för den ena webbplatsen för den otillförlitliga datorn eventuell skadlig kod på den opålitliga datorn, inklusive keyloggers). Det andra scenariot är ännu värre, eftersom det är både obekvämt och exponerar användarens hela, dekrypterade lösenordsdatabas och huvudlösenord för den otillförlitliga datorn. Med SQRL skulle användaren bara behöva skanna en QR-kod på den otillförlitliga datorns skärm, vilket är mycket bekvämare för användaren, och bara exponera en enda inloggningssession (utan återanvändbara referenser som ett lösenord) till den otillförlitliga datorn .

En annan fördel som SQRL har jämfört med lösenordshanterare är att det är lättare att återhämta sig från det värsta fallet: användarens lösenordsdatabas / huvudnyckel stjäls. Med en lösenordshanterare skulle du inte behöver bara ändra ditt lösenord på varje webbplats, du måste också oroa dig för att angriparen ändrar dina lösenord (eventuellt låser dig från ditt konto). Angriparen har också fördelen att ha en lista över alla webbplatser du har en gör det enklare att utnyttja stölden av en lösenordsdatabas. Med SQRL är det fortfarande en fruktansvärd situation att ha din huvudnyckel stulen, men angriparen har ingen lista över webbplatser du har ett konto på (måste istället gissa ) och kan inte ändra ditt lösenord för att låsa ut dig av ditt konto. När du väl har laddat din identitetsupplåsningsnyckel är det också lite bekvämare att ändra dina inloggningsuppgifter på varje webbplats, eftersom SQRL-klienten har möjlighet att göra det åt dig automatiskt för varje webbplats du besöker vid inloggningen. (Inget behov av att gå genom alla ”ändra lösenord” -formulär.)

Slutligen tror jag att SQRL har en liten men viktig fördel jämfört med lösenordshanterare när det gäller sitt mål att helt ersätta lösenord, och det är att webbplatser har möjlighet att verkställa användning av SQRL jämfört med traditionella lösenord. Så länge användare fortfarande har möjlighet till dålig säkerhet, att återanvända samma lösenord på varje webbplats, är det något som fortfarande kommer att hända. Om SQRL börjar få ett brett antagande kan webbplatser faktiskt börja avveckla användningen av lösenord. Det kan inte göras med lösenordshanterare, eftersom de förlitar sig på användningen av lösenord för att fungera.

När det gäller nackdelar kan jag faktiskt inte tänka på en situation där SQRL skulle nödvändigtvis vara värre än lösenordshanterare när det gäller säkerhet. Den största nackdelen med SQRL är att den kräver stöd från webbplatsoperatörer, medan lösenordshanterare inte behöver något särskilt stöd från befintliga tjänster. Det betyder att du kan börja använda lösenordshanterare just nu, men SQRL måste vänta tills webbplatser implementerar det innan det kan användas. Detta är ett betydande hinder för adoption.

Klientcertifikat

Den primära fördelen som SQRL har framför klientcertifikat är bekvämligheten. Klientcertifikat är för närvarande komplicerade att installera, svåra att överföra mellan datorer och har sekretessproblem när samma certifikat används på olika webbplatser. Även om vi teoretiskt sett kunde bygga ett system med klientcertifikat som skulle lösa dessa problem, skulle det också finnas problemet med dålig integration med webbplatsgränssnitt och webbservrar, vilket är svårare att lösa. Jag kommer inte att gå för mycket i detalj här, eftersom det redan finns en utmärkt artikel om användbarhetsfrågorna för klientcertifikat på browserauth.net.

När det gäller säkerhet har klientcertifikat nackdelen att det krävs en CA-medverkan. Detta är (potentiellt) dyrt och kräver förtroende för tredje parts CA. Dessutom, om du väljer att ignorera certifikatutfärdare och istället själv signera dina certifikat, har du frågan om återkallande av certifikat att hantera. Klientcertifikat har också samma säkerhets- och bekvämlighetsproblem som lösenordshanterare när användare vill logga in på en otillförlitlig dator. de måste överföra certifikatet till den otillförlitliga datorn, vilket både är obekvämt och potentiellt utsätter sin huvudidentitet för skadlig programvara på den datorn.

Kort sagt, tills någon kommer fram till en bättre, användarvänlig lösning med klientcertifikat som löser (åtminstone de flesta av) dessa problem, jag tror inte att kundcertifikat är en seriös konkurrent till SQRL (eller för den delen, lösenord).

2-faktorautentisering

Tänkte bara att jag skulle nämna detta: SQRL och 2-faktor autentisering är inte uteslutande. SQRL är en ersättning för den första faktorn i 2FA: lösenord. Andra ytterligare åtgärder som OTP-koder eller FIDO U2F-nycklar kan fortfarande användas med SQRL.

WebAuthn

Nu här ” där saker blir intressanta. WebAuthn är en ny (väl, nyare än SQRL) W3C-standard utformad för att tillhandahålla en standard API-webbplatser kan använda för att autentisera användare med offentliga nycklar på webben. Precis som SQRL, den stöder med användarens telefon för att autentisera en inloggningssession på en extern enhet , förutom några andra autentiseringsmetoder (t.ex. andra faktor säkerhetsnycklar) .

Det är här SQRL äntligen möter sin match, åtminstone ur ett säkerhetsperspektiv. WebAuthn tillhandahåller inte bara samma skydd mot återanvändning av lösenord, svaga lösenord och nyckelloggning som SQRL gör, men det ger också ännu starkare skydd mot nätfiske genom att integrera med användarens webbläsare jämnt när du godkänner en inloggning session för en dator har användaren inte tidigare konfigurerat autentiseringsprogramvarans klientprogramvara. Detta är möjligt eftersom WebAuthn i den situationen kommunicerar med användarens webbläsare direkt med tvåvägskommunikationsprotokoll som Blutooth eller NFC istället för att kommunicera med webbplatsen som användaren använder via en enkelriktad QR-kod.

Ur ett användbarhetsperspektiv är saker lite mer komplicerade. På ytan åtminstone vinner WebAuthn igen. Eftersom det är en W3C-standard som redan har implementeringar i flera webbläsare , i teorin kan användare omedelbart börja använda WebAuthn utan att behöva installera någon tredjepartsprogramvara. I praktiken fokuserar dock de flesta befintliga WebAuthn-implementationer på dess användning som en form av andra faktor-autentisering, eller som ett sätt att verifiera en användare som tidigare loggade in på samma enhet via en annan inloggningsmetod (vanligtvis ett lösenord). Som en primär autentiseringsfaktor saknar WebAuthn fortfarande ganska genomförbara implementeringar.

Andra mindre överväganden inkluderar det faktum att SQRL har en buil t-in-metod för att rotera nycklarna till konton i händelse av en stulen huvudnyckel, medan WebAuthn förlitar sig på webbplatser för att implementera sitt eget system för återkallande av nycklar, och det faktum att WebAuthn kräver viss valfri hårdvara (som Bluetooth eller NFC) för att autentisera till en fjärrmaskin, medan SQRL kan fungera på alla maskiner med en fungerande skärm.

Sammantaget tror jag att det är mycket troligt att WebAuthn så småningom kommer att göra SQRL föråldrad. SQRL kan ha lite andningsrum för nu, men WebAuthn har mycket starkare stöd från webbläsarleverantörer, webbplatsoperatörer och andra tredjepartsorganisationer (som W3C). När WebAuthn får ett par implementeringar som möjliggör dess användning som en primär autentiseringsfaktor, förväntar jag mig att det kommer att börja ta över webben mycket snabbt.

Förbehåll

SQRL är fortfarande under aktiv utveckling, så materialet som presenteras i detta svar kan komma att ändras. När utvecklingen fortsätter förväntar jag mig att några av sårbarheterna och osäkerheterna i detta svar kommer att tas upp. Det mesta av diskussionen äger rum för närvarande i SQRL-nyhetsgruppen över på grc.com.

SQRL är en bekväm lösning på problemet med användarnamnet / lösenordsparadox. (dvs. bekvämlighets- / säkerhetsavvägningen) utan att använda en tredjeparts . Det ger ett enkelt alternativ till den mest populära autentiseringsmodellen (användarnamn & Lösenord), med praktiskt taget ingen kompromiss för säkerheten. Det är praktiskt taget lika säkert för någon av de vanliga autentiseringsmodellerna som används idag, så länge du fortfarande är säkerhetsmedveten . Om du använder SQRL betyder det inte att du inte kan följa bästa säkerhetsmetoder som och kombinera detta med flerfaktorautentisering för viktiga konton.

Det är viktigt att inte missa poängen med SQRL. SQRL i sig behöver inte ge bättre eller sämre säkerhet. Om själva datorn / telefonen blir äventyrad eller användaren luras som phishing, då är detta en sidokanalattack istället för ett direkt fel hos SQRL själv. Varje konventionell autentiseringsmetod har detta problem med sidokanalattacker Den okrossbara engångsplattan är också sårbar för sidokanalattacker som kompromissen med själva dynan eller dålig säkerhet eller implementeringar.

Om du lyssnade på idéens ursprungliga förslag på Steve Gibson ”s podcast , följt av Q & A ”s, har många av de bekymmer som tas upp på denna stacktråd besvarats. Steve sa också själv att denna mycket ”enkla” och ”geniala” (hans ord) idé skulle behöva ”kontrolleras” och ”hamras på” av säkerhetsexperter, eftersom bara tiden kommer att visa om detta är en säker lösning.

Sammanfattningsvis faller de flesta argumenten mot SQRL utanför själva SQRL-domänen och är istället problem med att människor utövar dålig säkerhet. SQRL introducerar inte ny klassificering av problem som våra traditionella autentiseringsmetoder inte har.

SQRL är utmärkt om det används på rätt sätt av personer som är säkerhetsmedvetna. Du måste förstå att det alltid finns en avvägning mellan bekvämlighet och säkerhet , och den här lösningen är förmodligen bästa balans av de två jag har sett.

Kommentarer

• Tack Ansichart. Men kan ’ t existerande autentiska lösningar helt enkelt behålla lika eller överlägsna säkerhetsfunktioner som SQRL och sedan använda automatisering för att öka användarnas bekvämlighet? Vilken grundläggande egenskap hos SQRL ’ s användarvänlighet är inte på grund av automatisering? Jag frågar för om en användare har två svarta rutor som gör samma sak; en märkt ” Mogen ” och den andra märkt ” SQRL ” och de kan båda konstrueras / automatiseras med samma gränssnitt / knappar på utsidan av rutan – vilket mervärde ger SQRL?
• Det löser problemet med lösenordsparadoxen utan att behöva använda en tredje part.
• Jag förstår. Så om någon inte ’ t vill ha tredje parts risk för enkel inloggning och inte ’ t genererar / lagrar sina lösenord med en lösenordshanterare kan SQRL öka. Men om SQRL är en mobil svart ruta som ber om ett lösenord för att låsa upp huvudnyckeln som används för att regenerera / lagra SQRLID och sedan utföra backkanal-länkning av klient ’ s cookie / QR session_id med server ’ har spelat in SQRLID för inloggning – hur är detta en annan mobil svart ruta från en mobil lösenordshanterare med automatisk inloggning via samma bakkanal; eller ett tvåpartscertifikatprogram för mobilklienter med automatisk generation & inloggning via samma bakkanal?
• Jag har gjort en del större redigering av mitt ursprungliga inlägg efter några andra överväganden och närmare läsning av vad andra har sagt, eftersom jag kanske har överdrivit det. Jag antar att det att ha mobiltelefonen som den centrala nyckeln förskjuter problemet och skulle göra det viktigare att ha starkare säkerhet på din telefon. Steve Gibson tar också upp detta i Q & En podcast.

SQRL ger inga banbrytande förbättringar. QR-koder är ett optiskt streckkodsformat som är användbart för kort innehållsdistribution – inget mer.

Alla ”auto-inloggningssituationer” som SQRL försöker lösa kan helt enkelt använda ett klientcertifikat lagrat på mobilen istället.

Hypotetiskt kan en QR-streckkod på en HTTPS-sida returnera en serversignerad eller krypterad version av klientcertifikatet (eller en liknande referens) som servern tidigare känt, men varför? För legitimationsutgång? Webbplatsen kan helt enkelt avvisa en utgången referens direkt.

Så det största säkerhetsproblem jag har med detta protokollet är: Återuppfinna fyrkantiga hjulet .

Update

När jag läser nya svar och kommentarer vill jag påpeka hur enkelt det är att göra något som liknar SQRL genom enkel automatisering av mogen befintlig teknik :

1. Webbplatsen frågar alla CAPTCHAs eller liknande ”Jag” är mänsklig ”verifiering. När användaren har följt (POSTat) returnerar webbplatsen ett HTTP 403.7 - Client Certificate Required eller ett vanilj 403-fel.
2. Anpassade 403-sidor är enkla att installera och kan vara ganska vackra och användarvänliga. Kunde till och med starta upp den funktion som krävs nedan på ett sätt som liknar ”Adobe Reader krävs” på många webbplatser.
3. Anpassad 403-sida innehåller en viss markering som ett anpassat webbläsarinsticksprogram reagerar på. Låt oss kalla detta anpassade plugin ”S403L-kompatibelt” i andan av ”SQRL-överensstämmelse”.
4. S403L-plugin genererar ett standardklientcertifikat som är säkrat i den vanliga krypterade webbläsarens certcache (eller en tredje part-cache om din webbläsares kryptering av nyckelbutiken suger). Plugin skapar en standard CSR för klientcertifikatet och skickar CSR till den URL som anges i 403-markeringen. (t.ex. <s403l ref="https://www.example.com/S403L" />)
5. Den S403L-kompatibla servern använder användarens session_id (hämtad från cookies eller frågesträng) för att skapa kontinuitet med steg 1 och returnerar sedan CSR som signerad av servern. Allmän serverautentisering accepterar alla klientcertifikat som signerats av servern (och därmed uppfyllde de registreringskriterier som krävdes i steg 1).
6. S403L-plugin lagrar det signerade klientcertifikatet i webbläsarens cache. sedan kan standardwebbläsaren utan instickshjälp ”automatiskt logga in” på servern på vanligt SSL / TLS-sätt tills certifikatet upphör.

Den ”mobila” och ”visuella” karaktären av SQRL är något av en felriktning eftersom det inte ger fristående tvåfaktorautentisering och du behöver nu två datorer för att navigera på internet istället för en. Om du inte riktar USB-webbkameran på skrivbordet mot sin egen bildskärm.

Avvägningarna mellan lösenord och certifikat är väl definierade i säkerhetsgemenskapen: Lösenord passar in i en mänsklig hjärna; certifikat passar inte in en mänsklig hjärna ( vanligtvis ) men kan ha galen entropi och bra PKI-hanteringsfunktioner (utgång , återkallande, policyförlängningar, etc). SQRL passar rent in i varken lägret; och om det driver mot det mindre mänskliga mer-datorlägret som det verkar vara – har det många års utveckling och säkerhetsanalys att upprepa befintliga X.509-funktioner.

Kommentarer

• > kan helt enkelt använda ett klientcertifikat lagrat på mobilen istället.— förutom att den här tekniken finns i flera år både på mobil och stationär dator, och att den ’ inte är så utbredd som man önskar. Och i motsats till klientcertifikatet kräver SQRL inte ’ t att du bevisar din verkliga identitet för att skapa en ” SQRL-identitet ”. Om du så önskar kan du skapa så många identiteter som du vill. Detta innebär att fördelen med att jämföra med klientcertifikat är att du har anonymitet från auth-protokollet ’ s sida.
• @jpkrohling Det är en vanlig missuppfattning att klientcertifikat kräver identitetsupplysning för att använda. Det är ett krav från kommersiella underteckningsmyndigheter att använda sina globalt utbytbara förtroendekedjor. I praktiken kan ett kundcertifikat helt enkelt vara en anonym CSR skapad av klienten och undertecknad av en specifik server efter att ha uppfyllt önskade kriterier (CAPTCHAs, tidigare konto, etc). Certifikat kan också ha en inbyggd utgång. Type 40-L QR-streckkoder kan skicka / lagra 1KB X.509-klientcertifikatet om så önskas.
• Okej, sant, dåligt. Ur detta perspektiv kan klienten (till exempel mobilappen) generera ett klientcertifikat för varje webbplats som användaren registrerar. Det låter dyrare än att ha lite information, men kan vara en intressant lösning. I vilket fall som helst håller jag inte ’ inte med dina påståenden om att SQRL är värre än värdelös.
• Jag var kanske hård på den formuleringen och kommer att ta bort den. Men jag ser inte ’ SQRL som något annat än mer sexigt sätt att distribuera förhandlade kunduppgifter; och en som inte har ’ t löste några av de subtila problemen som behandlas av mogna autentiseringsscheman. En lösenordshanterare är tråkig (jag bryr mig inte ’ eftersom jag ’ är paranoiac) men jag vet att bara jag och en webbplats delar varje enskilt lösenord i min krypterade nyckelbutik. Jag behöver inte ’ oroa mig för snygga nya hash / auth-scheman, bara kvaliteten på PRNG / TRNG som min lösenordshanterare använder för att generera lösenord.
• @LateralFractal vem bryr sig om det ’ är nytt eller inte? SQRL tillåter användarvänlig autentisering där den första parten inte avslöjar sin hemlighet med andra parten eller någon tredje part som kan ha äventyrat den andra partens ’ s säkerhet. Det ’ är ett försök att lösa ett verkligt världsproblem som hittills ingen annan har kunnat lösa.

Jag vill ta upp den första frågan: ”ett av de problem som jag kan tänka mig är om QR-läsaren äventyras, att visa www.google.com istället för www.nsa-super-secret-place.gov/123 ”:

Huvudnyckeln används som utsäde i HMAC tillsammans med webbplatsadressen (FQDN). Så även om QR-koden kan koda helt annorlunda URL kommer protokollet INTE att avslöja den autentiseringskod som normalt skulle skickas till www.google.com (i exemplet).

För det andra glömmer många av bidragsgivarna huvudmålen när de utarbetar denna idé:

1. anonymitet genom att inte använda tredje part
2. användarvänlighet
3. inget behov av att skriva hemlig referens på opålitliga datorer

Jag tror att protokollen behandlar dessa i sin helhet!

Det finns dock kompromisser som faktiskt kommer från den första obectjive. Om ingen tredje part är inblandad i autentiseringen, hur kan man återkalla deras autentiseringsinformation? Dessutom är säkerheten för huvudnyckeln ett uppenbart problem. Jag tänker mig att detta ska vara väl skyddat av framtida mobila enheter i ett HSM-liknande chip. Tills dess är nyckeln bara en filnål mobil enhet, skyddad av ett lösenord, även om PBDKF2 säkerställer att det är mycket långsamt att faktiskt tvinga det.

Kommentarer

• Återigen, vad ’ är nytt med denna idé? Det verkar för mig vara en primitiv variant av det nu avskaffade Windows CardSpace.
• Ja, du har rätt i CardSpace. Sedan finns det U-Prove som också ägs av Microsoft. Frågan är hur skulle du använda CardSpace eller U-Prove på en dator som du inte litar på (internetcafé eller kompisdatorn). Det var vad Steve tillade.
• Ah, ok, att ’ är vad jag saknade. Jag håller fortfarande med @TerryChia att detta är en icke-startare utan en återkallningsmekanism för användarnycklarna.
• @Xander Det finns en återkallningsmekanism för användarnycklarna. grc.com/sqrl/idlock.htm