Ta som vanlig alt som er relatert til Steve Gibson med en lastebil med salt. Obligatorisk attrition.org lenke .

La oss ta en titt på Gibsons beskrivelse av protokollen sin.

• QR-koden som presenteres nær innloggingen ledeteksten inneholder URL-en til autentiseringstjenesten for nettstedet. URL-en inneholder et sikkert generert langt tilfeldig tall slik at hver presentasjon av påloggingssiden viser en annen QR-kode. (I kryptosirkler er dette lange tilfeldige tallet kjent som en “nonce.”)

• Smarttelefonens SQRL-autentiseringsapp kryper kryptografisk domenenavnet på nettstedet som er tastet inn av brukeren «hovednøkkel for å produsere et stedsspesifikt offentlig nøkkelpar.

• Appen signerer kryptografisk hele URL-en inneholdt i QR-koden ved hjelp av den stedsspesifikke private nøkkelen. Siden URL-en inneholder et sikkert langt tilfeldig tall (nonce), er signaturen unik for det nettstedet og QR-koden.

• Appen utsteder et sikkert HTTPS POST-spørsmål til QR-siden kode URL, som er autentiseringstjenesten for nettstedet. POST gir den stedsspesifikke offentlige nøkkelen og den samsvarende kryptografiske signaturen til QR-kodens URL.

• Det autentiserende nettstedet mottar og bekrefter POST-spørringen ved å returnere en standard HTTP «200 OK» uten annet innhold. SQRL-appen bekrefter vellykket innlevering av den brukersignerte QR-koden.

• Det autentiserende nettstedet har URL-en som inneholder nonce som kom tilbake fra påloggingssiden via brukerens smarttelefon. Den har også en kryptografisk signatur av den nettadressen, og brukerens nettstedsspesifikke offentlige nøkkel. Den bruker den offentlige nøkkelen for å bekrefte at signaturen er gyldig for URL-en. Dette bekrefter at brukeren som produserte signaturen, brukte den private nøkkelen som tilsvarer den offentlige nøkkelen. Etter å ha bekreftet signaturen, gjenkjenner det autentiserende nettstedet den nå autentiserte brukeren ved sin stedsspesifikke offentlige nøkkel.

The største tingen som hopper ut på meg er bruken av en » hovednøkkel » av brukeren. Hvis jeg leser protokollen riktig, styrer den ene hovednøkkelen brukerens hele online identitet …

Antagelig er denne hovednøkkelen lagret i brukerens telefon i en applikasjonsdatabase. Som åpner en enorm gapende angrepsvektor i form av skadelig programvare designet spesielt for å stjele hovednøkkelen.

Så la oss sammenligne forskjellen mellom hva som skjer når et passord blir kompromittert og hva som skjer når hovednøkkelen blir kompromittert. Forutsatt at du følger god passordpraksis for lange, unike og svært tilfeldige passord lagret i en passordbehandling, er alt du trenger å gjøre å endre et enkelt passord hvis det blir kompromittert. Hva skjer hvis hovednøkkelen din blir kompromittert? må på en eller annen måte få alle nettstedene du autentiserte med for å gjenkjenne at hovednøkkelen din er kompromittert. Det eneste problemet er, siden du ikke har andre måter å autentisere med nettstedet på, for eksempel brukernavn eller e-postadresser, hvordan vil siden vite at det faktisk er deg som prøver å tilbakekalle hovednøkkelen?

Som alt som kommer ut av Gibson, er denne SRQL-ordningen svært feil og gir ingen fordeler fremfor konvensjonelle metoder.

Komme nts

• » Hvis du ‘ følger god passordpraksis » er en stor advarsel, og de fleste netizens gjør det ikke ‘.En del av SQRL ‘ s løfte er å redusere brukere ‘ trenger å holde seg oppdatert om beste praksis. Videre vil SQRL-spesifikasjonen kreve at hovednøkkelen lagres kryptert med et hovedpassord og vil være umulig å tøffe (innstilt til å ta ~ 60-tallet for ett forsøk). Å få passordet vil ofte være lite trivielt siden SQRL fremmer autentisering utenfor bandet (dvs. nøkkellogging av en hacket maskin vil ikke ‘ ikke alltid hjelpe deg). Så mens konsekvensene av fullt kompromiss er høye, er sannsynligheten for kompromiss noe lav.
• SQRL kan fremdeles ha mangler som trenger å løse, men det hevder å løse en rekke problemer som finnes i eksisterende tilnærminger til autentisering, og enhver kritikk av SQRL som hevder det » gir ingen fordeler » bør omfatte tilbakevendinger av disse påstandene i stedet for å forvente at påstanden blir akseptert blindt.
• > Som alt som kommer ut av Gibson , denne SRQL-ordningen er svært feil og gir ingen fordeler i forhold til konvensjonelle metoder. — Dette ser ikke ut ‘ å svare på spørsmålet, og jeg føler faktisk at du har problemer med teknologien på grunn av hvem som fant på det. Noen av punktene du nevnte som mangler adresseres faktisk av » spesifikasjonen «. For eksempel nevner ikke SQRL ‘ t hvordan hovednøkkelen er lagret, men Steve Gibson ‘ s kommentarer om det er at en mobil klient, for eksempel, vil kryptere det med et hovedpassord ved hjelp av en kryptering som det tar 60-tallet i gjennomsnitt å utføre.
• Gibson-eksplisitt adresserer beskyttelsen til hovednøkkelen.
• Hold inne en sekund. Du likestiller at din SQRL-hovednøkkel blir stjålet med en av LastPass-nøklene dine som blir stjålet. Ville det ikke være ‘ å sammenligne det med at hele, dekrypterte LastPass-passorddatabase blir stjålet?

Samlet sett ser ikke protokollen ut til å øke sikkerheten i forhold til eksisterende teknologi. Hvis du leter etter den beste måten å beskytte din identitet på nettet, er dette uten tvil ikke det . Men la oss gå over fordeler og ulemper:

Fordeler

Det er umulig å » dele » et passord i smal forstand at et ondsinnet nettsted ikke kan bruke autentiseringen som er gitt til et nettsted for å logge på et annet nettsted.

Et voldsomt angrep mot godkjenningstokenet er ikke mulig.

Påloggingsinformasjon lagres ikke på datamaskinen din. Dette beskytter deg mot en liten delmengde av angitt på arbeidsstasjonen. Spesielt er du beskyttet mot angrep som stjeler passordet ditt fra datamaskinen. Du er ikke beskyttet mot noen form for øktkapring eller nettleserovertakelsesangrep, og du er nå også utsatt for telefonrelaterte angrep. Mer om det senere.

Ulemper

Denne teknikken er farlig utsatt for MITM-angrep og sosial engineering. Sannsynligvis mer enn noen annen autentiseringsordning som er i bruk, inkludert passord. Autentiseringstrinnet og påloggingsinitieringstrinnet er iboende frakoblet i den forstand at telefonen vil autentisere riktig mot enhver presentert QR-kode, uansett hvordan eller hvor den blir presentert for brukeren.

Så for eksempel et phishing-nettsted kan vise en autentisk innloggings-QR-kode som logger inn angriperen i stedet for brukeren. Gibson er trygg på at brukerne vil se navnet på banken eller butikken eller nettstedet i telefonappen under autentisering og vil derfor utvise tilstrekkelig årvåkenhet for å hindre angrep. Historien antyder dette usannsynlig, og den mer fornuftige forventningen er at å se det riktige navnet på appen vil berolige brukeren til å tro at nettstedet er legitimt fordi det var i stand til å utløse den velkjente påloggingsforespørselen på telefonen. Forsiktigheten som allerede er slått inn i hodet på brukerne angående passordsikkerhet, betyr ikke nødvendigvis nye autentiseringsteknikker som denne, og det er dette som gjør denne appen sannsynligvis iboende mindre motstandsdyktig mot sosialteknikk. «a9ad2fb1fb»>

SQRL absolutt er ikke uten feil, men det er absolutt bedre enn de fleste primære autentiseringsløsninger som er mye brukt på nettet i dag når det gjelder sikkerhet og (og dette er viktig) brukervennlighet. Tillat meg å forklare.

Misforståelser

La meg først redegjøre for noen av misforståelsene i noen av de andre svarene på dette spørsmålet. Mange av disse svarene er utdaterte og ble skrevet før endringer i SQRL-dokumentasjonen som adresserer problemene som presenteres i dem, mens andre ser ut til å legge for stor vekt på feil i SQRL som også er til stede i mange andre mye brukte eksisterende autentiseringsløsninger, mens de ignorerer fordelene. Så la oss oppklare noen misforståelser her, skal vi?

Myte: SQRL krever skanning av QR-koder for å fungere

Dette er rett og slett ikke sant. QR-koder er en bekvemmelighet som gjør SQRL enklere å bruke på datamaskiner som brukeren ikke har satt opp SQRL klientprogramvare på. SQRLs nettsted sier følgende:

Three Ways to Go …smarttelefon valgfritt:

Selv om den opprinnelige inspirasjonen for utviklingen av dette systemet var en smarttelefon som skannet en QR-kode på innloggingssiden til et nettsted, muliggjør et lite tillegg til den modellen to viktige driftsmåter: Bare gjør QR-kodebildet også til en klikkbar lenke til den samme URL-en som er kodet inn i QR-koden. Dette gir tre måter å logge på:

• Skann koden med en smarttelefon: Bruk modellen beskrevet ovenfor, skanner en brukers smarttelefon QR-koden som vises på innloggingssiden til et nettsted, og brukeren er logget inn på nettstedet.
• TAP KODEN på en smarttelefon: For å logge på et nettsted PÅ smarttelefonen, når den visuelle SQRL-koden også er en lenke i URL-stil (ved å bruke sqrl: // som skjema), SQRL-appen som er installert i smarttelefonen, vil motta den lenken og logge brukeren sikkert inn på nettstedet på telefonen.
• Klikk på koden på en stasjonær eller bærbar PC-skjerm : For å bruke SQRL-systemet på et hvilket som helst stasjonært eller bærbart system, vil et SQRL-program på skrivebordet bli installert og registrere seg selv for å motta sqrl: // lenker. (Dette ligner på måten et e-postprogram registrerer seg for å motta mailto: lenker.) Dette gjør at den samme løsningen kan brukes av brukere på skrivebordet som de bruker på smarttelefonene sine. Når et nettsted tilbyr en SQRL-kode, klikker brukeren bare på koden med musemarkøren, og den lokalt installerte SQRL-appen vil vises, ber om SQRL-passordet, bekrefter domenet og logger dem deretter på.

Myte: SQRL-hovednøkkelen er lagret helt ukryptert og ubeskyttet på telefonen din

Jeg er ikke sikker på hvorfor noen gjorde dette antagelse, da det virker opplagt for meg at dette ikke ville være tilfelle. SQRL-hovednøkkelen er beskyttet omtrent på samme måte som du vil beskytte en passorddatabase: med et sterkt hovedpassord. Å stjele en brukers telefon vil ikke automatisk gi deg tilgang til deres online identitet med mindre du også hadde hovedpassordet. Mer informasjon om nøkkeladministrasjon blir forklart på siden på SQRL Client- Side Key Management på SQRLs nettsted.

Myte: Hvis hovednøkkelen din blir stjålet, kan du ikke endre påloggingsinformasjonen din

Dette er også falskt. SQRL gir en innebygd måte å la den ekte kontoinnehaveren oppdatere påloggingsinformasjonen sin i tilfelle en kompromittert nøkkel. Denne funksjonen er kjent som identitetslås:

“Identitetslås” forhindrer identitetsendring & tillater gjenoppretting: Dette er også betydelig nok til å fortjene sin egen detaljerte beskrivelsesside: “ Identitetslåseprotokollen ” (side 4 i lenkeblokken nederst på denne siden.) En gang en brukerens identitet er etablert med en webserver, SQRL c lient er ute av stand for å endre identiteten. Dette betyr at hvis det verste skjedde, og et veldig svakt og lett gjettet passord ble brukt, eller en brukers telefon eller skrivebord ble hacket for å skaffe identitetsnøkkel og passord, ingen ondsinnet tredjepart kan endre brukerens online identitet for å låse dem utenfor sine egne online-kontoer. Og dessuten, ved å laste inn en normalt frakoblet «Identity Unlock Key», kan den sanne eieren av identiteten deres pensjonere seg og erstatte sin tapte eller stjålne online identitet for å i hovedsak ta den tilbake fra enhver angriper, noe som gjør deres tidligere identitet ubrukelig.

Plausibel: SQRL er mer sårbar for phishing enn eksisterende autentiseringsløsninger

Ok, så dette er faktisk delvis sant. Når du bruker SQRL ved å skanne en QR-kode, er det virkelig veldig liten beskyttelse mot phishing. Med mindre brukeren er forsiktig med å sikre at nettstedet som vises i nettleserens nettleserlinje er det samme som det som vises av SQRL Client-appen, kan de godkjenne en påloggingsøkt for angriperen. Dette er fortsatt bedre enn passord, der de vil gi phisheren permanent tilgang til kontoen sin (og andre kontoer de har andre steder som har samme passord) til de endrer passordet, men ikke så bra som andre løsninger som integreres med brukerens nettleser som U2F-nøkler , WebAuthn, klientsertifikater og (under visse betingelser) passordadministratorer.

Når du bruker en SQRL-klient på samme enhet som du logger på med, har SQRL imidlertid noen beskyttelser mot phishing på plass. Disse beskyttelsene blir forklart på SQRLs nettsted under seksjonen Hvordan SQRL kan hindre phishing-angrep .Det er også muligheten for å integrere SQRL med nettlesere (muligens gjennom plugins) for å gi mye sterkere beskyttelse mot phishing-angrep. På linje med løsninger som WebAuthn og klientsertifikater.

Samlet sett rangerer jeg SQRL på omtrent på samme nivå som passordbehandlere for phishing-beskyttelse. Den har potensial til å gi sterk beskyttelse mot phishing når den er installert på den samme enheten brukeren logger på, men gir minimal beskyttelse når den er installert på en annen enhet.

Sammenligning med alternativer

Nå kan vi sammenligne SQRL med eksisterende mye brukte autentiseringsløsninger.

Passord

SQRL er langt bedre enn passord på mange måter. Ikke bare er det mer praktisk å bruke når det er satt opp, siden brukere ikke trenger å bekymre seg for å huske eller skrive inn flere forskjellige passord for hvert nettsted, men det beskytter også mot gjenbruk av passord, svake passord, nøkkellogging og til en viss grad phishing.

Ulemper SQRL har sammenlignet med passord er at det er vanskeligere å implementere for nettstedsoperatører, ikke så mye brukt, krever mer tid å sette opp i utgangspunktet, krever litt innsats for å overføre til en ny enhet, og gir et enkelt feilpunkt for alle brukerens kontoer hvis hovednøkkelen er stjålet (skjønt denne siste poinen t er også tilfelle for passord hvis en bruker bruker samme passord på hvert nettsted).

Passordadministratorer

På mange måter ligner SQRL veldig passordadministratorer. De gir begge et enkelt, sentralisert tillitsanker som fungerer som en slags autentiseringsproxy mellom brukere og individuelle tjenester. Det er noen måter at SQRL er bedre enn passordadministratorer.

Den største fordelen jeg tror SQRL har over passordadministratorer er at det er enklere og sikrere å bruke på ikke-klarerte eller bare delvis pålitelige datamaskiner. Si for eksempel at en bruker ønsker å logge inn på et nettsted ved hjelp av en datamaskin i et offentlig bibliotek. Med en passordbehandling må han enten få tilgang til passordet for nettstedet på telefonen og skrive det inn på datamaskinen på nytt manuelt, eller laste ned passordbehandling og passorddatabase på biblioteksdatamaskinen, låse opp databasen ved hjelp av hovedpassordet, og logg deretter på. Det første scenariet er ubeleilig for brukeren, og eksponerer brukerens klartekstpassord for det ene nettstedet til den ikke-klarerte datamaskinen (og all skadelig programvare på den ikke-klarerte datamaskinen, inkludert nøkkelloggere). Det andre scenariet er enda verre, ettersom det både er upraktisk og utsetter brukerens hele dekrypterte passorddatabase og hovedpassord for den ikke-klarerte datamaskinen. Med SQRL vil brukeren bare måtte skanne en QR-kode på skjermen til den ikke-klarerte datamaskinen, noe som er mye mer praktisk for brukeren, og bare eksponere en enkelt påloggingsøkt (uten gjenbrukbare legitimasjon som et passord) til den ikke-klarerte datamaskinen. .

En annen fordel SQRL har over passordadministratorer er at det er lettere å gjenopprette fra verste fall: brukerens passorddatabase / hovednøkkel blir stjålet. Med en passordadministrator ville du ikke trenger bare å endre passordet ditt på hvert nettsted, du trenger også å bekymre deg for at angriperen endrer passordene dine (muligens sperrer deg utenfor kontoen din). Angriperen har også fordelen av å ha en liste over alle nettstedene du har en gjør det enklere å utnytte tyveriet av en passorddatabase. Med SQRL er det fortsatt en forferdelig situasjon å være stjålet med hovednøkkelen, men angriperen har ingen liste over nettsteder du har en konto på (må i stedet gjette ), og kan ikke endre passordet ditt for å låse deg ute av kontoen din. Når du har lastet inn identitetslåsingsnøkkelen din, er det også litt mer praktisk å endre påloggingsinformasjonen på hvert nettsted, siden SQRL-klienten har muligheten til å gjøre det automatisk for hvert nettsted du besøker ved pålogging. (Ingen grunn til å gå gjennom alle «endre passord» -skjemaer.)

Til slutt tror jeg SQRL har en liten, men viktig fordel i forhold til passordadministratorer når det gjelder målet om å erstatte passord helt, og det er at nettsteder har muligheten til å håndheve bruk av SQRL over tradisjonelle passord. Så lenge brukerne fortsatt har muligheten for dårlig sikkerhet, som bruker det samme passordet på hvert nettsted, er det noe som fremdeles vil skje. Hvis SQRL begynner å få bred adopsjon, kan nettsteder faktisk begynne å fase ut bruken av passord. Det kan ikke gjøres med passordadministratorer, ettersom de stoler på bruk av passord for å fungere.

Når det gjelder ulemper, kan jeg faktisk ikke tenke på en situasjon der SQRL ville nødvendigvis være verre enn passordforvaltere mht sikkerhet. Den største ulempen SQRL har er at den krever støtte fra nettstedoperatører, mens passordadministratorer ikke krever spesiell støtte fra eksisterende tjenester. Dette betyr at du kan begynne å bruke passordadministratorer akkurat nå, men SQRL må vente til nettsteder implementerer det før det kan brukes. Dette er en betydelig barriere for adopsjon.

Klientsertifikater

Den primære fordelen SQRL har fremfor klientsertifikater er en enkelhet. Klientsertifikater er for tiden kompliserte å konfigurere, vanskelige å overføre mellom datamaskiner og har personvernproblemer når samme cert brukes på forskjellige nettsteder. Mens vi teoretisk sett kunne bygge et system ved hjelp av klientsertifikater som ville løse disse problemene, ville det også være problemet med dårlig integrasjon med nettstedsgrensesnitt og webservere, som er vanskeligere å løse. Jeg vil ikke gå for mye i detaljer her, da det allerede er en utmerket artikkel om bruksspørsmålene til klientsertifikater på browserauth.net.

Når det gjelder sikkerhet, har klientsertifikater ulempen med å kreve involvering av en CA. Dette er (potensielt) dyrt, og krever tillit til tredjeparts CA. Videre, hvis du velger å ignorere sertifiseringsinstanser og i stedet selv signere sertifikatene dine, har du spørsmålet om sertifikat tilbakekalling å håndtere. Klientsertifikater har også de samme sikkerhets- og bekvemmelighetsproblemene som passordadministratorer når brukere vil logge på en ikke-klarert datamaskin; de må overføre sertifikatet til den ikke-klarerte datamaskinen, noe som både er upraktisk og potensielt utsetter sin masteridentitet for skadelig programvare på den datamaskinen.

Kort fortalt, til noen kommer med en bedre, brukervennlig løsning ved å bruke klientsertifikater som løser (i det minste de fleste av) disse problemene, tror jeg ikke klientsertifikater er en seriøs konkurrent til SQRL (eller for den saks skyld passord).

2-faktor autentisering

Tenkte bare jeg nevnte dette: SQRL og 2-faktor autentisering er ikke gjensidig utelukkende. SQRL er en erstatning for den første faktoren i 2FA: passord. Andre tilleggstiltak som OTP-koder eller FIDO U2F-nøkler kan fortsatt brukes med SQRL.

WebAuthn

Nå her ”s hvor ting blir interessante. WebAuthn er en ny (vel, nyere enn SQRL) W3C-standard designet for å gi en standard API-nettsteder som kan bruke til å autentisere brukere med offentlige nøkler på nettet. Akkurat som SQRL, den støtter bruker brukerens telefon til å autentisere en påloggingsøkt på en ekstern enhet , i tillegg til noen få andre autentiseringsmetoder (for eksempel 2. faktor sikkerhetsnøkler) .

Det er her SQRL endelig møter sin kamp, i det minste fra et sikkerhetsperspektiv. Ikke bare gir WebAuthn all den samme beskyttelsen mot gjenbruk av passord, svake passord og nøkkellogging som SQRL gjør, men det gir også enda sterkere beskyttelse mot phishing ved å integrere med brukerens nettleser til og med når du godkjenner en pålogging økt for en PC brukeren ikke tidligere har satt opp autentisatorens klientprogramvare på. Dette er mulig fordi WebAuthn i den situasjonen kommuniserer med brukerens nettleser direkte ved hjelp av toveiskommunikasjonsprotokoller som Blutooth eller NFC i stedet for å kommunisere med nettstedet brukeren bruker via en enveis QR-kode.

Fra et brukervennlighetsperspektiv er ting litt mer kompliserte. I det minste vinner WebAuthn igjen. Fordi det er en W3C-standard som allerede har implementeringer i flere nettlesere , i teorien kan brukere umiddelbart begynne å bruke WebAuthn uten å måtte installere noen tredjepartsprogramvare. I praksis fokuserer de fleste eksisterende WebAuthn-implementeringer imidlertid på bruken som en form for andrefaktorautentisering, eller som en måte å re-autentisere en bruker på som tidligere logget på den samme enheten via en annen påloggingsmetode (vanligvis et passord). Som en primær autentiseringsfaktor mangler WebAuthn fremdeles ganske levedyktige implementeringer.

Andre mindre hensyn inkluderer det faktum at SQRL har en buil t-in-metode for å rotere nøklene til kontoer i tilfelle en stjålet hovednøkkel, mens WebAuthn er avhengig av nettsteder for å implementere sitt eget system for tilbakekalling av nøkler, og det faktum at WebAuthn krever viss valgfri maskinvare (som Bluetooth eller NFC) for å autentisere til en ekstern maskin, mens SQRL kan fungere på en hvilken som helst maskin med en fungerende skjerm.

Totalt sett tror jeg det er veldig sannsynlig at WebAuthn til slutt vil gjøre SQRL foreldet. SQRL kan ha litt pusterom for nå, men WebAuthn har mye sterkere støtte fra nettleserleverandører, nettstedsoperatører og andre tredjepartsorganisasjoner (som W3C). Når WebAuthn får et par implementeringer som gjør det mulig å bruke den som en primær autentiseringsfaktor, forventer jeg at den vil begynne å ta over nettet veldig raskt.

Advarsler

SQRL er fortsatt under aktiv utvikling, så materialet som presenteres i dette svaret kan endres. Etter hvert som utviklingen fortsetter, forventer jeg at noen av sårbarhetene og usikkerheten i dette svaret vil bli løst. Mesteparten av diskusjonen foregår for tiden i SQRL-nyhetsgruppen over på grc.com.

SQRL er en praktisk løsning på problemet med brukernavnet / passordparadoks. (dvs. bekvemmelighets- / sikkerhetsavveining) uten å bruke en tredjeparts . Det gir et enkelt alternativ til den mest populære autentiseringsmodellen (Brukernavn & Passord), med praktisk talt ingen kompromisser for sikkerhet. Det er praktisk talt like sikkert for noen av de vanlige autentiseringsmodellene som brukes i dag, så lenge du fremdeles er sikkerhetsbevisst . Hvis du bruker SQRL, betyr det ikke at du ikke kan følge beste sikkerhetspraksis som og kombinerer dette med flerfaktorautentisering for viktige kontoer.

Det er viktig å ikke gå glipp av poenget med SQRL. SQRL i seg selv gir ikke bedre eller dårligere sikkerhet. Hvis datamaskinen / telefonen selv blir kompromittert, eller brukeren blir lurt til blir phished, så er dette et sidekanalangrep i stedet for en direkte feil av SQRL selv. Hver konvensjonell autentiseringsmetode har dette problemet med sidekanalangrep Den ubrytbare engangspaden er også sårbar for sidekanalangrep for eksempel kompromisset med selve puten, eller dårlig sikkerhet eller implementeringer.

Hvis du lyttet til det opprinnelige forslaget til ideen på Steve Gibson «s podcast , etterfulgt av Q & A «s, mange av bekymringene som er reist på denne stabletråden har blitt besvart. Også Steve sa det selv at denne veldig «enkle» og «geniale» (hans ord) ideen måtte «undersøkes» og «hamres på» av sikkerhetseksperter, da bare tiden vil vise om dette er en sikker løsning.

Avslutningsvis faller de fleste argumentene mot SQRL utenfor selve SQRL, og er i stedet problemer med at mennesker praktiserer dårlig sikkerhet. SQRL introduserer ikke ny klassifisering av problemer som våre tradisjonelle autentiseringsmetoder ikke allerede har.

SQRL er utmerket hvis det brukes riktig av personer som er sikkerhetsbevisste. Du må forstå at det alltid er en avveining mellom bekvemmelighet og sikkerhet , og denne løsningen er sannsynligvis beste balanse av de to jeg har sett.

Kommentarer

• Takk Ansichart. Men kan ‘ t eksisterende autelløsninger bare beholde like eller overlegne sikkerhetsfunksjoner i forhold til SQRL og deretter bruke automatisering for å øke brukerens bekvemmelighet? Hvilken grunnleggende egenskap ved SQRL ‘ brukerkomfort er ikke på grunn av automatisering? Jeg spør fordi hvis en bruker har to sorte bokser som gjør det samme; den ene merket » Eldre » og den andre merket » SQRL » og de kan begge konstrueres / automatiseres med samme grensesnitt / knapper på utsiden av boksen – hvilken tilleggsverdi gir SQRL?
• Det løser problemet med passordparadokset uten å måtte bruke en tredjepart.
• Ser jeg. Så hvis noen ikke ‘ ikke vil ha tredjepartsrisikoen for enkel pålogging og ikke vil ‘ t generere / lagre passordene sine med en passordbehandling, kan SQRL trappe opp. Men hvis SQRL er en mobil svart boks som ber om et passord for å låse opp hovednøkkelen som brukes til å regenerere / lagre SQRLIDer og deretter utføre bakkanalkobling av klient ‘ s cookie / QR session_id med server ‘ er registrert SQRLID for pålogging – hvordan er dette en annen mobil svart boks fra en mobil passordbehandling med automatisk innlogging via samme bakkanal; eller et to-parts certifikat for mobilklient med automatisk generering & pålogging via samme bakkanal?
• Jeg har gjort noen større redigeringer av det opprinnelige innlegget mitt etter noen andre betraktninger og nærmere lesing til hva andre har sagt, da jeg kanskje har overhypet det. Jeg antar at å ha mobiltelefonen som den sentrale nøkkelen, forskyver problemet, og det vil gjøre det viktigere å ha sterkere sikkerhet på telefonen din. Steve Gibson tar dette også opp i Q & En podcast.

SQRL gir ingen banebrytende forbedringer. QR-koder er et optisk strekkodeformat som er nyttig for kort innholdsdistribusjon – ikke noe mer.

Enhver «automatisk påloggingssituasjon» som SQRL prøver å løse, kan ganske enkelt bruke et klientsertifikat som er lagret på mobilen i stedet.

Hypotetisk kunne en QR-strekkode på en HTTPS-side returnere en serversignert eller kryptert versjon av klientsertifikatet (eller en lignende legitimasjon) som serveren tidligere har kjent, men hvorfor? For legitimasjon utløp? Nettstedet kan rett og slett avvise en utløpt legitimasjon direkte.

Så det største sikkerhetsproblemet jeg har med dette protokollen er: Reinventing the Square Wheel .

Update

Når jeg leser nye svar og kommentarer, vil jeg påpeke hvor enkelt det er å gjøre noe som ligner på SQRL gjennom enkel automatisering av moden eksisterende teknologi :

1. Nettstedet ber om alle CAPTCHA-er eller lignende «Jeg» er en menneskelig bekreftelse. Når brukeren har overholdt (POSTet), returnerer nettstedet en HTTP 403.7 - Client Certificate Required eller en vanilje 403-feil.
2. Tilpassede 403 sider er enkle å installere og kan være ganske pene og brukervennlige. Kan til og med starte opp funksjonaliteten som kreves nedenfor, på en måte som ligner på «Adobe Reader required» -meldingen på mange nettsteder.
3. Tilpasset 403-side inneholder en del markeringer som et tilpasset nettleserprogramtillegg reagerer på. La oss kalle dette tilpassede pluginet «S403L-kompatibelt» i ånden av «SQRL-samsvar».
4. S403L-plugin genererer et standard klientsertifikat, som er sikret i vanlig kryptert nettlesersertcache (eller en tredje- festbuffer hvis nettleserens kryptering av nøkkelbutikk suger). Plugin oppretter en standard CSR for klientsertifikatet og sender CSR til URL-en spesifisert i 403-markeringen. (f.eks. <s403l ref="https://www.example.com/S403L" />)
5. Den S403L-kompatible serveren bruker brukerens session_id (hentet fra informasjonskapsler eller spørringsstreng) for å skape kontinuitet med trinn 1 og returnerer deretter CSR som signert av serveren. Generell serverautentisering godtar ethvert klientsertifikat som ble signert av serveren (og dermed oppfylte registreringskriteriene som ble krevd i trinn 1).
6. S403L-pluginet lagrer det signerte klientsertifikatet i nettleserens cache. deretter på kan standard nettleser uten plugin-assistanse «automatisk logge inn» på serveren på standard SSL / TLS-måte til sertifikatet utløper.

Den «mobile» og «visuelle» naturen av SQRL er noe av en feilretting, da den ikke gir frittliggende tofaktorautentisering, og du trenger nå to datamaskiner for å navigere på internett i stedet for en. Med mindre du retter USB-webkameraet på skrivebordet mot sin egen skjerm.

Avveiningene mellom passord og sertifikater er godt definert i sikkerhetssamfunnet: Passord passer inn i en menneskelig hjerne; sertifikater passer ikke inn en menneskelig hjerne ( vanligvis ), men kan ha gal entropi og gode PKI-styringsfunksjoner (utløper , tilbakekalling, policyutvidelser osv.). SQRL passer rent inn i ingen av leirene; og hvis den driver mot den mindre menneskelige mer-datamaskinleiren som den ser ut til å være – har den mange års utvikling og sikkerhetsanalyse for å gjenta eksisterende X.509-funksjoner.

Kommentarer

• > kan ganske enkelt bruke et klientsertifikat som er lagret på mobilen i stedet.— bortsett fra at denne teknologien eksisterer i mange år både på mobil og stasjonær pc, og den ‘ er ikke så utbredt som man skulle ønske. Og i motsetning til klientsertifikatet krever SQRL ikke ‘ t at du skal bevise din virkelige identitet for å opprette en » SQRL-identitet «. Hvis du ønsker det, kan du opprette så mange identiteter du vil. Dette betyr at fordelen i forhold til klientsertifikater er at du har anonymitet fra autiprotokollen ‘ s side.
• @jpkrohling Det er en vanlig misforståelse at klientsertifikater kreve avsløring av identitet for å bruke. Dette er et krav fra kommersielle signeringsmyndigheter å bruke sine globalt utskiftbare tillitskjeder. I praksis kan et klientsertifikat ganske enkelt være en anonym CSR opprettet av klienten og signert av en bestemt server, etter å ha oppfylt hvilke kriterier som er ønsket (CAPTCHAs, tidligere konto, etc). Sertifikater kan også ha en innebygd utløp. Type 40-L QR-strekkoder kan sende / lagre 1KB X.509-klientsertifikatet hvis ønskelig.
• Ok, sant, det er dårlig. Fra dette perspektivet kan klienten (for eksempel mobilappen) generere et klientsertifikat for hvert nettsted som brukeren registrerer. Dette høres dyrere ut enn å hashe litt informasjon, men kan være en interessant løsning. I alle fall er jeg fortsatt ikke ‘ ikke enig i dine påstander om at SQRL er verre enn ubrukelig.
• Jeg var kanskje hard på den formuleringen og vil fjerne den. Men jeg ser ikke ‘ SQRL som noe annet enn mer sexy måte å distribuere forhandlede klientopplysninger på; og en som ikke har ‘ t løste noen av de subtile problemene som løses av modne autentiseringsskjemaer. En passordbehandling er kjedelig (jeg bryr meg ikke ‘ fordi jeg ‘ er paranoiac) men jeg vet at bare jeg og en nettside dele hvert enkeltpassord i min krypterte nøkkelbutikk. Jeg trenger ikke ‘ ikke å bekymre meg for fancy nye hash / auth-ordninger, bare kvaliteten på PRNG / TRNG som passordadministratoren min bruker for å generere passord.
• @LateralFractal hvem bryr seg om det ‘ er nytt eller ikke? SQRL tillater brukervennlig autentisering der den første parten ikke avslører hemmeligheten med den andre parten eller en tredjepart som kan ha kompromittert 2. parts ‘ s sikkerhet. Det ‘ er et forsøk på å løse et reelt verdensproblem som hittil ingen andre har klart å løse.

Jeg vil ta opp det første spørsmålet: «et av problemene jeg kan tenke meg er om QR-leseren er kompromittert, å vise www.google.com i stedet for www.nsa-super-secret-place.gov/123 «:

Hovednøkkelen brukes som frø i HMAC sammen med nettadressen (FQDN). Så selv om QR-koden kan kode en helt annen URL, vil protokollen IKKE avsløre autentiseringskoden som normalt vil bli sendt til www.google.com (i eksemplet).

For det andre glemmer mange av bidragsyterne hovedmålene når de jobber med denne ideen:

1. anonymitet ved ikke å bruke tredjepart
2. brukervennlighet
3. ikke behov for å skrive hemmelig legitimasjon på ikke-klarerte datamaskiner

Jeg tror protokollene adresserer disse i sin helhet!

Imidlertid er det kompromisser som faktisk kommer fra den første obectjive. Hvis ingen tredjepart er involvert i autentiseringen, hvordan kan man trekke tilbake deres autentiseringsdetaljer? I tillegg er sikkerheten til hovednøkkelen en åpenbar bekymring. Jeg ser for meg at dette skal være godt beskyttet av fremtidige mobile enheter i en HSM-lignende chip. Inntil da er nøkkelen bare en filnål mobilenhet, beskyttet av et passord, selv om PBDKF2 sørger for at det er veldig sakte å faktisk tvinge det.

Kommentarer

• Igjen, hva ‘ er nytt med denne ideen? Det virker for meg å være en primitiv variant på det nå nedlagte Windows CardSpace.
• Ja, du har rett i CardSpace. Så er det U-Prove også eid av Microsoft. Spørsmålet er hvordan du vil bruke CardSpace eller U-Prove på en datamaskin du ikke stoler på (internettkafé eller venners datamaskin). Det er det Steve la til.
• Ah, ok, at ‘ er det jeg manglet. Jeg er fortsatt enig med @TerryChia i at dette er en ikke-startpakke uten en tilbakekallingsmekanisme for brukernøklene.
• @Xander Det er en tilbakekallingsmekanisme for brukernøklene. grc.com/sqrl/idlock.htm