Tag som sædvanlig noget, der er relateret til Steve Gibson, med en lastbil salt. Obligatorisk attrition.org link .

Lad os se på Gibsons beskrivelse af sin protokol.

• QR-koden præsenteret nær login prompt indeholder URL-adressen til godkendelsestjenesten for webstedet. URLen indeholder et sikkert genereret langt tilfældigt tal, så hver præsentation af login-siden viser en anden QR-kode. (I kryptokredse kaldes dette lange tilfældige tal som en “nonce.”)

• Smarttelefonens SQRL-godkendelses-app hash kryptografisk domænenavnet på det sted, der er indtastet af brugeren “hovednøgle til at producere et stedsspecifikt offentligt nøglepar.

• Appen krypterer kryptografisk hele URLen indeholdt i QR-koden ved hjælp af den stedsspecifikke private nøgle. Da URLen indeholder et sikkert langt tilfældigt tal (nonce), er signaturen unik for dette websted og QR-kode.

• Appen udsteder en sikker HTTPS POST-forespørgsel til QR kode “s URL, som er godkendelsestjenesten for webstedet. POST leverer den stedsspecifikke offentlige nøgle og den matchende kryptografiske signatur af QR-kodens URL.

• Det godkendende websted modtager og kvitterer POST-forespørgslen ved at returnere en standard HTTP “200 OK” uden andet indhold. SQRL-appen anerkender den vellykkede indsendelse af den brugersignerede QR-kode.

• Det godkendende websted har den URL, der indeholder den nonce, der kom tilbage fra login-siden via brugerens Den har også en kryptografisk signatur af denne URL og brugerens stedsspecifikke offentlige nøgle. Det bruger den offentlige nøgle til at kontrollere, at signaturen er gyldig for URLen. Dette bekræfter, at den bruger, der producerede signaturen, brugte den private nøgle svarende til den offentlige nøgle. Efter bekræftelse af signaturen genkender det godkendende websted den nu godkendte bruger ved hjælp af deres webstedsspecifikke offentlige nøgle.

den største ting, der springer ud på mig, er brugen af en ” masternøgle ” af brugeren. Hvis jeg læser protokollen korrekt, styrer den enkelt masternøgle brugerens hele online identitet …

Formentlig lagres denne masternøgle i brugerens telefon i en applikationsdatabase. Hvilket åbner en enorm gapende angrebsvektor i form af malware designet specielt til at stjæle masternøglen.

Så lad os sammenligne forskellen mellem hvad der sker, når en adgangskode bliver kompromitteret vs hvad der sker, når masternøglen Hvis du antager, at du følger god adgangskodepraksis for lange, unikke og meget tilfældige adgangskoder, der er gemt i en adgangskodeadministrator, er alt hvad du skal gøre, at ændre en enkelt adgangskode, hvis den bliver kompromitteret. Hvad sker der, hvis din hovednøgle bliver kompromitteret? bliver nødt til på en eller anden måde at hente alle de websteder, du er godkendt med, for at genkende, at din hovednøgle er kompromitteret. Det eneste problem er, da du ikke har andre måder at godkende på webstedet, såsom brugernavne eller e-mail-adresser, hvordan ved siden, at det faktisk er dig, der forsøger at tilbagekalde masternøglen?

Som alt, hvad der kommer ud af Gibson, er denne SRQL-ordning meget mangelfuld og giver ingen fordele i forhold til konventionelle metoder.

Komme nts

• ” Hvis du ‘ følger god adgangskodepraksis ” er en kæmpe advarsel, og de fleste Netizens gør det ikke ‘.En del af SQRL ‘ s løfte er at reducere brugere ‘ har brug for at holde sig på toppen af bedste praksis. Yderligere vil SQRL-spec opfordre til, at masternøglen opbevares krypteret med en masteradgangskode og vil være umulig at brute force (tunet til at tage ~ 60s for et forsøg). At få adgangskoden vil ofte være ikke-trivielt, da SQRL fremmer autentificering uden for båndet (dvs. at nøglelogging af en hacket maskine ikke vil hjælpe dig ‘). Så mens konsekvenserne af fuldt kompromis er høje, er sandsynligheden for kompromis noget lav.
• SQRL kan muligvis stadig have mangler, der skal løses, men det hævder at løse et antal problemer, der findes i eksisterende tilgange til godkendelse, og enhver kritik af SQRL, der hævder det ” giver ingen fordele ” bør omfatte tilbagekaldelser af disse påstande i stedet for at forvente, at påstanden blindt accepteres.
• > Ligesom alt andet, der kommer ud af Gibson , denne SRQL-ordning er meget mangelfuld og giver ingen fordele i forhold til konventionelle metoder. — Dette synes ikke ‘ at hjælpe med at besvare spørgsmålet, og jeg føler faktisk, at du har problemer med teknologien på grund af hvem der kom op med det. Nogle af de punkter, du nævnte som fejl, behandles faktisk af ” spec “. For eksempel nævner SQRL selv ikke ‘ t, hvordan masternøglen er gemt, men Steve Gibson ‘ s kommentarer om det er, at en mobil klient krypterede den for eksempel med en hovedadgangskode ved hjælp af en scrypt, der i gennemsnit tager 60ere at udføre.
• Gibson-eksplicit beskytter masternøglen.
• Hold nede på en sekund. Du sidestiller din SQRL-hovednøgle, der bliver stjålet, til en af dine LastPass-nøgler, der bliver stjålet. Ville ‘ ikke være en bedre analogi at sidestille den med hele din dekrypterede LastPass-adgangskodedatabase bliver stjålet?

Generelt ser protokollen ikke ud til at øge sikkerheden i forhold til eksisterende teknologi. Hvis du leder efter den bedste måde at beskytte din identitet online på, er dette uden spørgsmål ikke det . Men lad os gå over fordele og ulemper:

Fordele

Det er umuligt at ” dele ” en adgangskode i snæver forstand, at et ondsindet websted ikke kan bruge den godkendelse, der gives til et websted, til at logge ind på et andet websted.

Et voldsomt angreb mod godkendelsestokenet er ikke muligt.

Oplysninger er ikke gemt på din computer. Dette beskytter dig mod en lille delmængde af arbejdsstationsstyrede angreb. Specifikt er du beskyttet mod angreb, der stjæler din adgangskode fra din computer. Du er dog ikke beskyttet mod nogen form for sessionskapring eller browserovertagelsesangreb, og du er nu også modtagelig for telefonrelaterede angreb. Mere om det senere.

Ulemper

Denne teknik er farligt modtagelig for MITM-angreb og social engineering. Sandsynligvis mere end nogen anden godkendelsesplan, der er i brug, inklusive adgangskoder. Autentificeringstrinnet og logininitieringstrinnet afbrydes i sagens natur i den forstand, at telefonen godkendes korrekt mod enhver præsenteret QR-kode, uanset hvordan eller hvor den bliver præsenteret for brugeren.

Så f.eks. et phishing-websted kan vise en autentisk login-QR-kode, der logger på angriberen i stedet for brugeren. Gibson er overbevist om, at brugerne vil se navnet på banken eller butikken eller webstedet i telefonappen under godkendelse og vil derfor udvise tilstrækkelig årvågenhed til at modvirke angreb. Historien antyder dette usandsynligt, og den mere rimelige forventning er, at det at se det rigtige navn i appen falsk vil berolige brugeren til at tro, at webstedet er legitimt, fordi det var i stand til at udløse den velkendte loginanmodning på telefonen. Den forsigtighed, der allerede er slået ind i brugernes hoveder med hensyn til adgangskodesikkerhed, oversættes ikke nødvendigvis til nye godkendelsesteknikker som denne, hvilket gør denne app sandsynligvis iboende mindre modstandsdygtig over for social engineering.

Denne teknik kombinerer både autentificering og identitet i et fysisk objekt, der ofte mistes eller stjæles. I denne forstand er det ” er mere som et pas snarere end et kodeord. Enhver, der har din telefon i besiddelse, er pludselig udelukkende i besiddelse af din identitet: ikke kun kan angriberen efterligne dig, men uden en anden kopi på en anden telefon ( usandsynligt), nu har du mistet evnen til at identificere dig selv.Godkendelsesnøgler kan ikke tilbagekaldes, så uden gendannelse uden for bånd fra hvert eneste sted kan du ikke gendanne din identitet. Og selvom der findes gendannelse uden for bandet, når det konfronteres med to brugere, en med besiddelse af identiteten og en uden, kan det være svært at se, hvorfor webstedsoperatøren skal stole på dig.

Denne teknik kombinerer alle dine godkendelsestokens til en enkelt nøgle , medmindre du manuelt opretter andre. Dette gør din ene nøgle til et ekstra saftigt mål for angribere. Desuden er nøglen gemt på din telefon, hvilke enheder der typisk har haft latterligt porøs intern sikkerhed. At kombinere usædvanligt saftige mål med substandard sikkerhed gør dig ikke sikker.

Alternativer

Det mest problematiske aspekt af denne ordning er, hvor dårligt den sammenlignes med de tilgængelige alternativer.

Den mest sikre universelt accepterede mulighed i dag er lastpass, keepass og andre sådanne browserintegrerede adgangskodesystemer. Især fjerner kryptering på klientsiden behovet for at stole på enhver tredjepart. Og vigtigere er, browserintegration gør phishing praktisk talt umulig . LastPass eller KeePass udfylder kun adgangskoden, hvis den serveres fra det rigtige domæne, hvilket betyder, at hvis brugeren præsenteres for et ondsindet websted, har den ikke adgang til sin adgangskode.

Desuden tilføjede LastPass for nylig en funktion som napper brugere til at ændre adgangskoder, der ikke er globalt unikke. Dette hjælper med at forhindre genbrug af adgangskoder, hvilket betyder, at den primære fordel ved Gibsons teknik let kan opnås ved hjælp af dette værktøj i dag på eksisterende websteder uden den ekstra usikkerhed, som hans skema indebærer.

Eksisterende ordninger med anden faktor-godkendelse, der bruger telefoner eller lignende enheder, hjælper med at beskytte brugerlogins i dag gør det allerede på en sådan måde, at det ikke gør dig straks sårbar over for identitetstyveri, hvis din enhed bliver stjålet. sikkerhed ved tofaktorautentisering ligger i, at hverken enheden eller adgangskoden kan bruges, hvis de stjæles uden den anden. Gibsons teknik er stort set modstandsdygtig over for at blive inkluderet i et tofaktorsystem, hvilket gør dette beskyttelsesniveau tion utilgængelig.

TL; DR:

Gibsons godkendelsesteknik skaber ikke tilstrækkelig fordel til at overvinde de ekstra sikkerhedsomkostninger, som den også pålægger. Disse omkostninger er en grundlæggende del af selve ordningen og kan sandsynligvis ikke udarbejdes uden at skrotte hele designet.

Du kan argumentere for, at det er bedre end ingenting, men du kan ikke argumentere for, at det er bedre end noget andet, vi allerede har.

Gibsons opdateringer

Gibson annoncerede for nylig en vis ekstra beskyttelse mod phishing, fordi dette har været en stor kritik. Deres beskyttelse er denne: Hvis du IKKE bruger QR-koder, mobiltelefon osv. Og i stedet har en godkendelsesagent på dit system (f.eks. I browseren), kan serveren kontrollere for at sikre, at godkendelsen svaret kommer fra samme IP som godkendelsesanmodningen. Dette er godt og godt, men hele formålet med denne protokol er at flytte din identitet til din mobiltelefon. Hvis den eneste sikre måde at bruge protokollen på er ikke at bruge den kerne funktion, så måske skal vi tænke igen, hvad vi prøver at opnå.

Teoretisk set kunne du fortsætte med at bruge din mobiltelefon, hvis (og kun hvis) din mobiltelefon vidste at den brugte den samme IP som din computer. Hvilket selvfølgelig ikke kan vide, fordi den ikke kender din computers IP-adresse.

En bedre løsning

Som tidligere nævnt, hvis godkendelsesmål er i din browser, , løses hele phishing-problemet med det samme uden nogen indsats eller verifikation fra brugeren. Selv den mindst dygtige bruger kan ikke narres til at autentificere til det forkerte websted, fordi websteds godkendelsestoken er knyttet til domænenavnet, og browseren vandt ” t tillader godkendelse til det forkerte domæne. Dette er en teknik, der allerede er i brug i dag, er fuldstændig automatisk og kræver ikke webstedets samarbejde eller nogen intelligens fra brugerens side.

Denne metode kan styrkes ved at kræve en anden godkendelsesfaktor (såsom en tidsvarierende nøgle på en mobiltelefon), som igen allerede er tilgængelig og i brug i dag, som beskytter dig (især) mod skruer fra destinationswebstedet eller firmaet.

Hvad angår bekymringer om godkendelse af browsersiden, der er sårbar over for angreb på klient-arbejdsstationer: mens det er sandt, er det også sandt, at brugen af denne browser er sikker , uanset hvilken godkendelsesmekanisme du bruger.Malwareforfattere kan (og allerede gør) vente på, at du autentificerer dig selv ved hjælp af din supersikker teknik og derefter lydløst sende den nødvendige trafik til ” ejer ” din konto, alt sammen uden at du ser noget galt. Hverken SQRL eller noget andet godkendelsessystem kan beskytte brugeren af en kompromitteret browser, mere end dørlåse kan beskytte dig mod en husbrand. At købe brandsikre låse er ikke en løsning.

Hvor næste

Hvis du leder efter en absolut garanti for beskyttelse mod efterligning , se derefter på Fido U2F-token. Denne standard skinner, hvor SQRL ikke er tilstrækkelig, og giver dig garanteret immunitet over for MITM (f.eks. phishing) -angreb. Det gør det ved at autentificere ikke kun brugeren, men også kanalen, så du “er garanteret, at (a) din konto ikke kan godkendes uden tokenet, og også (b) dit token kun kan bruges til at godkende en forbindelse til den maskine, den er knyttet til. Se dette svar for at få flere oplysninger.

Kommentarer

• Om det første punkt : så vidt jeg forstår, blev dette overvejet, og en mulighed er at lade det websted, som du godkender, være ansvarlig for omdirigering. Så ved login omdirigeres du til den rigtige banks ‘ side, ikke angriberen. Omkring det andet punkt sker det samme i dag med brugere af værktøjer som LastPass. Medmindre du konfigurerer en beskyttelsesmekanisme (f.eks. PIN), stjæles også alle dine adgangskoder. Hvorfor kan ‘ t det samme være tilfældet for SQRL? Så vidt jeg forstår det fra specifikationen, kan brugeren sikkerhedskopiere sin identitet selv på papir (som en QR-kode).
• Og om det tredje punkt: det samme sker med de fleste brugere, der ikke ‘ Brug ikke en adgangskodeadministrator ved blot at bruge et enkelt brugernavn / adgangskode på flere websteder. Eller hos brugere af adgangskodeadministratorer, hvis ” identitet ” er spredt på flere websteder, men gemt på en enkelt placering (LastPass ‘ servere, 1Password-database osv.). Så det er ‘ ikke rigtig en SQRL-fejl. Alt i alt, jo mere jeg læser om SQRL, jo mere ser jeg fordelene ved at sammenligne med de nuværende alternativer. Sig, at du siger om Steve Gibson, men SQRL virker virkelig som et godt alternativ for mig. brugere vedrørende adgangskodesikkerhed oversætter ikke nødvendigvis til nye godkendelsesteknikker som denne. . . ” Dette er et glimrende punkt, og kampen er allerede gået tabt for markedsføring. QR-koder ses som en nem måde at få tingene gjort på, ikke som en potentiel angrebsvektor. I det mindste blev brugernavn / adgangskodepar FØRST anvendt som en godkendelsesmekanisme, ikke et marketingværktøj.
• @jpkrohling: Med hensyn til adgangskodeadministratorer vil jeg gætte, at de fleste brugere af sådan software IKKE gemmer deres hovedadgangskode. på deres mobile enhed, netop fordi de er opmærksomme på, hvor farligt det er. Jeg har en fysisk kopi af min hovedadgangskode et sikkert sted, men ingen elektroniske kopier. De angreb, der giver adgang til min hovedadgangskode, adskiller sig fra dem, der kompromitterer et webstedsadgangskode og er langt mindre sandsynlige. (Primært fordi angreb på min adgangskodedatabase ville involvere angreb på mig personligt i stedet for på et stort kompromitteret websted.)
• @jpkrohling Hverken LastPass eller KeePass gemmer en hovedadgangskode hvor som helst. Det ‘ bruges til at låse din adgangskodedatabase op, men den er ikke ‘ t gemt. Dette er fundamentalt forskelligt fra at have en enkelt nøgle, som i sig selv bruges overalt.

SQRL bestemt er ikke uden fejl, men det er bestemt bedre end de fleste primære autentificeringsløsninger, der i vid udstrækning anvendes på nettet i dag med hensyn til sikkerhed og (og det er vigtigt) brugbarhed. Tillad mig at forklare.

Misforståelser

Lad mig først rydde op i nogle få af de misforståelser, der findes i nogle af de andre svar på dette spørgsmål. Mange af disse svar er forældede og blev skrevet før ændringer i SQRL-dokumentationen der løser problemerne i dem, mens andre ser ud til at lægge unødig vægt på fejl i SQRL, som også er til stede i mange andre almindeligt anvendte eksisterende godkendelsesløsninger, mens de ignorerer fordelene. Så lad os rydde op et par misforståelser her, skal vi?

Myte: SQRL kræver scanning af QR-koder for at arbejde

Dette er simpelthen ikke sandt. QR-koder er en bekvemmelighed hvilket gør SQRL nemmere at bruge på computere, som brugeren ikke har konfigureret SQRL-klientsoftware til. SQRLs websted siger følgende:

Tre måder at gå …smartphone valgfri:

Selvom den originale inspiration til udviklingen af dette system var en smartphone, der scannede en QR-kode på et websides login-side, muliggør en lille tilføjelse til denne model to vigtige driftsformer: Simpelthen gør QR-kodebilledet også til et klikbart link til den samme URL, der er kodet i QR-koden. Dette giver tre måder at logge på:

• Scan koden med en smartphone: Brug af den model, der er beskrevet ovenfor, scanner en brugers smartphone QR-koden, der vises på en websides login-side, og brugeren er logget ind på det sted.
• TAP KODEN på en smartphone: For at logge ind på et websted PÅ smartphonen, når den visuelle SQRL-kode også er et URL-stil-link (ved hjælp af sqrl: // som skema), SQRL-appen, der er installeret i smartphonen, modtager dette link og logger brugeren sikkert ind på siden på telefonen.
• Klik på koden på en stationær eller bærbar skærm : For at bruge SQRL-systemet på ethvert stationært eller bærbart system, ville en desktop SQRL-applikation blive installeret og registrere sig selv for at modtage sqrl: // links. (Dette svarer til den måde, hvorpå et e-mail-program registrerer sig for at modtage mailto: links.) Dette gør det muligt for den samme løsning at blive brugt af brugere på deres skrivebord, som de bruger på deres smartphones. Når ethvert websted tilbyder en SQRL-kode, klikker brugeren bare på koden med sin musemarkør, og den lokalt installerede SQRL-app vil pop op, bede om deres SQRL-adgangskode, bekræfte domænet og logge dem derefter ind.

Myte: SQRL-masternøglen er gemt helt ukrypteret og ubeskyttet på din telefon

Jeg er ikke sikker på, hvorfor nogle mennesker lavede dette antagelse, da det synes indlysende for mig, at dette ikke ville være tilfældet. SQRL-masternøglen er beskyttet på omtrent samme måde, som du beskytter en adgangskodedatabase: med en stærk masteradgangskode. At stjæle en brugers telefon ville ikke automatisk give dig adgang til deres online identitet, medmindre du også havde deres hovedadgangskode. Flere detaljer om nøglehåndtering forklares på siden på SQRL Client- Side Key Management på SQRLs websted.

Myte: Hvis din masternøgle er stjålet, kan du ikke ændre dine loginoplysninger

Dette er også forkert. SQRL giver en indbygget måde, der gør det muligt for den ægte kontoindehaver at opdatere deres loginoplysninger i tilfælde af en kompromitteret nøgle. Denne funktion kaldes identitetslås:

“Identitetslås” forhindrer identitetsændring & tillader gendannelse: Dette er også signifikant nok til at fortjene sin egen detaljerede beskrivelsesside: “ Identitetslåseprotokollen ” (side 4 i linkblokken nederst på denne side.) En gang en brugerens identitet er etableret med en webserver, SQRL c lient er ude af stand til til at ændre denne identitet. Dette betyder, at hvis det værste skete, og der blev brugt en meget svag og let gættet adgangskode, eller hvis en brugers telefon eller desktop blev hacket for at få deres identitetsmasternøgle og adgangskode, ingen ondsindet tredjepart kan ændre brugerens online identitet for at låse dem ud af deres egne online-konti. Og desuden kan den sande ejer af deres identitet trække sig tilbage og erstatte deres mistede eller stjålne online-identitet for i det væsentlige ved at indlæse en normalt offline “Identity Unlock Key”. fra enhver angriber, hvilket gør deres tidligere identitet ubrugelig.

Plausibel: SQRL er mere sårbar over for phishing end eksisterende godkendelsesløsninger

Okay, så dette er faktisk delvist sandt. Når du bruger SQRL ved at scanne en QR-kode, er der faktisk meget lidt beskyttelse mod phishing. Medmindre brugeren er omhyggelig med at sikre, at webstedet, der vises i deres browsers URL-linje, er det samme som det, der vises af SQRL Client-appen, kan de godkende en login-session til angriberen. Dette er stadig bedre end adgangskoder, hvor de ville give phisheren permanent adgang til deres konto (og andre konti, de har andre steder, der deler den samme adgangskode), indtil de ændrer deres adgangskode, men ikke så gode som andre løsninger, der integreres med brugerens browser som U2F-nøgler , WebAuthn, klientcertifikater og (under visse betingelser) adgangskodeadministratorer.

Når du bruger en SQRL-klient på den samme enhed, som du logger på med, har SQRL dog en vis beskyttelse mod phishing på plads. Disse beskyttelser forklares på SQRL “s websted under sektionen om Hvordan SQRL kan forhindre phishing-angreb .Der er også muligheden for at integrere SQRL med browsere (muligvis via plugins) for at give meget stærkere beskyttelse mod phishing-angreb; på niveau med løsninger som WebAuthn og klientcertifikater.

Samlet set rangordner jeg SQRL på omtrent det samme niveau som adgangskodeadministratorer til phishing-beskyttelse. Det har potentialet til at yde stærk beskyttelse mod phishing, når det er installeret på den samme enhed, som brugeren logger på, men giver minimal beskyttelse, når det er installeret på en anden enhed.

Sammenligning med alternativer

Lad os nu sammenligne SQRL med eksisterende udbredte godkendelsesløsninger.

Adgangskoder

SQRL er langt bedre end adgangskoder på mange måder. Det er ikke kun mere praktisk at bruge en gang indstillet op, da brugerne ikke behøver at bekymre sig om at huske eller indtaste flere forskellige adgangskoder for hvert websted, men det beskytter også mod genbrug af adgangskoder, svage adgangskoder, keylogging og til en vis grad phishing.

Ulemper SQRL har sammenlignet med adgangskoder, at det er sværere at implementere for webstedsoperatører, ikke så udbredt, kræver mere tid til oprettelse oprindeligt, kræver en vis indsats for at overføre til en ny enhed og giver et enkelt fejlpunkt for alle brugerens konti, hvis masternøglen er stjålet (dog denne sidste poin t er også tilfældet med adgangskoder, hvis en bruger bruger den samme adgangskode på hvert websted).

Adgangskodeadministratorer

På mange måder ligner SQRL meget adgangskodeadministratorer. De giver begge et enkelt, centraliseret tillidsanker, der fungerer som en slags godkendelsesproxy mellem brugere og individuelle tjenester. Der er dog et par måder, at SQRL er bedre end adgangskodeadministratorer.

Den største fordel, jeg tror, at SQRL har over adgangskodeadministratorer, er at det er lettere og mere sikkert at bruge på computere, der ikke er tillid til eller kun delvist pålidelige. Lad os f.eks. Sige, at en bruger ønsker at logge ind på et websted ved hjælp af en computer på et offentligt bibliotek. Med en adgangskodeadministrator skal han enten få adgang til adgangskoden til dette websted på sin telefon og indtaste den manuelt på computeren eller downloade sin adgangskodeadministrator og adgangskodedatabase på bibliotekscomputeren, skal du låse databasen op ved hjælp af hans hovedadgangskode, og derefter logge ind. Det første scenario er ubelejligt for brugeren og udsætter brugerens almindelige tekstadgangskode for det ene sted for den ikke-betroede computer (og for al malware på den ikke-betroede computer, inklusive keyloggers). Det andet scenario er endnu værre, da det både er ubelejligt og udsætter brugerens hele dekrypterede adgangskodedatabase og hovedadgangskode for den ikke-betroede computer. Med SQRL behøver brugeren kun at scanne en QR-kode på den ikke-betroede computers skærm, hvilket er meget mere praktisk for brugeren, og udsætter kun en enkelt login-session (uden genanvendelige legitimationsoplysninger som en adgangskode) til den ikke-betroede computer .

En anden fordel, som SQRL har over adgangskodeadministratorer, er, at det er lettere at gendanne fra det værste tilfælde: brugerens adgangskodedatabase / masternøgle bliver stjålet. Med en adgangskodeadministrator ville du ikke behøver kun at ændre din adgangskode på hvert websted, du skal også bekymre dig om, at angriberen ændrer dine adgangskoder (muligvis låser dig ud af din konto). Angriberen har også fordelen ved at have en liste over alle de sider, du har en gør det meget lettere at udnytte tyveriet af en adgangskodedatabase. Med SQRL er det stadig en frygtelig situation at have stjålet din hovednøgle, men angriberen har ingen liste over websteder, du har en konto på (i stedet for at gætte ), og kan ikke ændre din adgangskode for at låse dig ude af din konto. Når du har indlæst din identitetsnøgle, er det også lidt mere praktisk at ændre dine loginoplysninger på hvert websted, da SQRL-klienten har mulighed for automatisk at gøre det for dig for hvert websted, du besøger ved login. (Ingen grund til at gå gennem enhver form for “skift adgangskode”.)

Endelig tror jeg, at SQRL har en lille, men vigtig fordel i forhold til adgangskodeadministratorer med hensyn til sit mål om at erstatte adgangskoder helt, og det er, at websteder har mulighed for at håndhæve brug af SQRL frem for traditionelle adgangskoder. Så længe brugere stadig har mulighed for dårlig sikkerhed ved at genbruge den samme adgangskode på hvert websted, er det noget, der stadig vil ske. Hvis SQRL begynder at få bred vedtagelse, kan websteder faktisk begynde at udfase brugen af adgangskoder. Det kan ikke gøres med adgangskodeadministratorer, da de stoler på brugen af adgangskoder for at arbejde.

Med hensyn til ulemper kan jeg faktisk ikke tænke på en situation, hvor SQRL ville nødvendigvis være værre end adgangskodeadministratorer med hensyn til sikkerhed. Den største ulempe, SQRL har, er, at det kræver support fra webstedsoperatører, mens adgangskodeadministratorer ikke kræver nogen særlig support fra eksisterende tjenester. Dette betyder, at du kan begynde at bruge adgangskodeadministratorer lige nu, men SQRL bliver nødt til at vente, indtil websteder implementerer det, før det kan bruges. Dette er en betydelig barriere for adoption.

Klientcertifikater

Den primære fordel, SQRL har over klientcertifikater, er en bekvemmelighed. Klientcertifikater er i øjeblikket komplicerede at konfigurere, vanskelige at overføre mellem computere og har fortrolighedsproblemer, når det samme certifikat bruges på forskellige websteder. Mens vi teoretisk kunne bygge et system ved hjælp af klientcertifikater, der ville løse disse problemer, ville der også være problemet med dårlig integration med websteds-UIer og webservere, hvilket er sværere at løse. Jeg vil ikke gå for meget i detaljer her, da der allerede er en fremragende artikel om anvendelighedsproblemer med klientcertifikater på browserauth.net.

Med hensyn til sikkerhed har klientcertifikater den ulempe, at de kræver involvering af en CA. Dette er (potentielt) dyrt og kræver tillid til tredjeparts CA. Desuden, hvis du vælger at ignorere CAer og i stedet selvsignere dine certifikater, har du spørgsmålet om tilbagekaldelse af certifikat at håndtere. Klientcertifikater har også de samme sikkerheds- og bekvemmelighedsproblemer som adgangskodeadministratorer, når brugere vil logge på en ikke-betroet computer; de er nødt til at overføre deres cert til den ikke-betroede computer, hvilket både er ubelejligt og potentielt udsætter deres masteridentitet for malware på den computer.

Kort sagt, indtil nogen kommer med en bedre, brugervenlig løsning ved hjælp af klientcertifikater, der løser (i det mindste de fleste af) disse problemer, tror jeg ikke, at klientcertifikater er en seriøs konkurrent til SQRL (eller for den sags skyld adgangskoder).

2-faktor-godkendelse

Tænkte bare, at jeg ville nævne dette: SQRL og 2-faktor-godkendelse er ikke gensidigt eksklusive. SQRL er en erstatning for den første faktor i 2FA: adgangskoder. Andre yderligere foranstaltninger som OTP-koder eller FIDO U2F-nøgler kan stadig bruges med SQRL.

WebAuthn

Nu her “s hvor tingene bliver interessante. WebAuthn er en ny (godt, nyere end SQRL) W3C-standard designet til at give en standard API-websteder kan bruge til at godkende brugere med offentlige nøgler på nettet. Ligesom SQRL, det understøtter ved hjælp af brugerens telefon til at godkende en login-session på en ekstern enhed , ud over et par andre godkendelsesmetoder (såsom 2. faktor sikkerhedsnøgler) .

Det er her SQRL endelig møder sit match, i det mindste set ud fra et sikkerhedsperspektiv. Ikke kun giver WebAuthn den samme beskyttelse mod genbrug af adgangskoder, svage adgangskoder og keylogging, som SQRL gør, men det giver også endnu stærkere beskyttelse mod phishing ved at integrere med brugerens browser endda når du godkender et login session for en pc, som brugeren ikke tidligere har konfigureret godkendelses klientsoftwaren til. Dette er muligt, fordi WebAuthn i den situation kommunikerer med brugerens browser direkte ved hjælp af tovejskommunikationsprotokoller som Blutooth eller NFC i stedet for at kommunikere med det websted, brugeren bruger via en envejs QR-kode.

Fra et brugervenligt perspektiv er tingene lidt mere komplicerede. I det mindste vinder WebAuthn igen. Fordi det er en W3C-standard, som allerede har implementeringer i flere browsere i teorien kan brugerne straks begynde at bruge WebAuthn uden at skulle installere nogen tredjepartssoftware. I praksis fokuserer de fleste eksisterende WebAuthn-implementeringer dog på dets anvendelse som en form for andenfaktorautentificering eller som en måde at re-godkende en bruger på som tidligere har logget ind på den samme enhed via en anden login-metode (normalt en adgangskode). Som en primær godkendelsesfaktor mangler WebAuthn stadig retfærdige implementeringer.

Andre mindre overvejelser inkluderer det faktum, at SQRL har en buil t-in metode til at rotere kontonøgler i tilfælde af stjålet hovednøgle, mens WebAuthn er afhængig af websteder til at implementere deres eget system til tilbagekaldelse af nøgler, og det faktum, at WebAuthn kræver bestemt valgfri hardware (som Bluetooth eller NFC) for at godkende til en fjernmaskine, hvorimod SQRL kan arbejde på enhver maskine med en fungerende skærm.

Alt i alt synes jeg det er meget sandsynligt, at WebAuthn i sidste ende vil gøre SQRL forældet. SQRL har muligvis lidt vejrtrækning for nu, men WebAuthn har meget stærkere opbakning fra browserudbydere, webstedsoperatører og andre tredjepartsorganisationer (som W3C). Når WebAuthn får et par implementeringer, der muliggør brugen som en primær godkendelsesfaktor, forventer jeg, at det vil begynde at overtage internettet meget hurtigt.

Advarsler

SQRL er stadig under aktiv udvikling, så materialet præsenteret i dette svar kan ændres. Efterhånden som udviklingen fortsætter, forventer jeg, at nogle af sårbarhederne og usikkerheden i dette svar vil blive behandlet. Det meste af diskussionen foregår i øjeblikket i SQRL-nyhedsgruppen på grc.com.

SQRL er en bekvem løsning på problemet med brugernavnet / password paradox. (dvs. bekvemmelighed / sikkerhed afvejning) uden at bruge en tredjeparts . Det giver et simpelt alternativ til den mest populære godkendelsesmodel (brugernavn & Adgangskode) med næsten intet kompromis med sikkerheden. Det er praktisk talt lige så sikkert for en af de almindelige godkendelsesmodeller, der bruges i dag, så længe du stadig er sikkerhedsbevidst . Hvis du bruger SQRL, betyder det ikke, at du ikke kan følge bedste sikkerhedspraksis som , der kombinerer dette med multifaktorautentificering for vigtige konti.

Det er vigtigt ikke at gå glip af SQRL. SQRL i sig selv giver ikke bedre eller dårligere sikkerhed. Hvis computeren / telefonen selv bliver kompromitteret, eller hvis brugeren bliver narret bliver phishing, så er dette et sidekanalangreb i stedet for en direkte fejl i selve SQRL. Hver konventionel godkendelsesmetode har dette problem med sidekanalangreb Den ubrydelige engangspude er også sårbar over for sidekanalangreb såsom kompromiset med selve puden eller dårlig omgivende sikkerhed eller implementeringer.

Hvis du lyttede til idéens oprindelige forslag på Steve Gibson “s podcast , efterfulgt af Q & A “s, mange af de bekymringer, der er rejst på denne staktråd, er blevet besvaret. Steve sagde det også selv, at denne meget “enkle” og “geniale” (hans ord) idé skulle “undersøges” og “hamres på” af sikkerhedseksperter, da kun tiden vil vise, om dette er en sikker løsning.

Som konklusion falder de fleste af argumenterne mod SQRL uden for selve SQRL og er i stedet problemer med, at mennesker praktiserer dårlig sikkerhed. SQRL introducerer ikke ny klassificering af problemer, som vores traditionelle godkendelsesmetoder ikke allerede har.

SQRL er fremragende, hvis det anvendes korrekt af personer, der er sikkerhedsbevidste. Du skal forstå, at der altid er en kompromis mellem bekvemmelighed og sikkerhed , og denne løsning er sandsynligvis bedste balance af de to, jeg har set.

Kommentarer

• Tak Ansichart. Men kan ‘ t eksisterende godkendelsesløsninger simpelthen bibeholde lige eller overlegne sikkerhedsfunktioner i forhold til SQRL og derefter bruge automatisering til at øge deres brugervenlighed? Hvilken grundlæggende egenskab ved SQRL ‘ s brugervenlighed skyldes ikke automatisering? Jeg spørger, for hvis en bruger har to sorte bokse, der gør det samme; den ene mærket ” Moden ” og den anden mærket ” SQRL “, og de kan begge konstrueres / automatiseres, har den samme grænseflade / knapper på ydersiden af kassen – hvilken merværdi giver SQRL?
• Det løser problemet med adgangskodeparadoxet uden at skulle bruge en tredjepart.
• Jeg kan se. Så hvis nogen ikke ‘ ikke vil have tredjepartsrisikoen for single-sign-on og ikke vil ‘ t generere / gemme deres adgangskoder med en adgangskodeadministrator, kan SQRL træde op. Men hvis SQRL er en mobil sort boks, der beder om en adgangskode til at låse den masternøgle, der bruges til at regenerere / gemme SQRLIDer, og derefter udføre back-channel-sammenkædning af klient ‘ s cookie / QR session_id med server ‘ er optaget SQRLID til login – hvordan er dette en anden mobil sort boks fra en mobil adgangskodeadministrator med automatisk login via den samme bagkanal; eller et to-parts mobilklientcert-plugin med automatisk generering & login via den samme backkanal?
• Jeg har foretaget nogle større redigeringer af mit originale indlæg efter nogle sekunders overvejelser og nærmere læsning af hvad andre har sagt, da jeg måske har overhypet det. Jeg formoder, at hvis mobiltelefonen er den centrale nøgle, forskydes problemet og ville gøre det vigtigere at have stærkere sikkerhed på din telefon. Steve Gibson bringer dette også op i Q & En podcast.

SQRL giver ingen banebrydende forbedringer. QR-koder er et optisk stregkodeformat, der er nyttigt til kort indholdsdistribution – intet mere.

Enhver “auto-login” situation, som SQRL forsøger at løse, kan simpelthen bruge et klientcertifikat, der er gemt på mobilen i stedet.

Hypotetisk kunne en QR-stregkode på en HTTPS-side returnere en serverunderskrevet eller krypteret version af klientcertifikatet (eller en lignende legitimationsoplysninger) som tidligere kendt af serveren, men hvorfor? For legitimationsudløb? Webstedet kan simpelthen afvise en udløbet legitimationsoplysninger direkte.

Så det største sikkerhedsproblem jeg har med dette protokol er: Genopfinding af det firkantede hjul .

Update

Når jeg læser nye svar og kommentarer, vil jeg gerne påpege, hvor let det er at gøre noget svarende til SQRL gennem enkel automatisering af moden eksisterende teknologi :

1. Webstedet beder om enhver CAPTCHA eller lignende “jeg” er en menneskelig verifikation. Når brugeren har overholdt (POSTet), returnerer webstedet en HTTP 403.7 - Client Certificate Required eller en vanilje 403-fejl.
2. Tilpassede 403 sider er lette nok til at opsætte og kan være ret smukke og brugervenlige. Kunne endda starte den nødvendige funktionalitet nedenfor på en måde svarende til “Adobe Reader krævet” -prompterne på mange websteder.
3. Tilpasset 403-side indeholder nogle markeringer, som et brugerdefineret browser-plugin reagerer på. Lad os kalde dette brugerdefinerede plugin “S403L-kompatibel” i ånden af “SQRL-overholdelse”.
4. S403L-pluginet genererer et standardklientcertifikat, der er sikret i den sædvanlige krypterede browsercertcache (eller en tredje- festcache, hvis din browsers nøglelagerkryptering suger). Pluginet opretter en standard CSR til klientcertifikatet og sender CSRen til den URL, der er angivet i 403-markeringen. (f.eks. <s403l ref="https://www.example.com/S403L" />)
5. Den S403L-kompatible server bruger brugerens session_id (hentet fra cookies eller forespørgselsstreng) til at skabe kontinuitet med trin 1 og returnerer derefter CSR som signeret af serveren. Generel servergodkendelse accepterer ethvert klientcertifikat, der blev underskrevet af serveren (og dermed opfyldte de krævede registreringskriterier i trin 1).
6. S403L-pluginet gemmer det signerede klientcertifikat i browserens cache. Fra derefter på kan standardbrowseren uden plugin-hjælp “automatisk logge ind” på serveren på standard SSL / TLS-måde, indtil certifikatet udløber.

Den “mobile” og “visuelle” natur af SQRL er noget af en forkert omdirigering, da det ikke giver løsrevet tofaktorautentificering, og du har nu brug for to computere til at navigere på internettet i stedet for en. Medmindre du retter USB-webkameraet på dit skrivebord på sin egen skærm.

Afvejningerne mellem adgangskoder og certifikater er veldefinerede i sikkerhedsfællesskabet: Adgangskoder passer ind i en menneskelig hjerne; certifikater passer ikke ind en menneskelig hjerne ( normalt ) men kan have skør entropi og gode PKI-styringsfunktioner (udløb , tilbagekaldelse, politikudvidelser osv.). SQRL passer rent i hverken lejren; og hvis det kører mod den mindre menneskelige mere-computerlejr, som det ser ud til at være – har det mange års udvikling og sikkerhedsanalyse for at gentage eksisterende X.509-funktioner. ul class = “comments”>

Jeg vil gerne behandle det første spørgsmål: “et af de problemer, jeg kan tænke på, er, hvis QR-læseren er kompromitteret, at vise www.google.com i stedet for www.nsa-super-secret-place.gov/123 “:

Hovednøglen bruges som frø i HMAC sammen med webstedsadressen (FQDN). Så selvom QR-koden muligvis koder for en helt anden URL, afslører protokollen IKKE den godkendelseskode, der normalt ville blive sendt til www.google.com (i eksemplet).

For det andet glemmer mange af bidragsydere hovedmålene, når de udarbejder denne idé:

1. anonymitet ved ikke at bruge tredjepart
2. brugervenlighed
3. intet behov for at skrive hemmelig legitimationsoplysninger på ikke-tillid til computere

Jeg mener, at protokollerne løser disse fuldt ud!

Der er dog kompromiser, der faktisk kommer fra den første objectjive. Hvis ingen tredjepart er involveret i godkendelsen, hvordan kan man tilbagekalde deres godkendelsesoplysninger? Derudover er masternøgles sikkerhed en åbenbar bekymring. Jeg forestiller mig, at dette skal beskyttes godt af fremtidige mobile enheder i en HSM-lignende chip. Indtil da er nøglen kun en filnål mobilenhed, beskyttet af en adgangskode, selvom PBDKF2 sikrer, at det er meget langsomt til faktisk at tøve det.

Kommentarer

• Igen, hvad ‘ er nyt ved denne idé? Det forekommer mig at være en primitiv variation på det nu nedlagte Windows CardSpace.
• Ja, du har ret i CardSpace. Så er der U-Prove, der også ejes af Microsoft. Spørgsmålet er, hvordan ville du bruge CardSpace eller U-Prove på en computer, som du ikke stoler på (internetcafé eller vennecomputer). Det tilføjede Steve.
• Ah, ok, at ‘ er det, jeg manglede. Jeg er stadig enig med @TerryChia i, at dette er en ikke-starter uden en tilbagekaldelsesmekanisme for brugernøglerne.
• @Xander Der er en tilbagekaldelsesmekanisme for brugernøglerne. grc.com/sqrl/idlock.htm