Ota tavalliseen tapaan Steve Gibsoniin liittyvä kuorma-autolla suolaa. Pakollinen attrition.org -linkki .

Tarkastellaan Gibsonin protokollan kuvausta.

• Sisäänkirjautumisen lähellä oleva QR-koodi -kehote sisältää sivuston todennuspalvelun URL-osoitteen. URL-osoite sisältää turvallisesti luodun pitkän satunnaisluvun, joten jokaisella kirjautumissivun esityksellä on erilainen QR-koodi. (Salauspiireissä tämä pitkä satunnaisluku tunnetaan nimellä ”nonce”.)

• Älypuhelimen SQRL-todennusohjelma salaa käyttäjän avaimen sivuston salauksen. ”pääavaimen tuottamaan sivustokohtaisen julkisen avaimen parin.

• Sovellus allekirjoittaa salauksen QR-koodissa olevan koko URL-osoitteen käyttämällä sivustokohtaista yksityistä avainta. Koska URL-osoite sisältää suojatun pitkän satunnaisluvun (nonce), allekirjoitus on tälle sivustolle ja QR-koodille yksilöllinen.

• Sovellus lähettää suojatun HTTPS POST -kyselyn QR: lle. koodin URL-osoite, joka on sivuston todennuspalvelu. POST tarjoaa sivustokohtaisen julkisen avaimen ja QR-koodin URL-osoitteen vastaavan salauksen allekirjoituksen.

• Todentava verkkosivusto vastaanottaa ja kuittaa POST-kyselyn palauttamalla vakio-HTTP: n ”200 OK” ilman muuta sisältöä. SQRL-sovellus tunnustaa käyttäjän allekirjoittaman QR-koodin onnistuneen lähettämisen.

• Todennuspaikalla on URL-osoite, joka sisältää käyttäjän, joka palasi kirjautumissivulta käyttäjän kautta. Sillä on myös kyseisen URL-osoitteen salaus ja käyttäjän sivustokohtainen julkinen avain. Se tarkistaa julkisen avaimen avulla, että allekirjoitus on kelvollinen URL-osoitteelle. Tämä vahvistaa, että allekirjoituksen tuottanut käyttäjä käytti julkista avainta vastaavaa yksityistä avainta. Allekirjoituksen vahvistamisen jälkeen todennussivusto tunnistaa nyt todennetun käyttäjän sivustokohtaisella julkisella avaimellaan.

suurin asia, joka hyppää minuun, on ” -pääavaimen käyttö ”. Jos luen protokollaa oikein, yksi pääavain ohjaa käyttäjän koko online-identiteettiä …

Oletettavasti tämä pääavain on tallennettu käyttäjän puhelimeen sovellustietokantaan. Mikä avaa valtavan ammottavan hyökkäysvektorin haittaohjelmien muodossa, joka on suunniteltu erityisesti pääavaimen varastamiseen.

Verrataan siis eroa sen välillä, mitä tapahtuu, kun salasana vaarantuu, ja sen välillä, mitä tapahtuu, kun pääavain oletetaan, että noudatat hyviä salasanahallinnassa tallennettujen pitkien, yksilöllisten ja erittäin satunnaisten salasanojen hyviä käytäntöjä, sinun tarvitsee vain vaihtaa yksi salasana, jos se vaarantuu. Mitä tapahtuu, jos pääavaimesi vaarantuu? täytyy jotenkin hankkia kaikki todentamasi sivustot tunnistaakseen, että pääavaimesi on vaarantunut. Ainoa ongelma on, koska sinulla ei ole muita tapoja todentaa sivustolla, kuten käyttäjänimi tai sähköpostiosoitteet, mistä sivusto tietää, että itse sinä yrität peruuttaa pääavaimen?

Kuten mikä tahansa Gibsonista tuleva, tämäkin SRQL-järjestelmä on erittäin puutteellinen eikä tarjoa mitään etuja perinteiseen verrattuna menetelmiä.

Comme nts

• ” Jos ’ noudatat hyviä salasanakäytäntöjä ” on valtava huomautus, ja useimmat verkkokäyttäjät eivät tee sitä ’.Osa SQRL ’ -lupauksesta on vähentää käyttäjiä ’ on pysyttävä parhaiden käytäntöjen kärjessä. Lisäksi SQRL-spesifikaatio vaatii pääavaimen tallentamista salatulla pääsalasanalla, ja sitä on mahdotonta karkottaa (viritetty kuluttamaan ~ 60 sekuntia yhdelle yritykselle). Salasanan hankkiminen on usein ei-triviaalia, koska SQRL edistää kaistan ulkopuolista todennusta (ts. Hakkeroidun koneen avainkoodaus ei aina auta sinua ’). Joten vaikka täydellisen kompromissin seuraukset ovat suuret, kompromissien todennäköisyys on jonkin verran pieni.
• SQRL: llä voi vielä olla puutteita, jotka on korjattava, mutta se väittää, että ratkaisee useita todentamisen nykyisissä lähestymistavoissa esiintyviä ongelmia, ja kaikki SQRL: n kritiikat, jotka sitä väittävät ”, eivät tarjoa etuja ” tulisi sisältää näiden väitteiden kumoaminen sen sijaan, että odotettaisiin väitteen sokea hyväksyminen.
• > Kuten kaikki, mikä tulee Gibsonista , tämä SRQL-järjestelmä on erittäin puutteellinen eikä tarjoa mitään etuja perinteisiin menetelmiin verrattuna. — Tämä ’ ei näytä auttavan vastaamaan kysymykseen, ja minusta tuntuu, että sinulla on ongelmia tekniikan kanssa sen vuoksi, kuka sen keksi. Jotkin puutteista, jotka mainitsit puutteina, on tosiasiallisesti käsitelty ” spec ”. Esimerkiksi SQRL itse ei mainitse ’ t, kuinka pääavain tallennetaan, mutta Steve Gibson ’ kommentoi sitä, että matkapuhelin Esimerkiksi asiakas salaisi sen pääsalasanalla käyttämällä salausta, jonka suorittaminen kestää keskimäärin 60 vuotta.
• Gibsonin yksiselitteisyys koskee pääavaimen suojausta.
• Pidä kiinni toinen. Voit rinnastaa varastamasi SQRL-pääavaimesi yhteen varastettuihin LastPass-avaimiin. Eikö ’ ole parempi analogia rinnastaa se koko, salauksen purettuun LastPass-salasanatietokantaan , joka varastetaan?

Kaiken kaikkiaan protokolla ei näytä lisäävän nykyisen tekniikan turvallisuutta. Jos etsit parasta tapaa suojata henkilöllisyytesi verkossa, tämä on epäilemättä ei se . Mutta käykäämme läpi edut ja haitat:

edut

” on mahdotonta jakaa ” salasana kapeassa mielessä, että haitallinen sivusto ei voi käyttää yhdelle sivustolle annettua todennusta kirjautumalla toiseen sivustoon.

Raaan voiman hyökkäys todennustunnusta vastaan on ei toteutettavissa.

Tunnistetietoja ei ole tallennettu tietokoneellesi. Tämä suojaa sinua pieneltä osajoukolta työasemaan kohdistetut hyökkäykset. Erityisesti olet suojattu hyökkäyksiltä, jotka varastavat salasanasi tietokoneeltasi. Olet kuitenkin ei suojattu minkäänlaisilta istunnon kaappauksilta tai selaimen haltuunottohyökkäyksiltä, ja olet nyt myös altis puhelimiin liittyville hyökkäyksille. Lisätietoja siitä myöhemmin.

Haitat

Tämä tekniikka on vaarallisesti altis MITM-hyökkäyksille ja sosiaaliselle suunnittelulle. Todennäköisesti enemmän kuin mikään muu käytössä oleva tunnistusjärjestelmä, mukaan lukien salasanat. Todennusvaihe ja sisäänkirjautumisen aloitusvaihe ovat luonnostaan katkenneita siinä mielessä, että puhelin todentaa oikein mihin tahansa esitettyyn QR-koodiin, riippumatta siitä, miten tai missä se esitetään käyttäjälle.

Joten esimerkiksi tietojenkalastelusivusto voi näyttää aito sisäänkirjautumisen QR-koodi, joka kirjautuu hyökkääjään käyttäjän sijaan. Gibson on vakuuttunut siitä, että käyttäjät näkevät pankkisovelluksen tai kaupan tai sivuston nimen puhelinsovelluksessa todennuksen aikana ja ovat siksi riittävän valppaita hyökkäysten estämiseksi. Historia viittaa tähän epätodennäköiseen, ja järkevämpi oletus on, että oikean nimen näkeminen sovelluksessa rauhoittaa käyttäjää väärin ajattelemaan, että sivusto on laillinen, koska se pystyi käynnistämään tutun kirjautumispyynnön puhelimessa. Käyttäjien päähän jo lyöty varoitus salasanaturvallisuudesta ei välttämättä tarkoita tämän kaltaisia uusia todennustekniikoita, mikä tekee sovelluksesta todennäköisesti luonnostaan vähemmän vastustuskykyisen sosiaalisen suunnittelun suhteen.

Tämä tekniikka yhdistää sekä todennuksen että henkilöllisyyden fyysiseksi objektiksi, joka usein katoaa tai varastetaan. Tässä mielessä se ” Se muistuttaa pikemminkin passia kuin salasanaa. Kenellä tahansa puhelimesi hallussa on yhtäkkiä yksinomaan henkilöllisyytesi: hyökkääjä ei vain voi esiintyä sinä, vaan ilman toista kopiota toisessa puhelimessa ( epätodennäköistä), nyt olet menettänyt kyvyn tunnistaa itsesi.Todennusavaimia ei voi peruuttaa, joten et voi palauttaa henkilöllisyyttäsi ilman kaistan ulkopuolista palautusta jokaisesta sivustosta. Ja vaikka taajuusalueen ulkopuolinen palautuminen onkin olemassa, voi olla vaikea ymmärtää, miksi sivuston ylläpitäjän pitäisi luottaa sinuun, kun kohtaavat kaksi käyttäjää, joista toisella on henkilöllisyys ja toisen ilman.

Tämä tekniikka yhdistää kaikki todennustunnuksesi yhdeksi avaimeksi , ellet luo muita manuaalisesti. Tämä tekee yhdestä avaimestasi erityisen mehukkaan kohteen hyökkääjille. Lisäksi avain on tallennettu puhelimeesi, jonka laitteilla on yleensä ollut naurettavan huokoinen sisäinen suojaus. Epätavallisen mehukkaiden kohteiden yhdistäminen huonompaan turvallisuuteen ei tee sinusta turvallista.

Vaihtoehdot

Tämän järjestelmän ongelmallisin näkökohta on, kuinka huonosti se vertaa käytettävissä oleviin vaihtoehtoihin.

Tämän päivän turvallisin yleisesti hyväksytty vaihtoehto on lastpass, keepass ja muut sellaiset selaimeen integroidut salasanajärjestelmät. Erityisesti asiakaspuolen salaus lievittää tarvetta luottaa mihinkään kolmanteen osapuoleen. Ja mikä tärkeintä, selaimen integrointi tekee tietojenkalastelun käytännössä mahdottomaksi . LastPass tai KeePass täyttävät salasanan vain, jos ne toimitetaan oikealta verkkotunnukselta, mikä tarkoittaa, että jos käyttäjälle tarjotaan haitallinen sivusto, hänellä ei ole pääsyä salasanaansa.

Lisäksi LastPass lisäsi äskettäin ominaisuuden Tämä kiusaa käyttäjiä vaihtamaan salasanoja, jotka eivät ole maailmanlaajuisesti ainutlaatuisia. Tämä auttaa estämään salasanojen uudelleenkäytön, mikä tarkoittaa, että Gibsonin tekniikan ensisijainen hyöty voidaan helposti saada tällä työkalulla nykyisin nykyisillä sivustoilla ilman hänen järjestelmään liittyvää lisävarmuutta.

Nykyiset toisen tekijän todennustavat, jotka käyttävät puhelimia tai vastaavia laitteita, auttavat suojaamaan käyttäjän sisäänkirjautumisia tänään, tekevät niin jo tavalla, joka ei tee sinusta välittömästi alttiita henkilöllisyysvarkauksille, jos laite varastetaan. Lisätty kaksitekijän todennuksen turvallisuus on siinä, että laitetta tai salasanaa ei voida käyttää, jos se varastetaan ilman toista. Gibsonin tekniikka on suurimmaksi osaksi vastustuskykyinen sisällytettäessä kaksivaiheiseen järjestelmään, mikä tekee tämän tason suojaukseksi Tiedosto ei ole käytettävissä.

TL; DR:

Gibsonin todennustekniikka ei tuota riittävää hyötyä ylittämään myös sen aiheuttamia ylimääräisiä tietoturvakustannuksia. Nämä kustannukset ovat olennainen osa itse järjestelmää, eikä niitä todennäköisesti voida selvittää romuttamatta koko mallia.

Voit väittää, että se on parempi kuin ei mitään, mutta et voi väittää, että se on parempi kuin mikään jo meillä.

Gibsonin päivitykset

Gibson ilmoitti äskettäin lisäsuojasta tietojenkalastelua vastaan, koska tämä on ollut suurta kritiikkiä. Niiden suojaus on tämä: Jos et käytä QR-koodeja, matkapuhelinta jne. Ja sinulla on sen sijaan järjestelmässä todennusagentti (esimerkiksi selaimessa), palvelin voi tarkistaa, että todennus vastaus tulee samalta IP: ltä kuin todennuspyyntö. Tämä on hyvä ja hyvä, mutta tämän protokollan tarkoituksena on siirtää henkilöllisyytesi matkapuhelimeesi. Jos ainoa turvallinen tapa käyttää protokollaa on olla käyttämättä sen ydintä ominaisuus, niin meidän pitäisi ehkä miettiä uudelleen, mitä yritämme saavuttaa.

Teoriassa voisit jatkaa matkapuhelimesi käyttöä, jos (ja vain jos) matkapuhelimesi tiesi että se käytti samaa IP: tä kuin tietokoneesi. Mitä se tietysti ei voi tietää, koska se ei tiedä tietokoneesi IP-osoitetta.

Parempi ratkaisu

Kuten aiemmin todettiin, jos todennustoiminto on selaimessasi, , koko tietojenkalasteluongelma ratkaistaan välittömästi ilman vaivaa tai vahvistusta. Jopa vähiten kykenevää käyttäjää ei voida huijata todentamaan väärälle sivustolle, koska sivuston todennustunnus liittyy verkkotunnukseen ja selain voitti. Älä salli todennusta väärään verkkotunnukseen. Tämä on tekniikka, jota käytetään jo tänään, on täysin automaattinen eikä vaadi sivuston yhteistyötä tai mitään älykkyyttä käyttäjältä.

Tätä menetelmää voidaan vahvistaa vaatimalla toinen todennustekijä (kuten matkapuhelimen aika-vaihteleva avain), joka taas on jo käytettävissä ja on käytössä tänään, mikä suojaa sinua (etenkin) kohdesivuston tai yrityksen ruuveilta.

Mitä tulee huoleen siitä, että selainpuolen todennus on haavoittuva asiakas-työaseman hyökkäyksille: vaikka se on totta, totta on myös se, että jos selaimesi on vaarantunut, niin ei kyseisen selaimen käyttö on turvallista riippumatta siitä, mitä todennusmekanismia käytät.Haittaohjelmien kirjoittajat voivat odottaa (ja jo tekevätkin) odottavan, että todistat itsesi superturvallisella tekniikallasi, ja lähettää sitten tarvittavan liikenteen hiljaa ” omalle ” tilisi, ilman että näet mitään vikaa. Kumpikaan SQRL tai mikään muu todennusjärjestelmä ei voi suojata vaarantuneen selaimen käyttäjää, enempää kuin ovilukot voivat suojata talotulelta. Tulenkestävien lukkojen ostaminen ei ole ratkaisu.

Missä seuraavaksi

Jos etsit ehdotonta suojaa esiintymiseltä , katso sitten Fido U2F -merkkiä. Tämä standardi loistaa, missä SQRL puuttuu, ja antaa sinulle taatun immuniteetin MITM (esim. tietojenkalastelu) -hyökkäyksille. Se tekee niin todentamalla paitsi käyttäjän, myös kanavan, joten sinä ”takaamme, että (a) tiliäsi ei voida todentaa ilman tunnusta, ja myös (b) tunnustasi voidaan käyttää vain todentamaan yhteys koneeseen, johon se on liitetty. Katso tämä vastaus saadaksesi lisätietoja.

Kommentit

• Tietoja ensimmäisestä kohdasta : Sikäli kuin ymmärrän, tästä ajateltiin ja yksi vaihtoehto on antaa verkkosivuston, jolla olet todentamassa, olla vastuussa uudelleenohjauksesta. Joten sisäänkirjautumisen yhteydessä sinut ohjataan oikealle pankin ’ -sivulle, ei hyökkääjälle. Toisesta kohdasta sama tapahtuu tänään LastPassin kaltaisten työkalujen käyttäjien kanssa. Ellet aseta jotakin suojamekanismia (esimerkiksi PIN-koodia), myös kaikki salasanasi varastetaan. Miksi ’ t voi olla sama SQRL: n suhteen? Lisäksi, kuinka ymmärrän spesifikaatiosta, käyttäjä voi varmuuskopioida henkilöllisyytensä jopa paperilla (QR-koodina).
• Ja kolmannesta kohdasta: sama tapahtuu useimpien käyttäjien kanssa, jotka eivät ’ älä käytä salasananhallintaa käyttämällä yksinkertaisesti yhtä käyttäjätunnusta / salasanaa useilla verkkosivustoilla. Tai salasanahallinnan käyttäjien kanssa, joiden ” identiteetti ” on levinnyt useille verkkosivustoille, mutta tallennettu yhteen paikkaan (LastPass ’ palvelimet, 1Password-tietokanta ja niin edelleen). Joten se ’ ei oikeastaan ole SQRL-virhe. Kaiken kaikkiaan, mitä enemmän luin SQRL: stä, sitä enemmän näen sen edut verrattuna nykyisiin vaihtoehtoihin. Sanokaa, että sanotte Steve Gibsonista, mutta SQRL näyttää todella hyvältä vaihtoehdolta.
• ” Varoitus, joka on jo lyöty päähän käyttäjät eivät välttämättä käänny tämän tyyppisiin uusiin todentamistekniikoihin. . . ” Tämä on erinomainen asia, ja taistelu on jo menetetty markkinoinnille. QR-koodien nähdään olevan helppo tapa saada aikaan asioita, ei potentiaalisena hyökkäysvektorina. Ainakin käyttäjätunnus / salasana-paria käytettiin ENSIMMÄISEN todennusmekanismina, ei markkinointityökaluna.
• @jpkrohling: Salasanojen hallitsijoiden osalta luulisin, että useimmat tällaisen ohjelmiston käyttäjät EI tallenna pääsalasanaa. mobiililaitteellaan juuri siksi, että he ovat tietoisia siitä, kuinka vaarallista se on. Minulla on yksi fyysinen kopio pääsalasanastani turvallisessa paikassa, mutta ei sähköisiä kopioita. Hyökkäykset, jotka antaisivat pääsyn pääsalasanalleni, eroavat hyökkäyksistä, jotka vaarantaisivat sivuston salasanan, ja ovat paljon vähemmän todennäköisiä. (Ensinnäkin siksi, että salasanatietokannan hyökkäys merkitsisi hyökkäystä minuun henkilökohtaisesti, eikä suuren vaarantuneen sivuston sijasta.)
• @jpkrohling LastPass ja KeePass eivät tallenna pääsalasanaa missään. Sitä ’ käytettiin salasanatietokannan lukituksen avaamiseen, mutta sitä ei ’ ole tallennettu. Tämä eroaa pohjimmiltaan siitä, että sinulla on yksi avain, jota itse käytetään kaikkialla.

SQRL varmasti ei ole virheetön, mutta se on varmasti parempi kuin useimmat nykypäivän verkossa laajalti käytetyt ensisijaiset todennusratkaisut turvallisuuden ja (ja tämä on tärkeää) käytettävyyden kannalta. Sallikaa minun selittää.

Väärinkäsitykset

Sallikaa minun ensin selvittää muutama väärinkäsitys joissakin muissa vastauksissa tähän kysymykseen. Monet näistä vastauksista ovat vanhentuneita, ja ne on kirjoitettu ennen muutoksia SQRL-dokumentaatioon jotka käsittelevät niissä esitettyjä ongelmia, kun taas toiset näyttävät painottavan kohtuuttomasti SQRL: n puutteita, joita esiintyy myös monissa muissa laajalti käytössä olevissa olemassa olevissa todennusratkaisuissa, sivuuttaen samalla sen edut. Selvitetään siis muutama väärinkäsitys, me?

Myytti: SQRL vaatii skannaamaan QR-koodit toimiakseen

Tämä ei yksinkertaisesti ole totta. QR-koodit ovat mukavuus mikä helpottaa SQRL: n käyttöä tietokoneissa, joihin käyttäjä ei ole asettanut SQRL – asiakasohjelmistoa. SQRL: n verkkosivustolla mainitaan seuraava:

Kolme tapaa mennä.älypuhelin valinnainen:

Vaikka alkuperäinen inspiraatio tämän järjestelmän kehittämiselle oli älypuhelin, joka skannaa QR-koodin verkkosivuston kirjautumissivulta, pieni lisäys malliin mahdollistaa kaksi merkittävämpää toimintatapaa: Yksinkertaisesti tee QR-koodikuvasta myös napsautettava linkki samaan URL-osoitteeseen, joka on koodattu QR-koodiin. Tämä antaa kolme tapaa kirjautua sisään:

• Skannaa koodi älypuhelimella: Edellä kuvatun mallin mukaan käyttäjän älypuhelin skannaa verkkosivuston kirjautumissivulla näkyvän QR-koodin ja käyttäjä kirjautuu kyseiselle sivustolle.
• TAP KOODI älypuhelimessa: Voit kirjautua verkkosivustolle älypuhelimessa, kun visuaalinen SQRL-koodi on myös URL-tyylinen linkki (mallina käytetään sqrl: //). Älypuhelimeen asennettu SQRL-sovellus saa linkin ja kirjautuu käyttäjän turvallisesti puhelimen sivustoon.
• Napsauta koodia työpöydän tai kannettavan tietokoneen näytöllä : Jos haluat käyttää SQRL-järjestelmää missä tahansa pöytätietokoneessa tai kannettavassa tietokoneessa, asennetaan työpöydän SQRL-sovellus, joka rekisteröi itsensä vastaanottamaan sqrl: // -linkkejä. (Tämä on samanlainen tapa, jolla sähköpostiohjelma rekisteröidy vastaanottamaan mailto: linkkejä.) Tämä antaa käyttäjille mahdollisuuden käyttää samaa ratkaisua työpöydällä kuin älypuhelimissa. Kun jokin verkkosivusto tarjoaa SQRL-koodin, käyttäjä napsauttaa vain koodia hiiren osoittimella, ja paikallisesti asennettu SQRL-sovellus ponnahtaa esiin, pyytää SQRL-salasanaansa, vahvistaa verkkotunnuksen ja kirjautua sisään.

Myytti: SQRL-pääavain on tallennettu puhelimeesi täysin salaamattomana ja suojaamattomana

En ole varma, miksi jotkut tekivät tämän oletus, koska minusta näyttää itsestään selvältä, että näin ei olisi. SQRL-pääavain on suojattu suunnilleen samalla tavalla kuin sinä suojaisit salasanatietokannan: vahvalla pääsalasanalla. Käyttäjän puhelimen varastaminen ei automaattisesti antaisi sinulle pääsyä hänen online-henkilöllisyyteensä, ellei sinulla ole myös pääsalasanaa. Lisätietoja avaimen hallinnasta on sivulla SQRL Client- Sivun avaimen hallinta SQRL: n verkkosivustolla.

Myytti: Jos pääavaimesi varastetaan, et voi muuttaa kirjautumistietojasi

Tämä on myös väärä. SQRL tarjoaa sisäänrakennetun tavan sallia todellisen tilinhaltijan päivittää kirjautumistunnuksensa, jos avain on vaarantunut. Tätä ominaisuutta kutsutaan nimellä Identity Lock:

”Identity Lock” estää identiteetin muutoksen & sallii palautuksen: Tämä on riittävän merkittävä ansaitakseen oman yksityiskohtaisen kuvaussivunsa: “ Tunnuslukitusprotokolla ” (sivu 4 tämän sivun alaosassa olevassa linkkilohkossa.) käyttäjän henkilöllisyys on määritetty Web-palvelimella, SQRL c lient ei pysty muuttamaan kyseistä identiteettiä. Tämä tarkoittaa, että jos pahin tapahtui ja käytettiin hyvin heikkoa ja helposti arvattavaa salasanaa tai käyttäjän puhelinta tai työpöytää hakkeroitiin identiteetin pääavaimen ja salasanan saamiseksi, mikään haitallinen kolmas osapuoli ei voi muuttaa käyttäjän online-identiteettiä lukitakseen heidät omilta verkkotileiltään. Ja lisäksi lataamalla normaalisti offline-tilassa olevan ”Identity Unlock Key” -tunnuksen, henkilöllisyytensä todellinen omistaja voi jäädä eläkkeelle ja korvata kadonneen tai varastetun online-identiteettinsä olennaisesti ja ottaa sen takaisin miltä tahansa hyökkääjältä, mikä tekee heidän edellisestä identiteetistään hyödytön.

Uskottava: SQRL on alttiimpi tietojenkalastelulle kuin olemassa olevat todennusratkaisut

Okei, joten tämä on itse asiassa osittain totta. Kun käytetään SQRL: ää skannaamalla QR-koodi, tietojenkalastelua vastaan on todellakin hyvin vähän suojaa. Ellei käyttäjä ole varovainen varmistaakseen, että heidän selaimensa URL-palkissa näkyvä verkkosivusto on sama kuin SQRL Client -sovelluksen näyttämä sivusto, hän voi valtuuttaa hyökkääjän kirjautumisistunnon. Tämä on silti parempi kuin salasanat, jos he antavat tietojenkalastelijalle pysyvän pääsyn tililleen (ja muille tileille, jotka heillä on muualla, joilla on sama salasana), kunnes he vaihtavat salasanansa, mutta eivät yhtä hyviä kuin muut käyttäjän selaimeen integroituvat ratkaisut, kuten U2F-avaimet , WebAuthn, asiakasvarmenteet ja (tietyissä olosuhteissa) salasananhallintaohjelmat.

Kun kuitenkin käytät SQRL-asiakasta samalla laitteella, jolla kirjaudut sisään, SQRL: llä on joitain suojauksia Tietojenkalastelu on paikallaan. Nämä suojaukset on selitetty SQRL: n verkkosivustolla kohdassa Kuinka SQRL voi estää tietojenkalasteluhyökkäykset .Siellä on myös mahdollisuus integroida SQRL selaimiin (mahdollisesti laajennusten kautta), jotta suojaus tietojenkalasteluhyökkäyksiltä olisi paljon vahvempi, samoin kuin ratkaisut, kuten WebAuthn ja asiakassertifikaatit.

Kaiken kaikkiaan pidän SQRL: ää suunnilleen samalla tasolla kuin salasanojen hallintaohjelmat tietojenkalastelusuojauksessa. Se voi tarjota vahvan suojan tietojenkalastelua vastaan, kun se on asennettu samaan laitteeseen, johon käyttäjä kirjautuu, mutta tarjoaa minimaalisen suojan, kun se asennetaan eri laitteelle.

Vertailu vaihtoehtoihin

Verrataan nyt SQRL: ää olemassa oleviin laajalti käytettyihin todennusratkaisuihin.

Salasanat

SQRL on huomattavasti parempia salasanoista monin tavoin. Sen lisäksi, että sitä on helpompi käyttää, kun se on asetettu ylöspäin, koska käyttäjien ei tarvitse huolehtia useiden eri salasanojen muistamisesta tai kirjoittamisesta uudelleen kullekin sivustolle, mutta se suojaa myös salasanojen uudelleenkäytöltä, heikoilta salasanoilta, näppäinlukitukselta ja jossain määrin verkkourkinnalta.

Haitat SQRL on vertaillut salasanoihin, että se on vaikeampaa toteuttaa verkkosivustojen ylläpitäjille, ei niin laajalti käytetty, vaatii enemmän aikaa perustamiseen, vaatii jonkin verran ponnisteluja siirtyä uudelle laitteelle ja tarjoaa yhden epäonnistumispisteen kaikki käyttäjän tilit, jos pääavain varastetaan (vaikka tämä viimeinen poin t pätee myös salasanoihin, jos käyttäjä käyttää samaa salasanaa jokaisella sivustolla).

Salasananhallinta

Monin tavoin SQRL on hyvin samanlainen kuin salasananhallinta. Molemmat tarjoavat yhden, keskitetyn luotettavuusankkurin, joka toimii eräänlaisena todennuksen välityspalvelimena käyttäjien ja yksittäisten palveluiden välillä. On kuitenkin olemassa pari tapaa, joilla SQRL on parempia kuin salasanojen hallinta.

Mielestäni tärkein etu SQRL: llä on salasanojen hallintaohjelmiin nähden, että sitä on helpompi ja turvallisempi käyttää epäluotettavilla tai vain osittain luotettavilla tietokoneilla. Oletetaan esimerkiksi, että käyttäjä haluaa kirjautua verkkosivustolle julkisen kirjaston tietokoneella. Salasanahallinnan avulla hänen on joko käytettävä kyseisen sivuston salasanaa puhelimessaan ja kirjoitettava se manuaalisesti tietokoneeseen tai ladattava salasananhallinta ja salasanatietokanta kirjastotietokoneelle, avaa tietokanta lukituksen pääsalasanallaan ja kirjaudu sitten sisään. Ensimmäinen skenaario on käyttäjän kannalta hankala ja altistaa käyttäjän kyseisen sivuston selkeän salasanan epäluotettavalle tietokoneelle (ja kaikki epäluotettavan tietokoneen haittaohjelmat, näppäinlukijat mukaan lukien). Toinen skenaario on vielä pahempi, koska se on sekä hankalaa että altistaa käyttäjän koko salauksen puretun salasanatietokannan ja pääsalasanan epäluotettavalle tietokoneelle. SQRL: n avulla käyttäjän tarvitsee vain skannata QR-koodi epäluotettavan tietokoneen näytöltä, mikä on paljon helpompaa käyttäjälle, ja paljastaa vain yhden kirjautumisistunnon (ilman uudelleenkäytettäviä tunnistetietoja, kuten salasana) epäluotettavaan tietokoneeseen .

Toinen etu, jonka SQRL: llä on salasanojen hallintaohjelmiin nähden, on se, että se on helpompi toipua pahimmassa tapauksessa: käyttäjän salasanatietokanta / pääavain varastetaan. Salasanahallinnan avulla et vain sinun on vaihdettava salasanasi jokaisella sivustolla, sinun on myös huolehdittava siitä, että hyökkääjä vaihtaa salasanasi (mahdollisesti lukitsee sinut tililtäsi). Hyökkääjällä on myös se etu, että hänellä on luettelo kaikista sivustoistasi ottaa salasanatietokannan varastamisen hyödyntämisen paljon helpommin. SQRL: n avulla pääavaimen varastaminen on silti kauhea tilanne, mutta hyökkääjällä ei ole luetteloa sivustoista, joilla sinulla on tili (hänen on sen sijaan arvattava) ), eikä se voi vaihtaa salasanaasi lukitaksesi sinut tilisi. Kun lataat henkilöllisyyden avaimen, on myös hieman helpompaa muuttaa kirjautumistunnuksia jokaisella sivustolla, koska SQRL-asiakas pystyy tekemään sen puolestasi automaattisesti jokaiselle sivustolle, jolla vierailet sisäänkirjautumisen yhteydessä. (Ei tarvitse mennä minkä tahansa ”muuta salasanaa” -lomakkeiden kautta.)

Lopuksi luulen, että SQRL: llä on yksi pieni mutta tärkeä etu salasanojen ylläpitäjiin nähden tavoitteensa korvata salasanat kokonaan, ja se on, että sivustoilla on mahdollisuus pakottaa SQRL: n käyttö perinteisiin salasanoihin nähden. Niin kauan kuin käyttäjillä on edelleen mahdollisuus heikkoon tietoturvaan ja käyttää samaa salasanaa uudelleen jokaisella sivustolla, niin tapahtuu edelleen. Jos SQRL alkaa saada laajaa käyttöönottoa, sivustot voivat todella alkaa lopettaa käytön salasanojen hallitsijoilla, koska he luottavat salasanojen käyttöön toimiakseen.

Haittojen suhteen en todellakaan voi ajatella tilannetta, jossa SQRL olisi välttämättä huonompi kuin salasanojen hallintaohjelmat turvallisuus. SQRL: n suurin haittapuoli on se, että se vaatii verkkosivustojen ylläpitäjien tukea, kun taas salasanojen hallinta ei vaadi erityistä tukea olemassa olevilta palveluilta. Tämä tarkoittaa, että voit alkaa käyttää salasananhallintaohjelmia heti, mutta SQRL: n on odotettava, kunnes sivustot toteuttavat sen, ennen kuin sitä voidaan käyttää. Tämä on merkittävä este adoptiolle.

Asiakassertifikaatit

Ensisijainen etu, jonka SQRL: llä on asiakkaan varmenteisiin nähden, on helppokäyttöisyys. Asiakassertifikaattien asettaminen on tällä hetkellä monimutkaista, vaikea siirtää tietokoneiden välillä, ja niillä on tietosuojaongelmia, kun samaa varmentetta käytetään eri sivustoissa. Teoriassa voisimme rakentaa järjestelmän, joka käyttää asiakassertifikaatteja ja joka ratkaisi nämä ongelmat, mutta ongelmana on myös huono integrointi verkkosivustojen käyttöliittymiin ja verkkopalvelimiin, jotka ovat vaikeampia ratkaista. En käsittele tässä liikaa yksityiskohtia, koska siellä on jo erinomainen artikkeli asiakassertifikaattien käytettävyyteen liittyvistä kysymyksistä browserauth.netissä.

Turvallisuuden kannalta asiakasvarmenteilla on se haitta, että ne edellyttävät varmentajan osallistumista. Tämä on (mahdollisesti) kallista ja edellyttää kolmannen osapuolen varmentajan luottamista. Lisäksi, jos päätät jättää varmentajat huomiotta ja allekirjoittaa sertifikaatit itse, sinun on käsiteltävä varmenteen peruuttamista. Asiakassertifikaateilla on myös samat turvallisuus- ja mukavuusongelmat kuin salasananhallinnoilla, kun käyttäjät haluavat kirjautua sisään epäluotettavalla tietokoneella. heidän on siirrettävä varmenteensa epäluotettavaan tietokoneeseen, mikä on sekä hankalaa että altistaa päätietunnuksensa haittaohjelmille kyseisessä tietokoneessa.

Lyhyesti sanottuna, kunnes joku keksii paremman, käyttäjäystävällisen ratkaisun käyttämällä asiakassertifikaatit, jotka ratkaisevat (ainakin suurimman osan) näistä ongelmista, en usko, että asiakassertifikaatit ovat vakava kilpailija SQRL: lle (tai siinä tapauksessa salasanoille).

2-tekijäinen todennus

Ajattelin vain mainita tämän: SQRL ja 2-tekijäinen todennus eivät sulje pois toisiaan. SQRL korvaa ensimmäisen tekijän 2FA: ssa: salasanat. Muita lisätoimenpiteitä, kuten OTP-koodeja tai FIDO U2F -avaimia, voidaan silti käyttää SQRL: n kanssa.

WebAuthn

Nyt täällä ”s missä asiat kiinnostavat. WebAuthn on uusi (hyvin, uudempi kuin SQRL) W3C-standardi, joka on suunniteltu tarjoamaan tavallinen sovellusliittymä, jonka verkkosivustot voivat käyttää käyttäjien todentamiseen julkisilla avaimilla verkossa. Aivan kuten SQRL, se tukee käyttäjän puhelimen käyttämistä kirjautumisistunnon todentamiseen ulkoisella laitteella muutamien muiden todennustapojen (kuten toisen tekijän suojausavaimet) lisäksi .

Tällöin SQRL saavuttaa viimeinkin ottelunsa, ainakin turvallisuuden näkökulmasta. Paitsi että WebAuthn tarjoaa kaikki samat suojaukset salasanan uudelleenkäyttöä, heikkoja salasanoja ja näppäinlukitusta vastaan kuin SQRL, se tarjoaa myös entistä vahvemman suojan tietojenkalastelua vastaan integroimalla käyttäjän selaimeen edes sisäänkirjautumisen valtuutuksessa istunto PC: lle, käyttäjä ei ole aiemmin asentanut todennuksen asiakasohjelmistoa. Tämä on mahdollista, koska siinä tilanteessa WebAuthn kommunikoi käyttäjän selaimen kanssa suoraan käyttämällä kaksisuuntaisia tiedonsiirtoprotokollia, kuten Blutooth tai NFC, sen sijaan, että kommunikoisi käyttäjän käyttämän verkkosivuston kanssa yksisuuntaisen QR-koodin kautta.

Käytettävyyden näkökulmasta asiat ovat hieman monimutkaisempia. Ainakin pinnalta WebAuthn voittaa jälleen. Koska se on W3C-standardi, jota on jo toteutettu useissa selaimissa , teoriassa käyttäjät voivat heti aloittaa WebAuthnin käytön tarvitsematta asentaa kolmannen osapuolen ohjelmistoja.Käytännössä kuitenkin useimmat olemassa olevat WebAuthn-toteutukset keskittyvät sen käyttöön toisen tekijän todennuksen muodossa tai tapana todentaa käyttäjä uudelleen. jotka ovat aiemmin kirjautuneet sisään samalla laitteella eri kirjautumistavalla (yleensä salasanalla). Ensisijaisena todennustekijänä WebAuthnista puuttuu edelleen melko toteuttamiskelpoisia toteutuksia.

Muita vähäisiä näkökohtia ovat se, että SQRL on rakennus t-in-menetelmä tilien avainten kiertämiseksi varastetun pääavaimen tapauksessa, kun taas WebAuthn luottaa verkkosivustoihin omien järjestelmiensä toteuttamiseksi avainten peruuttamiseksi ja siitä, että WebAuthn vaatii tiettyjä valinnaisia laitteita (kuten Bluetooth tai NFC) järjestyksen saamiseksi todentamaan etälaitteelle, kun taas SQRL voi toimia kaikilla koneilla, joilla on toimiva näyttö.

Kaiken kaikkiaan mielestäni on erittäin todennäköistä, että WebAuthn tekee SQRL: stä vanhentuneen. SQRL: llä voi olla vielä vähän hengitystilaa, mutta WebAuthnilla on paljon vahvempi tuki selaintoimittajilta, sivusto-operaattoreilta ja muilta kolmansien osapuolten organisaatioilta (kuten W3C). Kun WebAuthn saa pari toteutusta, jotka mahdollistavat sen käytön ensisijaisena todennustekijänä, uskon, että se alkaa ottaa verkon haltuunsa hyvin nopeasti.

Varoitukset

SQRL on edelleen aktiivisessa kehityksessä, joten tässä vastauksessa esitetty aineisto voi muuttua. Kehityksen jatkuessa odotan, että osa tämän vastauksen haavoittuvuuksista ja epävarmuustekijöistä korjataan. Suurin osa keskustelusta käydään tällä hetkellä SQRL-uutisryhmässä osoitteessa grc.com.

SQRL on kätevä ratkaisu käyttäjänimen ongelmaan / salasanan paradoksi. (eli mukavuus- / tietoturvakaari) ilman kolmannen osapuolen käyttöä . Se tarjoaa yksinkertaisen vaihtoehdon suosituimmalle todennusmallille (käyttäjätunnus & salasana), käytännössä tinkimättä tietoturvasta. Se on käytännössä yhtä turvallinen kaikista nykyisin käytetyistä tavallisista todennusmalleista, , kunhan olet edelleen tietoturvatietoinen . Jos käytät SQRL: ää, se ei tarkoita sitä, ettet voi noudattaa parhaita tietoturvakäytäntöjä, kuten , yhdistämällä tämä monitekijän todennukseen tärkeille tileille.

On tärkeää, että et menetä SQRL: n pistettä. SQRL itsessään ei välttämättä tarjoa parempaa tai huonompaa turvallisuutta. Jos tietokone / puhelin itse vaarantuu tai käyttäjä huijataan tietojenkalastelu, tämä on sivukanavan hyökkäys SQRL: n suoran vian sijaan. Jokaisessa tavanomaisessa todennusmenetelmässä on tämä sivukanavan hyökkäysten ongelma Murtumaton kertaluontoinen pad on myös altis sivukanavan hyökkäyksille kuten itse tyynyn kompromissi tai huono ympäröivä suojaus tai toteutukset.

Jos kuuntelit idean alkuperäistä ehdotusta Steve Gibson ”s podcast , jota seuraa Q & A ”, monet tähän pinoketjuun liittyvistä huolenaiheista on vastattu. Lisäksi Steve sanoi itse, että turvallisuusasiantuntijoiden olisi ”tarkastettava” ja ”kiinnitettävä” tämä hyvin ”yksinkertainen” ja ”nerokas” (hänen sanoinsa) ajatus, koska vain aika näyttää, onko tämä turvallinen ratkaisu.

Yhteenvetona voidaan todeta, että suurin osa SQRL: ää vastaan esitetyistä argumenteista jää itse SQRL: n toimialueen ulkopuolelle ja on sen sijaan ongelmia ihmisten kanssa, jotka harjoittavat huonoa turvallisuutta. SQRL ei ota käyttöön uutta luokittelua ongelmista, joita perinteisillä todennusmenetelmillämme ei jo ole.

SQRL on erinomainen, jos sitä käyttävät asianmukaisesti ihmiset, jotka ovat tietoisia turvallisuudesta. Sinun on ymmärrettävä, että mukavuuden ja turvallisuuden välillä on aina kompromissi , ja tämä ratkaisu on todennäköisesti paras tasapaino näkemistäni kahdesta.

Kommentit

• Kiitos Ansichart. Mutta voivatko ’ t olemassa olevat todennusratkaisut säilyttää yksinkertaisesti samanlaiset tai ylivertaiset turvaominaisuudet kuin SQRL ja käyttää sitten automaatiota käyttäjien mukavuuden parantamiseen? Mikä SQRL ’ -käyttömukavuuden perusominaisuus ei johdu automaatiosta? Kysyn, koska jos käyttäjällä on kaksi mustaa laatikkoa, jotka tekevät saman asian; yksi merkitty ” Aikuinen ” ja toinen nimetty ” SQRL ” ja molemmat voidaan suunnitella / automatisoida, niillä on sama käyttöliittymä / painikkeet laatikon ulkopuolella – mitä lisäarvoa SQRL tarjoaa?
• Se ratkaisee salasanaparadoksin ongelman tarvitsematta käyttää kolmatta osapuolta.
• Ymmärrän. Joten jos joku ei ’ ei halua kolmannen osapuolen kertakirjautumisriskiä ja voitti ’ t, luo / tallenna salasanojaan salasananhallinta, SQRL voi tehostaa. Mutta jos SQRL on mobiili musta laatikko, joka pyytää salasanaa pääavaimen lukituksen avaamiseksi, jota käytetään SQRLID-tiedostojen uudistamiseen / tallentamiseen, ja suorittaa sitten asiakkaan ’ -evästeen / QR-linkityksen takaisin kanavalla session_id with server ’ kirjaa SQRLID-tunnuksen sisäänkirjautumiseen – miten tämä on erilainen matkapuhelimen musta laatikko matkapuhelimen salasanahallinnasta, jolla on automaattinen sisäänkirjautuminen saman takakanavan kautta; vai kahden osapuolen mobiiliasiakkaiden varoituslaajennus, jossa on automaattinen sukupolven & sisäänkirjautuminen saman takakanavan kautta?
• Olen muokannut alkuperäistä viestiäni muutaman toisen harkinnan ja tarkemman lukemisen jälkeen toisten sanoihin, koska olen ehkä hypistänyt sen. Oletan, että matkapuhelimen olevan keskeinen avain siirtää ongelman ja tekisi tärkeämmäksi puhelimesi paremman turvallisuuden. Steve Gibson tuo tämän esille myös Q & A-podcastissa.

SQRL ei tarjoa uraauurtavia parannuksia. QR-koodit ovat optinen viivakoodimuoto, joka on hyödyllinen lyhyelle sisällönjakelulle – ei muuta.

Kaikki automaattisen sisäänkirjautumisen tilanteet, joita SQRL yrittää ratkaista, voivat käyttää yksinkertaisesti matkapuhelimeen tallennettuja asiakassertifikaatteja.

Hypoteettisesti HTTPS-sivun QR-viivakoodi voisi palauttaa palvelimen allekirjoittaman tai salatun version asiakassertifikaatista (tai vastaavasta tunnistetiedosta), kuten palvelin on aiemmin tuntenut, mutta miksi? Tunnisteiden vanhentumiselle? Sivusto voi yksinkertaisesti hylätä vanhentuneet kirjautumistiedot suoraan.

Joten suurin turvallisuusongelma protokolla on: Neliön pyörän keksiminen uudelleen .

Update

Lukemalla uusia vastauksia ja kommentteja haluaisin huomauttaa, kuinka helppoa on tehdä jotain samanlaista kuin SQRL yksinkertainen kypsän olemassa olevan tekniikan automatisointi:

1. Verkkosivusto pyytää CAPTCHA: ta tai vastaavaa ”I” ihminen ”-tarkistusta. Kun käyttäjä on noudattanut (POSTed) -toimintoa, verkkosivusto palauttaa HTTP 403.7 - Client Certificate Required – tai vanilja 403 -virheen.
2. Mukautetut 403 sivua on tarpeeksi helppo asentaa , ja ne voivat olla melko kauniita ja käyttäjäystävällisiä. Voisi jopa käynnistää alla vaaditut toiminnot samalla tavalla kuin ”Adobe Reader vaaditaan” -kehotteet monilla verkkosivustoilla.
3. Mukautettu 403 -sivu sisältää joitain merkintöjä, joihin mukautettu selainlaajennus reagoi. Kutsutaan tätä mukautettua laajennusta ”S403L-yhteensopivaksi” ”SQRL-yhteensopivuuden” hengessä.
4. S403L-laajennus luo tavallisen asiakassertifikaatin, joka on suojattu tavallisessa salatussa selaimen varmennevälimuistissa (tai kolmannessa osapuolen välimuisti, jos selaimesi avainsäilön salaus on imeytynyt). Laajennus luo tavallisen CSR: n asiakassertifikaatille ja lähettää CSR: n 403-merkinnässä määritettyyn URL-osoitteeseen (esim. <s403l ref="https://www.example.com/S403L" />)
5. S403L-yhteensopiva palvelin käyttää käyttäjän session_id-tunnusta (haettu evästeistä tai kyselymerkkijonosta) jatkuvuuden luomiseksi vaiheessa 1 ja palauttaa sitten CSR: n palvelimen allekirjoittamana. Palvelimen yleinen todennus hyväksyy kaikki palvelimen allekirjoittamat asiakassertifikaatit (ja täyttävät siten vaiheessa 1 vaaditut rekisteröintikriteerit).
6. S403L-laajennus tallentaa asiakassertifikaatin allekirjoittaneen selaimen välimuistiin. sitten tavallinen selain ilman laajennusapua voi ”kirjautua sisään” automaattisesti palvelimeen tavallisella SSL / TLS-tavalla, kunnes varmenne vanhenee.

”Mobiili” ja ”Visuaalinen” luonne of SQRL on jotain väärää suuntausta, koska se ei tarjoa irrotettua kaksivaiheista todennusta ja tarvitset nyt kaksi tietokonetta Internetin selaamiseen yhden sijasta. Ellet osoita työpöydän USB-verkkokameraa omaan näyttöön.

Salasanojen ja varmenteiden väliset kompromissit on määritelty turvallisuusyhteisössä: Salasanat sopivat ihmisen aivoihin; varmenteet eivät sovi ihmisen aivot ( yleensä ), mutta niillä voi olla hullu entropia ja hyvät PKI-hallintaominaisuudet (vanhentuminen , peruuttaminen, käytäntöjen laajentaminen jne.). SQRL sopii puhtaasti kumpaankaan leiriin; ja jos se ajautuu kohti vähemmän inhimillistä enemmän tietokoneita sisältävää leiriä kuin näyttää – sillä on vuosien kehitys- ja turvallisuusanalyysi toistamaan nykyiset X.509-ominaisuudet.

Kommentit

• > voisi käyttää yksinkertaisesti matkapuhelimeen tallennettua asiakasvarmentetta.— paitsi että tätä tekniikkaa on olemassa vuosien ajan sekä mobiililaitteilla että tietokoneilla, ja se ’ ei ole niin laajalle levinnyttä kuin haluaisi. Ja päinvastoin kuin asiakassertifikaatti, SQRL ei vaadi sinua ’ t edellyttämään todistamaan todellisen henkilöllisyytesi luomaan ” SQRL-identiteetti ”. Halutessasi voit luoda niin monta identiteettiä kuin haluat. Tämä tarkoittaa sitä, että etu verrattuna asiakassertifikaatteihin on, että sinulla on nimettömyys auth-protokollan ’ puolelta.
• @jpkrohling On yleinen väärinkäsitys, että asiakasvarmenteet vaatia henkilöllisyyden paljastamista käytettäväksi. Tämä on kaupallisten allekirjoittajien vaatimus käyttää maailmanlaajuisesti vaihdettavissa olevia luottoketjuja. Käytännössä asiakassertifikaatti voi olla yksinkertaisesti asiakkaan luoma ja tietyn palvelimen allekirjoittama tuntematon CSR saavutettuaan haluamasi ehdot (CAPTCHAs, edellinen tili, jne). Varmenteilla voi olla myös sisäänrakennettu vanhentumisaika. Type 40-L QR-viivakoodit voivat lähettää / tallentaa 1 kt X.509 -asiakassertifikaatin haluttaessa.
• Ok, totta, huono. Tästä näkökulmasta asiakas (esimerkiksi mobiilisovellus) voisi luoda asiakasvaroituksen jokaiselle verkkosivustolle, jota käyttäjä rekisteröi. Tämä kuulostaa kalliimmalta kuin joidenkin tietojen hajauttaminen, mutta voi olla mielenkiintoinen ratkaisu. Joka tapauksessa en edelleenkään ole ’ samaa mieltä väitteistänne, että SQRL on huonompi kuin hyödytön.
• Olin ehkä ankara sanamuodossa ja poistan sen. Mutta en näe ’ SQRL: ää kuin muuta seksikkäintä tapaa jakaa neuvoteltuja asiakastietoja; ja sellainen, joka ei ole ’ ratkaissut joitain hienovaraisia ongelmia, joita kypsät todennusmenetelmät käsittelevät. Salasanojen hallinta on työläs (en vaivaudu selaimen integrointiin, koska olen ’ ma paranoiakka), mutta tiedän, että vain minä ja yksi verkkosivusto jakaa kukin yhden laukauksen salasana salatussa avaimen myymälässä. Minun ’ ei tarvitse huolehtia hienoista uusista hash / auth-järjestelmistä, vain PRNG / TRNG: n laadusta, jota salasananhallintaohjelma käyttää salasanojen luomiseen.
• @LateralFractal kuka välittää ’ uudesta vai ei? SQRL sallii käyttäjäystävällisen todennuksen, jos ensimmäinen osapuoli ei paljasta salaisuuttaan toisen osapuolen tai kolmannen osapuolen kanssa, joka on saattanut vaarantaa toisen osapuolen ’ turvallisuuden. Se ’ yrittää ratkaista todellisen maailman ongelman, jota kukaan muu ei ole toistaiseksi pystynyt ratkaisemaan.

Haluan käsitellä ensimmäistä kysymystä: ”Yksi ongelmista, jotka voin ajatella, on se, että QR-lukija vaarantuu, jotta näytetään www.google.com www.nsa-super-secret-place.gov/123 ”: sijasta:

Pääavainta käytetään HMAC: n siemenenä yhdessä verkkosivuston osoitteen (FQDN) kanssa. Joten vaikka QR-koodi saattaa koodata täysin eri URL-osoitteen, protokolla EI paljasta todennuskoodia, joka normaalisti lähetetään osoitteeseen www.google.com (esimerkissä).

Toiseksi monet kirjoittajat unohtavat tärkeimmät tavoitteet ajatusta tehdessään:

1. nimettömyys olematta käyttämättä kolmatta osapuolta
2. helppokäyttöisyys
3. ei tarvitse kirjoittaa salaisia tunnistetietoja epäluotettaviin tietokoneisiin

Uskon, että protokollat vastaavat niihin kokonaan!

On kuitenkin olemassa kompromisseja, jotka todella tulevat ensimmäisestä esineestä. Jos kukaan kolmas osapuoli ei ole mukana todennuksessa, miten kukaan voi peruuttaa todennustietonsa? Lisäksi pääavaimen turvallisuus on ilmeinen huolenaihe. Uskon tämän olevan hyvin suojattu tulevilla mobiililaitteilla HSM: n kaltaisessa sirussa. Siihen asti avain on vain tiedostopääteinen mobiililaite, suojattu salasanalla, vaikka PBDKF2 varmistaa, että sen todellinen pakottaminen on hyvin hidasta.

Kommentit

• Mitä ’ uutta tässä ajatuksessa on? Minusta näyttää olevan primitiivinen muunnelma nyt lakkautetusta Windows CardSpacesta.
• Kyllä, olet oikeassa CardSpacessa. Sitten on U-Prove, jonka myös omistaa Microsoft. Kysymys on, kuinka käytät CardSpace- tai U-Prove-tietokonetta tietokoneeseen, johon et luota (Internet-kahvila tai ystävien tietokone). Sitä Steve lisäsi.
• Ah, ok, että ’ puuttui. Olen edelleen @TerryChia kanssa samaa mieltä siitä, että tämä ei ole käynnistysohjelma ilman käyttäjän avainten peruutusmekanismia.
• @Xander Siellä on käyttäjäavainten peruutusmekanismi. grc.com/sqrl/idlock.htm