Ca de obicei, luați orice este legat de Steve Gibson cu un camion de sare. Obligatory attrition.org link .

Să aruncăm o privire asupra descrierii lui Gibson a protocolului său.

• Codul QR prezentat lângă datele de conectare promptul conține adresa URL a serviciului de autentificare pentru site. Adresa URL include un număr aleatoriu generat în siguranță, astfel încât fiecare prezentare a paginii de conectare să afișeze un cod QR diferit. (În cercurile criptografice, acest număr lung aleatoriu este cunoscut sub numele de „nonce”.)

• Aplicația de autentificare SQRL a smartphone-ului criptografic nume de domeniu al site-ului tastat de utilizator cheia principală pentru a produce o pereche de chei publice specifice site-ului.

• Aplicația semnează criptografic întreaga adresă URL conținută în codul QR utilizând cheia privată specifică site-ului. Deoarece adresa URL include un număr sigur și lung aleatoriu (nonce), semnătura este unică pentru acel site și codul QR.

• Aplicația emite o interogare securizată HTTPS POST către QR URL-ul codului, care este serviciul de autentificare pentru site. POST oferă cheia publică specifică site-ului și semnătura criptografică potrivită a adresei URL a codului QR.

• Site-ul web de autentificare primește și confirmă interogarea POST prin returnarea unui HTTP „200 OK” standard fără alt conținut. Aplicația SQRL recunoaște trimiterea cu succes a codului QR semnat de utilizator.

• Site-ul de autentificare are adresa URL care conține nonce-ul care a revenit de pe pagina de autentificare prin intermediul utilizatorului De asemenea, are o semnătură criptografică a acelei adrese URL și cheia publică specifică site-ului utilizatorului. Folosește cheia publică pentru a verifica dacă semnătura este validă pentru adresa URL. Aceasta confirmă faptul că utilizatorul care a produs semnătura a folosit cheia privată corespunzătoare cheii publice. După verificarea semnăturii, site-ul de autentificare recunoaște utilizatorul acum autentificat prin cheia sa publică specifică site-ului.

cel mai mare lucru care mă privește este utilizarea unei ” cheie principală ” de către utilizator. Dacă citesc corect protocolul, acea cheie master controlează întreaga identitate online a utilizatorului …

Probabil, această cheie master este stocată în telefonul utilizatorului într-o bază de date a aplicației. Ceea ce deschide un vector de atac imens, sub formă de malware conceput special pentru a fura cheia master.

Deci, să comparăm diferența dintre ceea ce se întâmplă atunci când o parolă este compromisă și ceea ce se întâmplă atunci când cheia master Presupunând că urmați bune practici de parolă pentru parole lungi, unice și extrem de aleatorii stocate într-un manager de parole, tot ce trebuie să faceți este să schimbați o singură parolă dacă este compromisă. Ce se întâmplă dacă cheia dvs. master este compromisă? va trebui să obțină cumva toate site-urile cu care v-ați autentificat pentru a recunoaște că cheia dvs. master a fost compromisă. Singura problemă este, deoarece nu aveți alte mijloace de autentificare cu site-ul, cum ar fi numele de utilizator sau adrese de e-mail, de unde va ști site-ul că de fapt dvs. încercați să revocați cheia principală?

La fel ca orice lucru care iese din Gibson, această schemă SRQL este foarte defectă și nu oferă avantaje față de cele convenționale metode.

Comme nts

• ” Dacă ‘ urmăriți bune practici de parolă ” este o avertizare imensă, iar majoritatea internauților nu o fac ‘.O parte din promisiunea SQRL ‘ este de a reduce utilizatorii ‘ care trebuie să rămână la curent cu cele mai bune practici. Mai mult, specificația SQRL va solicita ca cheia master să fie stocată criptată cu o parolă master și va fi imposibil de forțat brut (reglată pentru a dura ~ 60s pentru o singură încercare). Obținerea parolei va fi adesea non-banală, deoarece SQRL promovează autentificarea în afara benzii (de exemplu, înregistrarea prin tastare a unei mașini pirate ‘ nu vă va ajuta întotdeauna). Deci, în timp ce consecințele compromisului complet sunt mari, probabilitatea compromisului este oarecum redusă.
• SQRL poate avea încă defecte care necesită soluționare, dar susține că rezolvă o serie de probleme găsite în abordările existente de autentificare și orice critică a SQRL care o afirmă ” nu oferă beneficii ar trebui să includă respingeri ale acestor revendicări în loc să se aștepte ca afirmația să fie acceptată orbește.
• > Ca orice iese din Gibson , această schemă SRQL este foarte defectuoasă și nu oferă beneficii față de metodele convenționale. — Acest lucru nu ‘ pare să ajute la răspunsul la întrebare și, de fapt, simt că aveți probleme cu tehnologia din cauza cine a venit cu ea. Unele dintre punctele pe care le-ați menționat ca defecte sunt de fapt abordate de ” spec „. De exemplu, SQRL în sine nu ‘ nu menționează modul în care este stocată cheia principală, dar comentariile lui Steve Gibson ‘ sunt că un telefon mobil clientul, de exemplu, l-ar cripta cu o parolă master folosind un scrypt care durează în medie 60 de ani pentru a fi executat.
• Gibson explicitate abordează protecția cheii master.
• Țineți apăsat un al doilea. Echivalați cheia principală SQRL furată cu una dintre cheile LastPass furate. ‘ nu ar fi o analogie mai bună să o echivalăm cu întreaga dvs. bază de date de parole LastPass decriptată fiind furată?

În general, protocolul nu pare să crească securitatea față de tehnologia existentă. Dacă căutați cel mai bun mod de a vă proteja identitatea online, aceasta este fără îndoială nu . Dar să analizăm avantajele și dezavantajele:

Avantaje

Este imposibil să ” să împărtășim ” o parolă în sensul restrâns că un site web rău intenționat nu poate folosi autentificarea furnizată unui site pentru a vă conecta la alt site.

Un atac cu forță brută împotriva simbolului de autentificare este nu este fezabil.

Acreditările nu sunt stocate pe computerul dvs. Acest lucru vă protejează împotriva unui subset mic de atacuri direcționate către stația de lucru. Mai exact, sunteți protejat împotriva atacurilor care vă fură parola de pe computer. Sunteți nu protejat împotriva oricărui tip de sesiune de deturnare sau atacuri de preluare a browserului, dar acum sunteți și susceptibil la atacuri legate de telefon. Mai multe despre asta mai târziu.

Dezavantaje

Această tehnică este periculoasă susceptibilă la atacuri MITM și inginerie socială. Probabil mai mult decât orice altă schemă de autentificare utilizată, inclusiv parole. Pasul de autentificare și pasul de inițiere a conectării sunt inerent deconectate în sensul că telefonul se va autentifica corect împotriva oricărui cod QR prezentat, indiferent de modul sau locul în care acesta este prezentat utilizatorului.

Deci, de exemplu, un site de phishing poate afișa un cod QR autentic de autentificare care conectează atacatorul în locul utilizatorului. Gibson este încrezător că utilizatorii vor vedea numele băncii sau magazinului sau site-ului în aplicația telefonică în timpul autentificării și, prin urmare, vor exercita suficientă vigilență pentru a contracara atacurile. Istoria sugerează acest lucru puțin probabil, iar așteptarea mai rezonabilă este că vizualizarea numelui corect în aplicație îl va reasigura în mod fals pe utilizator să creadă că site-ul este legitim, deoarece a putut declanșa solicitarea de conectare familiară pe telefon. Precauția deja bătută în capul utilizatorilor cu privire la securitatea parolei nu se traduce neapărat prin noi tehnici de autentificare precum aceasta, ceea ce face ca această aplicație să fie în mod inerent mai puțin rezistentă la ingineria socială. „a9ad2fb1fb”>

SQRL cu siguranță nu este lipsit de defecte, dar este „cu siguranță superior celor mai multe soluții de autentificare primare utilizate pe scară largă pe web astăzi în ceea ce privește securitatea și (și acest lucru este important) utilizabilitatea. >

Concepții greșite

Mai întâi, permiteți-mi să clarific câteva dintre concepțiile greșite prezente în unele dintre celelalte răspunsuri la această întrebare. Multe dintre aceste răspunsuri sunt învechite și au fost scrise înainte de modificări la documentația SQRL care abordează problemele prezentate în acestea, în timp ce altele par să pună un accent nejustificat pe defectele din SQRL, care sunt prezente și în multe alte soluții de autentificare existente pe scară largă, ignorând în același timp beneficiile sale. Deci, să clarificăm câteva concepții greșite aici, noi?

Mit: SQRL necesită scanarea codurilor QR pentru a funcționa

Acest lucru pur și simplu nu este adevărat. Codurile QR sunt o comoditate ceea ce face SQRL mai ușor de utilizat pe computerele pe care utilizatorul nu a configurat software-ul client SQRL. Site-ul web al SQRL prevede următoarele:

Three Ways to Go…smartphone opțional:

Deși inspirația inițială pentru dezvoltarea acestui sistem a fost un smartphone care scanează un cod QR pe pagina de conectare a unui site web, o mică adăugare la acel model permite două moduri de operare mai semnificative: Pur și simplu faceți din imaginea codului QR un link care poate fi făcut clic pe aceeași adresă URL care este codificată în codul QR. Acest lucru oferă trei moduri de conectare:

• Scanați codul cu un smartphone: Utilizând model descris mai sus, smartphone-ul unui utilizator scanează codul QR care apare pe pagina de conectare a unui site web și utilizatorul este conectat la acel site.
• TAP CODUL de pe un smartphone: Pentru a vă conecta la un site web pe smartphone, atunci când codul vizual SQRL este, de asemenea, un link în stil URL (folosind sqrl: // ca schemă) Aplicația SQRL instalată pe smartphone va primi acel link și va conecta în siguranță utilizatorul la site-ul de pe telefon.
• Faceți clic pe cod pe ecranul unui desktop sau laptop : Pentru a utiliza sistemul SQRL pe orice sistem desktop sau laptop, o aplicație desktop SQRL ar fi instalată și s-ar înregistra singură pentru a primi link-uri sqrl: //. (Acest lucru este similar cu modul în care un program de e-mail se înregistrează pentru a primi mailto: linkuri.) Acest lucru permite aceeași soluție să fie utilizată de utilizatori pe desktop-ul lor pe care o folosesc pe smartphone-urile lor. Când un site web oferă un cod SQRL, utilizatorul face doar clic pe cod cu cursorul mouse-ului și aplicația SQRL instalată local va apărea, va solicita parola SQRL, va confirma domeniul și apoi le va conecta.

Mit: Cheia principală SQRL este stocată complet necriptată și neprotejată pe telefonul dvs.

Nu sunt sigur de ce unele persoane au făcut acest lucru presupunere, deoarece mi se pare evident că acest lucru nu ar fi cazul. Cheia principală SQRL este protejată în același mod în care ați proteja o bază de date cu parole: cu o parolă master puternică. Furtul unui telefon al utilizatorului nu vă va oferi automat acces la identitatea lor online, cu excepția cazului în care aveți și parola principală. Mai multe detalii despre gestionarea cheilor sunt explicate în pagina de pe SQRL Client- Gestionarea cheii laterale pe site-ul web al SQRL.

Mit: Dacă cheia dvs. principală este furată, nu vă puteți schimba datele de conectare

Acest lucru este, de asemenea, fals. SQRL oferă un mod încorporat pentru a permite titularului de cont autentic să își actualizeze acreditările de conectare în cazul unei chei compromise. Această caracteristică este cunoscută sub numele de Blocare identitate:

„Identity Lock” previne schimbarea identității & permite recuperarea: Acesta este de asemenea, suficient de semnificativ pentru a merita propria sa pagină de descriere detaliată: „ Protocolul de blocare a identității ” (pagina 4 în blocul de linkuri din partea de jos a acestei pagini.) Odată ce identitatea utilizatorului a fost stabilită cu un server web, SQRL c lient este în imposibilitatea de a schimba identitatea respectivă. Aceasta înseamnă că, dacă s-a întâmplat cel mai rău și a fost utilizată o parolă foarte slabă și ușor de ghicit, sau telefonul sau desktopul unui utilizator au fost sparte pentru a obține cheia principală de identitate și parola, nicio terță parte rău intenționată nu poate modifica identitatea online a utilizatorului pentru a-i bloca din propriile conturi online. Și, mai mult, încărcând apoi o „cheie de deblocare a identității” în mod normal offline, adevăratul proprietar al identității lor poate să se retragă și să-și înlocuiască identitatea online pierdută sau furată pentru a-l prelua în esență de la orice atacator, făcând inutilă identitatea lor anterioară.

Plauzibil: SQRL este mai vulnerabil la phishing decât soluții de autentificare existente

Bine, deci acest lucru este de fapt parțial adevărat. Atunci când utilizați SQRL prin scanarea unui cod QR, există într-adevăr foarte puțină protecție împotriva phishingului. Cu excepția cazului în care utilizatorul are grijă să se asigure că site-ul web afișat în bara URL a browserului său este același cu cel afișat de aplicația SQRL Client, ar putea autoriza o sesiune de conectare pentru atacator. Acest lucru este încă mai bun decât parolele, unde ar oferi phisherului acces permanent la contul lor (și la orice alte conturi pe care le au în altă parte, care au aceeași parolă) până când își schimbă parola, dar nu la fel de bune ca alte soluții care se integrează cu browserul utilizatorului, cum ar fi tastele U2F , WebAuthn, certificate de clienți și (în anumite condiții) manageri de parole.

Cu toate acestea, atunci când „utilizați un client SQRL pe același dispozitiv cu care vă conectați, SQRL are anumite protecții împotriva phishing în loc. Aceste protecții sunt explicate pe site-ul web al SQRL, în secțiunea despre Cum SQRL poate contracara atacurile de phishing .Există, de asemenea, posibilitatea de a integra SQRL cu browsere (posibil prin intermediul pluginurilor) pentru a oferi o protecție mult mai puternică împotriva atacurilor de phishing; în același timp cu soluții precum WebAuthn și certificate de client.

În general, aș clasa SQRL pe cam la același nivel cu administratorii de parole pentru protecția împotriva phishingului. Are potențialul de a oferi o protecție puternică împotriva phishingului atunci când este instalat pe același dispozitiv pe care utilizatorul se conectează, dar oferă o protecție minimă atunci când este instalat pe un alt dispozitiv.

Compararea cu alternativele

Acum, să comparăm SQRL cu soluțiile de autentificare existente pe scară largă.

Parole

SQRL este mult superioară parolelor în multe feluri. Nu numai că este mai convenabil de utilizat odată setat sus, deoarece utilizatorii nu trebuie să vă faceți griji cu privire la amintirea sau retiparea mai multor parole diferite pentru fiecare site, dar protejează și împotriva reutilizării parolelor, parolelor slabe, keylogging și, într-o oarecare măsură, phishing-ului.

Dezavantaje SQRL în comparație cu parolele este că este mai dificil de implementat pentru operatorii de site-uri web, nu la fel de utilizat pe scară largă, necesită mai mult timp pentru a configura inițial, necesită un efort pentru a transfera pe un dispozitiv nou și oferă un singur punct de eșec pentru toate conturile utilizatorului dacă cheia principală este furată (deși acest ultim punct t este, de asemenea, cazul parolelor dacă un utilizator folosește aceeași parolă pe fiecare site).

Password Managers

În multe moduri, SQRL este foarte asemănător cu managerii de parole. Ambele oferă o singură ancoră de încredere centralizată care servește ca un fel de proxy de autentificare între utilizatori și servicii individuale. Există, totuși, câteva moduri în care SQRL este superior managerilor de parole.

Principalul avantaj pe care cred că SQRL îl are asupra managerilor de parole este că este mai ușor și mai sigur de utilizat pe computere de încredere sau doar parțial de încredere. De exemplu, să spunem că un utilizator dorește să se conecteze la un site web utilizând un computer într-o bibliotecă publică. Cu un manager de parole, el ar trebui fie să acceseze parola pentru site-ul respectiv de pe telefonul său și să o tastați din nou manual în computer, fie să o descarce managerul de parole și baza de date de parole pe computerul bibliotecii, deblocați baza de date folosind parola sa principală, apoi conectați-vă. Primul scenariu este incomod pentru utilizator și expune parola în clar text a utilizatorului pentru acel site către computerul care nu are încredere (și orice malware de pe computerul de încredere, inclusiv keylogger-urile). Al doilea scenariu este și mai rău, deoarece este atât incomod și expune întreaga bază de date de parole decriptată a utilizatorului și parola principală către computerul care nu are încredere. Cu SQRL, utilizatorul ar trebui să scaneze un cod QR pe ecranul computerului care nu este de încredere, ceea ce este mult mai convenabil pentru utilizator și expune doar o singură sesiune de conectare (fără acreditări reutilizabile, cum ar fi o parolă), pe computerul de încredere .

Un alt avantaj pe care îl are SQRL față de managerii de parole este că este mai ușor să vă recuperați din cel mai rău scenariu: baza de date de parole / cheia principală a utilizatorului fiind furată. Cu un manager de parole, nu trebuie doar să vă schimbați parola pe fiecare site, ar trebui să vă faceți griji și dacă atacatorul vă va schimba parolele (posibil să vă blocheze contul). Atacatorul are și avantajul de a deține o listă cu toate site-urile pe care le aveți. cont activat, ceea ce face exploatarea furtului unei baze de date cu parolă mult mai ușoară. Cu SQRL, să-ți fie furată cheia principală este încă o situație teribilă, dar atacatorul nu are nicio listă de site-uri pe care ai un cont (trebuie să ghicești în schimb) ) și nu vă poate schimba parola pentru a vă bloca din contul dvs. Odată ce ați încărcat cheia de deblocare a identității, este, de asemenea, puțin mai convenabil să vă modificați acreditările de conectare pe fiecare site, deoarece clientul SQRL are capacitatea de a face acest lucru automat pentru dvs. pentru fiecare site pe care îl vizitați la conectare. (Nu este nevoie să mergeți prin orice formulare de „schimbare parolă”.)

În sfârșit, cred că SQRL are un mic, dar important avantaj față de administratorii de parole în ceea ce privește obiectivul său de a înlocui parolele în totalitate, și anume că site-urile au opțiunea de a aplica utilizarea SQRL peste parolele tradiționale. Atâta timp cât utilizatorii au încă opțiunea de securitate slabă, reutilizarea aceleiași parole pe fiecare site, este ceva ce se va întâmpla în continuare. Dacă SQRL începe să fie adoptată pe scară largă, site-urile pot începe într-adevăr să renunțe la utilizarea de parole. Asta nu se poate face cu administratorii de parole, deoarece aceștia se bazează pe utilizarea parolelor pentru a funcționa.

În ceea ce privește dezavantajele, de fapt nu mă pot gândi la o situație în care SQRL ar fi neapărat mai rău decât managerii de parole în ceea ce privește Securitate. Principalul dezavantaj pe care îl are SQRL este că necesită asistență din partea operatorilor de site-uri web, în timp ce administratorii de parole nu necesită suport special de la serviciile existente. Aceasta înseamnă că puteți începe să utilizați administratorii de parole chiar acum, dar SQRL va trebui să aștepte până când site-urile o implementează înainte de a putea fi utilizată. Aceasta este o barieră semnificativă în calea adoptării.

Certificatele clientului

Avantajul principal pe care SQRL îl are față de certificatele clientului este unul de comoditate. Certificatele de client sunt în prezent complicate de configurat, dificil de transferat între computere și au probleme de confidențialitate atunci când același certificat este utilizat pe site-uri diferite. În timp ce teoretic am putea construi un sistem folosind certificate de clienți care ar rezolva aceste probleme, ar exista și problema unei integrări deficitare cu interfețele web și serverele web, care sunt probleme mai greu de rezolvat. Nu voi intra în prea multe detalii aici, deoarece există deja un articol excelent despre problemele de utilizare a certificatelor de clienți de pe browserauth.net.

În ceea ce privește securitatea, certificatele de clienți au dezavantajul de a necesita implicarea unei CA. Acest lucru este (potențial) scump și necesită încrederea în terța parte a CA. În plus, dacă alegeți să ignorați CA-urile și să vă autosemnați certificatele, aveți de-a face cu problema revocării certificatului. Certificatele de clienți au, de asemenea, aceleași probleme de securitate și comoditate ca și managerii de parole atunci când utilizatorii doresc să se conecteze pe un computer de încredere; trebuie să-și transfere certificatul pe computerul care nu este de încredere, ceea ce este atât incomod și poate expune identitatea lor principală malware-ului de pe acel computer.

Pe scurt, până când cineva vine cu o soluție mai bună, ușor de utilizat, certificate de client care rezolvă (cel puțin majoritatea) aceste probleme, nu cred că certificatele de client sunt un concurent serios pentru SQRL (sau, de altfel, pentru parole).

Autentificare cu 2 factori

Doar am crezut că aș menționa acest lucru: SQRL și autentificarea cu 2 factori sunt nu reciproc excluzivi. SQRL înlocuiește primul factor din 2FA: parolele. Alte măsuri suplimentare, cum ar fi codurile OTP sau tastele FIDO U2F, pot fi folosite în continuare cu SQRL.

WebAuthn

Acum aici „s unde lucrurile devin interesante. WebAuthn este un nou standard W3C (bine, mai recent decât SQRL) conceput pentru a oferi un API standard pe care site-urile web îl pot utiliza pentru autentificarea utilizatorilor cu chei publice pe web. La fel ca SQRL, acceptă folosind telefonul utilizatorului pentru a autentifica o sesiune de autentificare pe un dispozitiv extern , în plus față de alte câteva metode de autentificare (cum ar fi cheile de securitate cu factor 2) .

Aici SQRL își îndeplinește în cele din urmă potrivirea, cel puțin din perspectiva securității. Nu numai că WebAuthn oferă aceleași protecții împotriva reutilizării parolelor, parolelor slabe și keylogging-ului pe care le face SQRL, dar oferă și o protecție și mai puternică împotriva phishing-ului prin integrarea cu browserul utilizatorului chiar la autorizarea unei autentificări sesiune pentru un computer, utilizatorul nu a configurat anterior software-ul client al autentificatorului. Acest lucru este posibil, deoarece în această situație WebAuthn comunică direct cu browserul utilizatorului utilizând protocoale de comunicații bidirecționale precum Blutooth sau NFC, comunicând în schimb cu site-ul web pe care îl utilizează utilizatorul printr-un cod QR unidirecțional.

Din punct de vedere al utilizabilității, lucrurile sunt puțin mai complicate. Cel puțin la suprafață, WebAuthn câștigă din nou. Deoarece este un standard W3C care are deja implementări în mai multe browsere , în teorie, utilizatorii pot începe imediat să utilizeze WebAuthn fără a fi nevoie să instaleze niciun software terță parte. În practică, însă, majoritatea implementărilor WebAuthn existente se concentrează pe utilizarea acestuia ca o formă de autentificare a celui de-al doilea factor sau ca o modalitate de re-autentificare a unui utilizator care s-au conectat anterior pe același dispozitiv printr-o metodă de conectare diferită (de obicei o parolă). Ca factor principal de autentificare, WebAuthn încă nu are implementări viabile.

Alte considerații minore includ faptul că SQRL are un buil Metoda t-in pentru rotirea cheilor conturilor în cazul unei chei master furate, în timp ce WebAuthn se bazează pe site-urile web pentru a implementa propriul sistem de revocare a cheilor și faptul că WebAuthn necesită anumite hardware opțional (cum ar fi Bluetooth sau NFC) să vă autentificați la o mașină la distanță, în timp ce SQRL poate funcționa pe orice mașină cu un afișaj funcțional.

În general, cred că este foarte probabil ca WebAuthn să devină în cele din urmă SQRL învechit. SQRL poate avea un pic de spațiu de respirație pentru moment, dar WebAuthn are un sprijin mult mai puternic de la furnizorii de browsere, operatorii de site-uri și alte organizații terțe (cum ar fi W3C). Odată ce WebAuthn primește câteva implementări care să permită utilizarea acestuia ca factor principal de autentificare, mă aștept să înceapă să preia webul foarte repede.

Avertismente

SQRL este încă în curs de dezvoltare activă, deci materialul prezentat în acest răspuns poate fi modificat. Pe măsură ce dezvoltarea continuă, mă aștept ca unele dintre vulnerabilitățile și incertitudinile din acest răspuns să fie abordate. Cea mai mare parte a discuției are loc în prezent pe grupul de știri SQRL de pe grc.com.

SQRL este o soluție convenabilă la problema numelui de utilizator / parola paradox. (adică compromisul de comoditate / securitate) fără a utiliza o terță parte . Oferă o alternativă simplă la cel mai popular model de autentificare (Nume utilizator & Parolă), fără practic niciun compromis la securitate. Este practic la fel de sigur de oricare dintre modelele obișnuite de autentificare utilizate astăzi, atâta timp cât sunteți încă conștient de securitate . Dacă utilizați SQRL, nu înseamnă că nu puteți urma cele mai bune practici de securitate, cum ar fi , combinând aceasta cu autentificarea cu mai mulți factori pentru conturi importante.

Este important să nu pierdeți punctul SQRL. SQRL în sine nu oferă o securitate mai bună sau mai proastă. Dacă computerul / telefonul în sine sunt compromise sau utilizatorul este păcălit fiind phishing, atunci acesta este un atac lateral, în loc de o eroare directă a SQRL în sine. Fiecare metodă de autentificare convențională are această problemă a atacurilor pe canale laterale Pad-ul unbreakable este, de asemenea, vulnerabil la atacurile pe canal lateral cum ar fi compromisul tamponului în sine sau securitate sau implementări defectuoase din jur.

Dacă ați ascultat propunerea originală a ideii pe Steve Gibson „s podcast , urmat de Q & A „s, multe dintre preocupările ridicate pe acest fir de stivă au primit răspuns. De asemenea, Steve a spus el însuși că această idee foarte „simplă” și „ingenioasă” (cuvintele sale) ar trebui să fie „verificată” și „încercată” de către experții în securitate, deoarece doar timpul va spune dacă aceasta este o soluție sigură.

În concluzie, majoritatea argumentelor împotriva SQRL intră în afara domeniului SQRL în sine și, în schimb, sunt probleme cu oamenii care practică o securitate slabă. SQRL nu introduce o nouă clasificare a problemelor pe care metodele noastre tradiționale de autentificare nu le au deja.

SQRL este excelent dacă este utilizat în mod corespunzător de către persoanele conștiente de securitate. Trebuie să înțelegeți că există întotdeauna un compromis între comoditate și securitate , iar această soluție este probabil cel mai bun sold dintre cele două pe care le-am văzut.

Comentarii

• Mulțumesc Ansichart. Dar ‘ nu pot soluțiile de autentificare existente să păstreze pur și simplu caracteristici de securitate egale sau superioare SQRL și apoi să utilizeze automatizarea pentru a le spori confortul utilizatorului? Ce proprietate fundamentală a comodității utilizatorului SQRL ‘ nu este nu datorită automatizării? Întreb pentru că dacă un utilizator are două cutii negre care fac același lucru; unul etichetat ” Matur ” și celălalt etichetat ” SQRL și pot fi ambele proiectate / automatizate au aceeași interfață / butoane în exteriorul casetei – ce valoare adăugată oferă SQRL?
• Rezolvă problema paradoxului parolei fără a fi nevoie să folosesc o terță parte.
• Înțeleg. Deci, dacă cineva nu ‘ nu dorește riscul terților de conectare simplă și nu câștigă ‘ nu își generează / stochează parolele cu un manager de parole, SQRL poate intensifica. Dar dacă SQRL este o casetă neagră mobilă care solicită o parolă pentru a debloca cheia principală utilizată pentru a regenera / stoca SQRLID-uri și apoi pentru a efectua o legătură back-channel a cookie-ului clientului ‘ session_id cu serverul ‘ SQRLID înregistrat pentru autentificare – cum este aceasta o casetă neagră mobilă diferită de un manager de parolă mobil cu autentificare automată prin același back-channel; sau un plugin cert pentru client mobil cu două părți, cu generare automată & autentificare prin același back-channel?
• Am făcut o editare majoră a postării mele originale după câteva a doua considerații și o lectură mai atentă la ceea ce au spus alții, așa cum ar fi putut să-l exagerez. Presupun că faptul că telefonul mobil este cheia centrală schimbă problema și ar face mai important să aveți o securitate mai puternică pe telefon. Steve Gibson aduce acest lucru în Q & Un podcast.

Sunt de acord cu celelalte comentarii într-o anumită măsură, dar cred că există unele merite:

Pentru a activa SQRL pentru dvs., trebuie să vă creați cheia principală și să o stocați pe telefonul dvs. . TERMINAT. Din acea secundă, vă veți putea conecta la ORICE site web care utilizează „SQRL”.Și aceasta ar fi o autentificare anonimă – atâta timp cât decideți să nu furnizați alte informații.

Este mult mai ușor decât lucrul cu propriul certificat; sau crearea de conturi de utilizator explicite (probabil vă solicită să furnizați o adresă de e-mail validă). Poate că nu aș folosi aceeași cheie master pentru conturile mele bancare, Amazon, … – dar mai ales pentru aceste situații „aș vrea să postez ceva aici” … perfect. Gata cu „vă rugăm să anunțați Google sau Facebook sau orice alt site despre care doriți să postați aici”.

Comentarii

• I ‘ Nu sunt sigur că acesta este un punct valabil – dacă ‘ permiți conectări anonime, atunci de ce să te deranjezi cu o autentificare în primul rând? O simplă captcha ar fi suficientă pentru a preveni un anumit spam.
• Deoarece datele de conectare anonice sunteți DUMNEAVOASTRĂ, doar refuzați să furnizați orice informații despre identitatea dvs.; nimeni nu îl poate falsifica.
• Sună aproape ca o re-hash pe jumătate coaptă a Windows CardSpace.
• Sau un captcha, dacă vă conectați la un utilizator care nu s-a conectat niciodată înainte.
• ” Pentru a activa SQRL pentru dvs., trebuie să vă creați cheia principală și să o stocați pe telefonul dvs. ” De fapt, nu ‘ nu trebuie să faceți acest lucru, aveți nevoie doar de un software pe computer care poate deschide sqrl: // URL-uri.

SQRL nu oferă îmbunătățiri inovatoare. Codurile QR sunt un format de cod de bare optic util pentru distribuirea scurtă a conținutului – nimic mai mult.

Orice situație de „autentificare automată” pe care SQRL încearcă să o rezolve ar putea folosi pur și simplu un certificat de client stocat pe mobil.

În mod ipotetic, un cod de bare QR pe o pagină HTTPS ar putea să returneze o versiune semnată sau criptată de server a certificatului de client (sau a unei acreditări similare) așa cum era cunoscut anterior de server, dar de ce? Pentru expirarea acreditării? Site-ul ar putea respinge direct o acreditare expirată direct.

Deci, cea mai mare problemă de securitate pe care o am cu aceasta protocolul este: Reinventarea roții pătrate .

Citind noi răspunsuri și comentarii, aș dori să subliniez cât de ușor este să faci ceva similar cu SQRL prin automatizarea simplă a tehnologiei existente mature :

1. Site-ul web solicită orice verificare CAPTCHA sau o verificare similară „Sunt uman”. Odată ce utilizatorul a respectat (POST), site-ul web returnează o HTTP 403.7 - Client Certificate Required sau o eroare vanilie 403.
2. 403 de pagini personalizate sunt suficient de ușor de configurat și pot fi destul de frumoase și ușor de utilizat. S-ar putea chiar bootstrap funcționalitatea necesară mai jos într-o manieră similară cu solicitările „Adobe Reader obligatoriu” de pe multe site-uri web.
3. Pagina personalizată 403 include unele marcaje la care reacționează un plugin de browser personalizat. Haideți să numim acest plugin personalizat „compatibil S403L” în spiritul „conformității SQRL”.
4. Pluginul S403L generează un certificat de client standard, care este securizat în memoria cache cache criptată obișnuită (sau într-o a treia cache-ul de petrecere dacă criptarea depozitului de chei al browser-ului dvs. este o problemă). Pluginul creează un CSR standard pentru certificatul clientului și trimite CSR-ul la adresa URL specificată în marcajul 403 (de ex. <s403l ref="https://www.example.com/S403L" />)
5. Serverul compatibil S403L utilizează ID-ul sesiunii utilizatorului (preluat din cookie-uri sau șir de interogare) pentru a crea continuitate cu Pasul 1 și apoi returnează CSR-ul așa cum este semnat de server. Autentificarea generală a serverului va accepta orice certificat de client care a fost semnat de server (și astfel a îndeplinit criteriile de înregistrare cerute la pasul 1).
6. Pluginul S403L stochează certificatul de client semnat în memoria cache a browserului. apoi, browserul standard fără asistență pentru plugin se poate „conecta automat” la server în modul SSL / TLS standard până la expirarea certificatului.

Natura „mobilă” și „vizuală” din SQRL este o direcție greșită, deoarece nu oferă autentificare detașată cu doi factori și acum aveți nevoie de două computere pentru a naviga pe internet în loc de unul. Cu excepția cazului în care îndreptați camera web USB a desktopului către propriul său monitor.

Scalările dintre parole și certificate sunt bine definite în comunitatea de securitate: parolele se potrivesc într-un creier uman; certificatele nu se potrivesc un creier uman ( de obicei ), dar poate avea entropie nebună și caracteristici bune de gestionare a PKI (expirare , revocare, extinderi de politici etc.). SQRL nu se potrivește în niciun lagăr; și dacă se îndreaptă spre tabăra mai puțin umană, așa cum pare să fie – are ani de dezvoltare și analize de securitate pentru a repeta caracteristicile X.509 existente.

Comentarii

• > ar putea folosi pur și simplu un certificat de client stocat pe mobil.— cu excepția faptului că această tehnologie există de ani de zile atât pe dispozitive mobile, cât și pe desktop și ‘ nu este atât de răspândită pe cât s-ar dori. Și spre deosebire de certificatul clientului, SQRL nu ‘ t necesită să vă demonstrați identitatea reală pentru a crea un ” SQRL Identity „. Dacă doriți, puteți crea oricâte identități doriți. Aceasta înseamnă că avantajul comparativ cu certificatele clientului este că aveți anonimat din partea protocolului de autentificare ‘.
• @jpkrohling Este o concepție greșită obișnuită că certificatele clientului să solicite divulgarea identității. Aceasta este o cerință a autorităților de semnare comercială de a utiliza lanțurile lor de încredere interschimbabile la nivel global. În practică, un certificat de client poate fi pur și simplu un CSR anonim creat de client și semnat de un anumit server, după îndeplinirea oricăror criterii dorite (CAPTCHA, cont anterior, etc). Certificatele pot avea, de asemenea, o expirare încorporată. Type 40-L Codurile de bare QR ar putea expedia / stoca certificatul clientului de 1 KB X.509, dacă se dorește.
• Ok, adevărat, rău. Din această perspectivă, clientul (de exemplu, aplicația mobilă) ar putea genera un certificat de client pentru fiecare site web pe care utilizatorul îl înregistrează. Acest lucru pare mai scump decât hashing unele informații, dar ar putea fi o soluție interesantă. În orice caz, încă nu ‘ sunt de acord cu afirmațiile dvs. conform cărora SQRL este mai rău decât inutil.
• Poate că am fost aspru cu privire la această formulare și o voi elimina. Dar nu ‘ nu văd SQRL ca altceva decât un mod mai sexy de a distribui acreditările clientului negociat; și unul care nu a rezolvat ‘ unele dintre problemele subtile abordate de scheme de autentificare mature. Un manager de parole este plictisitor (nu mă deranjez cu integrarea browserului, deoarece ‘ ma paranoic), dar știu că numai eu și unul site-ul partajează fiecare parolă dintr-o singură fotografie în magazinul meu de chei criptate. Nu ‘ nu trebuie să îmi fac griji cu privire la noile scheme hash / auth, ci doar la calitatea PRNG / TRNG pe care managerul meu de parole o folosește pentru a genera parole.
• @LateralFractal cui îi pasă dacă ‘ este nou sau nu? SQRL permite autentificarea ușor de utilizat în cazul în care prima parte nu își expune secretul cu partea a doua sau cu o parte terță care ar fi putut compromite securitatea celei de a doua persoane ‘. ‘ este o încercare de a rezolva o problemă din lumea reală pe care, până acum, nimeni altcineva nu a putut să o rezolve.

Aș dori să abordez prima întrebare: „una dintre problemele la care mă pot gândi este dacă cititorul QR este compromis, să afișez www.google.com în loc de www.nsa-super-secret-place.gov/123 „:

Cheia principală este utilizată ca seed în HMAC împreună cu adresa site-ului web (FQDN). Deci, deși codul QR poate codifica o adresă URL complet diferită, protocolul NU va dezvălui codul de autentificare care ar fi trimis în mod normal la www.google.com (în exemplu).

În al doilea rând, mulți dintre colaboratori uită de obiectivele cheie atunci când elaborează această idee:

1. anonimatul prin faptul că nu folosește terți
2. ușurință în utilizare
3. nu este nevoie să tastați acreditări secrete pe computerele care nu sunt de încredere

Cred că protocoalele le abordează integral!

Cu toate acestea, există compromisuri care provin de la primul obiect. Dacă nicio terță parte nu este implicată în autentificare, cum se poate revoca detaliile lor de autentificare? În plus, securitatea cheii principale este o preocupare evidentă. Îmi propun ca acest lucru să fie bine protejat de viitoarele dispozitive mobile într-un cip HSM. Până atunci, cheia este doar un dispozitiv mobil cu fișier cu fișier, protejat de o parolă, deși PBDKF2 se asigură că este foarte lent să-l forțeze brutal.

Comentarii

• Din nou, ce ‘ este nou despre această idee? Mi se pare a fi o variantă primitivă pe acum defunctul Windows CardSpace.
• Da, aveți dreptate despre CardSpace. Apoi, există U-Prove deținut și de Microsoft. Întrebarea este cum ați folosi CardSpace sau U-Prove pe un computer în care nu aveți încredere (internet cafe sau computerul prietenilor). Asta a adăugat Steve.
• Ah, ok, că ‘ este ceea ce îmi lipsea. Încă sunt de acord cu @TerryChia că acesta este un non-starter fără un mecanism de revocare pentru cheile de utilizator.
• @Xander Există există un mecanism de revocare pentru cheile de utilizator. grc.com/sqrl/idlock.htm