Összességében úgy tűnik, hogy a protokoll nem növeli a meglévő technológia biztonságát. Ha identitásának online legjobb védelmét keresi, akkor ez kétségtelen és nem ez . De nézzük át az előnyöket és hátrányokat:

Előnyök

Lehetetlen ” megosztani ” egy szűk értelemben vett jelszó, amelyet egy rosszindulatú webhely nem használhat az egyik webhelyhez biztosított hitelesítéssel egy másik webhelyre való bejelentkezéshez.

A hitelesítési token elleni durva erőszakos támadás nem kivitelezhető.

A hitelesítő adatokat nem tároljuk a számítógépén. Ez megvédi Önt a munkaállomás által irányított támadások. Pontosabban védelmet nyújt a támadásokkal szemben, amelyek ellopják a jelszavát a számítógépéről. Nem védett semmiféle munkamenet-eltérítéssel vagy böngésző-átvételi támadással szemben, és most szintén fogékony vagy a telefonos támadásokra. Később erről bővebben.

Hátrányok

Ez a technika veszélyesen érzékeny a MITM támadásokra és a szociális mérnöki tevékenységre. Valószínűleg jobban, mint bármely más használt hitelesítési séma, beleértve a jelszavakat is. A hitelesítési lépés és a bejelentkezés megkezdésének lépése eleve elválik egymástól abban az értelemben, hogy a telefon helyesen hitelesít minden bemutatott QR-kódot, függetlenül attól, hogy hogyan és hol mutatják be a felhasználó számára.

Így például: az adathalász webhely hiteles bejelentkezési QR-kódot jeleníthet meg, amely a felhasználó helyett bejelentkezik a támadóba. Gibson bízik abban, hogy a felhasználók a hitelesítés során meglátják a bank, üzlet vagy webhely nevét a telefonos alkalmazásban, ezért kellő éberséget tanúsítanak a támadások megakadályozására. A történelem szerint ez valószínűtlen, és annál ésszerűbb elvárás, hogy a helyes név látása az alkalmazásban hamisan megnyugtassa a felhasználót abban, hogy azt gondolja, hogy a webhely jogszerű, mert képes volt kiváltani a telefonon az ismerős bejelentkezési kérelmet. A felhasználók fejében már megtett óvatosság a jelszóbiztonsággal kapcsolatban nem feltétlenül jelent új hitelesítési technikákat, mint ez, ami miatt ez az alkalmazás valószínűleg eredendően kevésbé ellenálló a társadalmi tervezéssel szemben.

Ez a technika a hitelesítést és az identitást egy olyan fizikai objektummá ötvözi, amelyet gyakran elvesznek vagy ellopnak. Ebben az értelemben ez ” s inkább útlevél, mint jelszó. Bárki, aki rendelkezik a telefonjával, hirtelen kizárólag birtokolja az Ön személyazonosságát: a támadó nemcsak megszemélyesítheti Önt, hanem a második telefon második példánya nélkül is ( valószínűtlen), most elvesztette a képességét, hogy azonosítsa önmagát.A hitelesítési kulcsok nem vonhatók vissza, így az egyes webhelyek sávon kívüli helyreállítása nélkül nem állíthatja vissza személyazonosságát. És még akkor is, ha a sávon kívüli helyreállítás létezik, két felhasználóval szembesülve, az egyik a személyazonosság birtokában van, a másik pedig anélkül, nehéz lehet megérteni, hogy miért bízzon benned a webhely üzemeltetője.

Ez a technika az összes hitelesítési tokent egyetlen kulcsba egyesíti , hacsak nem hoz létre másokat manuálisan. Ez az egyik kulcsod rendkívül szaftos célpont a támadók számára. Ezenkívül a kulcs a telefonján van tárolva, amely eszközök általában nevetségesen porózus belső biztonsággal rendelkeznek. A szokatlanul szaftos célok és a nem megfelelő biztonság kombinálása nem teszi biztonságossá.

Alternatívák

A séma legproblémásabb szempontja, hogy mennyire gyengén hasonlítja össze a rendelkezésre álló alternatívákkal.

A legbiztonságosabb, általánosan elfogadott lehetőség manapság a lastpass, a keepass és más hasonló, böngészővel integrált jelszó rendszerek. Különösen az ügyféloldali titkosítás enyhíti annak szükségességét, hogy megbízzunk harmadik felekben. És ami még fontosabb, a böngésző integrálása gyakorlatilag lehetetlenné teszi az adathalászat alkalmazást. A LastPass vagy a KeePass csak akkor tölti ki a jelszót, ha a megfelelő domainről szolgáltatja, ami azt jelenti, hogy ha rosszindulatú webhelyen mutatják be, akkor a felhasználónak nem lesz hozzáférése a jelszavához.

Ezenkívül a LastPass nemrégiben hozzáadott egy funkciót Ez arra készteti a felhasználókat, hogy változtassák meg a globálisan nem egyedi jelszavakat. Ez segít megelőzni a jelszavak újrafelhasználását, ami azt jelenti, hogy Gibson technikájának elsődleges előnyei ma már könnyen elérhetőek ennek az eszköznek a meglévő webhelyeken, anélkül, hogy a rendszer további bizonytalanságot jelentene.

A már meglévő, telefonokat vagy hasonló eszközöket használó hitelesítési sémák, amelyek segítenek megvédeni a felhasználói bejelentkezéseket, ma már ezt olyan módon teszik, amely nem teszi azonnal sebezhetővé a személyazonosság-lopásokkal szemben, ha az eszközét ellopják. A kétfaktoros hitelesítés biztonsága abban rejlik, hogy sem az eszköz, sem a jelszó nem használható, ha ellopják a másik nélkül. Gibson technikája nagyrészt ellenáll annak, hogy bekerüljön egy kétfaktoros sémába, ami ezt a szintet védi A cím nem érhető el.

TL; DR:

A Gibson hitelesítési technikája nem hoz elegendő előnyt az általa is felmerülő további biztonsági költségek leküzdésére. Ezek a költségek a rendszer alapvető részét képezik, és valószínűleg nem dolgozhatók ki a teljes terv selejtezése nélkül.

Azt állíthatod, hogy “jobb, mint a semmi, de nem állíthatod, hogy ez” jobb, mint bármi, amivel már rendelkezünk.

Gibson frissítései

Gibson nemrégiben jelentett be további védelmet az adathalászat ellen, mert ez komoly kritikát jelentett. Védelmük a következő: Ha NEM használja a QR-kódokat, mobiltelefonokat stb., És ehelyett van egy hitelesítő ügynök a rendszerén (például a böngészőben), akkor a szerver ellenőrizheti, hogy a hitelesítés A válasz ugyanarról az IP-ről érkezik, mint a hitelesítési kérelem. Ez jó és jó, de ennek a protokollnak az a célja, hogy személyazonosságát áthelyezze a mobiltelefonjára. Ha a protokoll használatának egyetlen biztonságos módja az, hogy nem használja a magot funkciót, akkor talán át kellene gondolnunk, hogy mit próbálunk megvalósítani.

Elméletileg folytathatná a mobiltelefon használatát, ha (és csak akkor), ha a mobiltelefonja tudja hogy ugyanazt az IP-t használta, mint a számítógéped. Amit természetesen nem tudhat, mert nem ismeri a számítógép IP-címét.

Jobb megoldás

Mint korábban említettük, ha a hitelesítési intézkedés a böngészőben található, , akkor az egész adathalász problémát azonnal megoldják, erőfeszítés és ellenőrzés nélkül. a felhasználó. Még a legkevésbé képes felhasználót sem lehet becsapni a rossz webhely hitelesítésére, mert a webhely hitelesítési tokenje a domain névhez van társítva, és a böngésző nyer ” t nem engedélyezheti a hitelesítést rossz tartományra. Ez egy ma már használt technika, teljesen automatikus, és nem igényli a webhely együttműködését vagy bármilyen intelligenciáját a felhasználó részéről.

Ez a módszer megerősíthető egy második hitelesítési tényező megkövetelésével. (például egy mobiltelefon időbeli változó kulcsa), amely ismét rendelkezésre áll és ma is használatban van, amely megvédi Önt (leginkább) a rendeltetési hely vagy vállalat részéről bekövetkező csavarásoktól.

Ami azt illeti, hogy a böngésző oldali hitelesítés kiszolgáltatott az ügyfél-munkaállomás támadásainak: bár az igaz, az is igaz, hogy ha a böngésző sérül, akkor nem az adott böngésző használata biztonságos , függetlenül attól, hogy milyen hitelesítési mechanizmust használ.A rosszindulatú programok szerzői megvárhatják (és már most is várják), amíg ön egyedül hitelesíti a szupervédett technikáját, majd csendben elküldi a szükséges forgalmat a ” saját ” a fiókod, mindez anélkül, hogy bármi bajod lenne. Sem az SQRL, sem bármely más hitelesítési rendszer nem védheti meg a veszélyeztetett böngésző felhasználóját, az ajtózárakon túlmenően az otthoni tűz ellen sem. Tűzálló zárak vásárlása nem megoldás.

Hol tovább

Ha a másolat elleni védelem abszolút garanciáját keresi , majd nézze meg a Fido U2F tokent. Ez a szabvány ragyog, ahol az SQRL elmarad, és garantált immunitást biztosít a MITM (pl. adathalász) támadásokkal szemben. Ezt nem csak a felhasználó, hanem a csatorna hitelesítésével is teszi, így Ön “garantált, hogy (a) a fiókját nem lehet hitelesíteni a token nélkül, és (b) a tokent csak a kapcsolat hitelesítésére lehet használni ahhoz a géphez, amelyhez csatolták. További információért lásd: ezt a választ .

Megjegyzések

• Az első pontról : amennyire megértem, ezt gondolták, és az egyik lehetőség az, hogy az átirányításért felelős legyen az a webhely, amelyen hitelesít. Tehát bejelentkezéskor a valódi bank ‘ s oldalra irányít át, nem pedig a támadóra. A második pontról ugyanez történik ma az olyan eszközök felhasználóival, mint a LastPass. Hacsak nem állít be valamilyen védelmi mechanizmust (például PIN-kódot), az összes jelszavát is ellopják. Miért nem lehet ugyanaz ‘ t az SQRL-re? Továbbá, amennyire a specifikációból megértem, a felhasználó még papíron is készíthet biztonsági másolatot (QR-kódként).
• És a harmadik pontról: ugyanez történik a legtöbb felhasználóval, aki nem id = “2a6529a4eb”>

SQRL minden bizonnyal nem hibátlan, de minden bizonnyal felülmúlja a legtöbb ma az interneten széles körben alkalmazott elsődleges hitelesítési megoldást a biztonság és (és ez fontos) használhatóság szempontjából. Engedje meg, hogy elmagyarázzam.

Tévhitek

Először hadd tisztázzak néhány tévhitet, amelyek a kérdésre adott néhány másik válaszban szerepelnek. Ezek a válaszok közül sok elavult, és az SQRL dokumentációjának módosítása előtt íródott. amelyek az azokban bemutatott problémákkal foglalkoznak, míg mások úgy tűnik, hogy indokolatlan hangsúlyt fektetnek az SQRL hibáira, amelyek számos más, széles körben használt, létező hitelesítési megoldásnál is jelen vannak, figyelmen kívül hagyva annak előnyeit. Tisztázzunk itt néhány tévhitet, mi?

Mítosz: Az SQRL működéséhez szükséges a QR-kódok beolvasása

Ez egyszerűen nem igaz. A QR-kódok kényelmesek ami megkönnyíti az SQRL használatát olyan számítógépeken, amelyeken a felhasználó nem állította be az SQRL kliens szoftvert. Az SQRL webhelye a következőket mondja ki:

Három út.okostelefon opcionális:

Bár ennek a rendszernek az eredeti inspirációja egy okostelefon volt, amely QR-kódot szkennelt egy webhely bejelentkezési oldalán, ennek a modellnek egy kis kiegészítése még két jelentős működési módot kínál: tegye a QR-kód képét egy kattintható linkre is ugyanarra az URL-re, amelyet a QR-kód kódolt. Ez háromféle módon jelentkezik be:

• Olvassa be a kódot okostelefonnal: A fent leírt modell szerint a felhasználó okostelefonja beolvassa a webhely bejelentkezési oldalán megjelenő QR-kódot, és a felhasználó be van jelentkezve az adott webhelyre.
• TAP A KÓD okostelefonon: Az okostelefonon lévő webhelyre való bejelentkezéshez, amikor a vizuális SQRL kód URL-stílusú link is (az sqrl: // mint séma) Az okostelefonra telepített SQRL alkalmazás megkapja ezt a linket, és biztonságosan bejelentkezteti a felhasználót a telefon webhelyére.
• Kattintson a kódra egy asztali vagy laptop képernyőn. : Az SQRL rendszer használatához bármely asztali vagy laptop rendszeren telepítenék egy asztali SQRL alkalmazást, és regisztrálná magát az sqrl: // linkek fogadására. (Ez hasonló ahhoz a módhoz, ahogy egy e-mail program regisztrál a mailto: linkek fogadására.) Ez lehetővé teszi, hogy ugyanazt a megoldást használhassák a felhasználók az asztalon, amelyet okostelefonjukon használnak. Amikor bármely webhely kínál SQRL kódot, a felhasználó csak rákattint a kódra az egér kurzorával, és a helyileg telepített SQRL alkalmazás felbukkan, felszólítja az SQRL jelszavát, megerősíti a domaint, majd bejelentkezik.

Mítosz: Az SQRL fő kulcs teljesen titkosítatlanul és védtelenül van tárolva a telefonon

Nem tudom, miért készítették ezt egyesek feltételezés, mivel számomra nyilvánvalónak tűnik, hogy ez nem így lenne. Az SQRL főkulcs ugyanúgy védett, mint egy jelszóadatbázis védelme: erős mesterjelszóval. A felhasználó telefonjának ellopása nem ad automatikusan hozzáférést online identitásához, hacsak nem rendelkezik fő jelszóval. A kulcskezeléssel kapcsolatos további részletek az SQRL Client- oldalon találhatók. Oldalkulcs-kezelés az SQRL webhelyén.

Mítosz: Ha a fő kulcsát ellopják, akkor a bejelentkezési adatokat nem módosíthatja

Ez szintén hamis. SQRL beépített módot kínál arra, hogy a valódi fióktulajdonos frissíthesse bejelentkezési adatait egy sérült kulcs esetén. Ez a szolgáltatás Identity Lock néven ismert:

Az „Identity Lock” megakadályozza az identitás megváltoztatását & lehetővé teszi a helyreállítást: Ez elég jelentős ahhoz, hogy megérdemelje a saját részletes leírását: „ Azonosító zárolási protokoll ” (4. oldal az oldal alján található linkblokkban.) a felhasználó identitását egy webkiszolgálóval, az SQRL c lient nem képes megváltoztatni ezt az identitást. Ez azt jelenti, hogy ha a legrosszabb történt, és nagyon gyenge és könnyen kitalálható jelszót használtak, vagy ha a felhasználó telefonját vagy asztalát feltörték, hogy megszerezzék identitásuk fő kulcsát és jelszavát, egyetlen rosszindulatú harmadik fél sem változtathatja meg a felhasználó online identitását , hogy kizárja őket saját online fiókjukból. Ezenkívül egy normálisan offline „Identity Unlock Key” betöltésével az identitásuk valódi tulajdonosa visszavonulhat, és elveszett vagy ellopott online identitását lényegében visszavetheti. bármely támadótól, használhatatlanná téve korábbi identitásukat.

Valószínű: Az SQRL sebezhetőbb az adathalászat ellen, mint meglévő hitelesítési megoldások

Rendben, tehát ez valójában részben igaz. Ha az SQRL-t QR-kód beolvasásával használja, valóban nagyon kevés a védelem az adathalászat ellen. Hacsak a felhasználó nem vigyáz arra, hogy a böngészője URL-sávjában megjelenő webhely megegyezzen az SQRL Client alkalmazás által megjelenített weboldallal, engedélyezheti a támadó bejelentkezési munkamenetét. Ez még mindig jobb, mint a jelszavak, ahol adathalásznak állandó hozzáférést biztosítanak a fiókjához (és minden más olyan fiókjukhoz, amely máshol van, ugyanazon a jelszóval rendelkeznek), amíg nem változtatják meg a jelszavukat, de nem olyan jóak, mint más megoldások, amelyek integrálódnak a felhasználó böngészőjébe, például az U2F kulcsok , WebAuthn, klienstanúsítványok és (bizonyos feltételek mellett) jelszókezelők.

Ha azonban ugyanazon az eszközön használ SQRL klienst, amellyel bejelentkezik, akkor az SQRL védelmet nyújt Az adathalászat a helyén van. Ezeket a védelmeket az SQRL webhelyének szakaszában ismertetjük. Hogyan akadályozhatja meg az SQRL az adathalász támadásokat .Lehetőség van az SQRL és a böngészők integrálására (esetleg beépülő modulokon keresztül), hogy sokkal erősebb védelmet nyújtson az adathalász támadások ellen, hasonlóan a WebAuthn és az ügyféltanúsítványokhoz.

Összességében az SQRL-et rangsorolom körülbelül ugyanazon a szinten, mint az adathalász-védelem jelszókezelői. Erős védelmet nyújthat az adathalászat ellen, ha ugyanarra az eszközre van telepítve, amelybe a felhasználó bejelentkezik, de minimális védelmet nyújt, ha másik eszközre telepíti.

Összehasonlítás az alternatívákkal

Most hasonlítsuk össze az SQRL-t a létező, széles körben használt hitelesítési megoldásokkal.

Jelszavak

Az SQRL sok szempontból jóval jobb a jelszavaknál. Nemcsak kényelmesebb használni, ha beállítottuk felfelé, mivel a felhasználóknak nem kell aggódniuk azért, hogy minden webhelyhez különféle jelszavakat emlékezzenek meg vagy írjanak be újra, de véd a jelszavak újrafelhasználása, a gyenge jelszavak, a billentyűzár és bizonyos mértékig az adathalászat ellen is.

Hátrányok Az SQRL összehasonlította a jelszavakkal, hogy nehezebb megvalósítani a weboldal üzemeltetői számára, nem annyira széles körben használják, több időre van szükség a kezdeti beállításhoz, némi erőfeszítést igényel egy új eszközre való áttérés, és egyetlen hibapontot biztosít a felhasználók számára. az összes felhasználó fiókja, ha a fő kulcsot ellopták (bár ez az utolsó poin t a jelszavak esetében is, ha a felhasználó minden webhelyen ugyanazt a jelszót használja).

Jelszókezelők

Az SQRL sok szempontból nagyon hasonlít a jelszókezelőkre. Mindkettő egyetlen, központosított megbízhatósági horgonyt biztosít, amely egyfajta hitelesítési proxyként szolgál a felhasználók és az egyes szolgáltatások között. Van néhány módja annak, hogy az SQRL felülmúlja a jelszókezelőket.

Úgy gondolom, hogy az SQRL legfőbb előnye a jelszókezelőkkel szemben az, hogy könnyebben és biztonságosabb használni nem megbízható vagy csak részben megbízható számítógépeken. Tegyük fel például, hogy egy felhasználó egy nyilvános könyvtárban lévő számítógép segítségével szeretne bejelentkezni egy webhelyre. Jelszókezelővel vagy be kell érnie a webhelyen található jelszót a telefonján, és manuálisan be kell írnia a számítógépbe, vagy le kell töltenie a a jelszókezelőt és a jelszóadatbázist a könyvtári számítógépre, nyissa fel az adatbázist a fő jelszavával, majd jelentkezzen be. Az első forgatókönyv kényelmetlen a felhasználó számára, és kiteszi a felhasználó egyszerű szöveges jelszavát a nem megbízható számítógép számára (és bármilyen rosszindulatú program a nem megbízható számítógépen, beleértve a billentyűzárakat is). A második forgatókönyv még rosszabb, mivel egyszerre kellemetlen, és a felhasználó teljes, visszafejtett jelszóadatbázisát és a fő jelszavát a nem megbízható számítógépnek teszi ki. Az SQRL használatával a felhasználónak csak egy QR-kódot kell beolvasnia a nem megbízható számítógép képernyőjére, ami sokkal kényelmesebb a felhasználó számára, és csak egyetlen bejelentkezési munkamenetet tesz ki (nem használható fel újra felhasználható hitelesítő adatokkal, például jelszóval) a nem megbízható számítógépnek. .

Az SQRL további előnye a jelszókezelőkkel szemben, hogy könnyebb helyreállni a legrosszabb esetből: a felhasználó jelszó adatbázisát / fő kulcsát ellopják. Jelszókezelővel nem csak minden webhelyen meg kell változtatnia a jelszavát, akkor is aggódnia kell, hogy a támadó megváltoztatja a jelszavát (esetleg kizárja Önt a fiókjából). A támadónak az az előnye is, hogy rendelkezik az összes olyan webhely listájával, amely rendelkezik a jelszó-adatbázis eltulajdonításának sokkal könnyebb kihasználása. Az SQRL használatával a fő kulcs ellopása még mindig szörnyű helyzet, de a támadónak nincs listája azokról a webhelyekről, amelyeken Ön rendelkezik fiókkal (inkább kitalálnia kell ), és nem tudja megváltoztatni a jelszavát a zároláshoz a fiókja. Miután feltöltöttük a személyazonosság feloldó kulcsát, egy kicsit kényelmesebb megváltoztatni a bejelentkezési adatokat minden webhelyen, mivel az SQRL kliens képes ezt automatikusan elvégezni az Ön számára minden bejelentkezéskor meglátogatott webhelynél. (Nem kell mennie bármilyen “jelszóváltoztatási” űrlapon keresztül.)

Végül úgy gondolom, hogy az SQRL-nek egyetlen apró, de fontos előnye van a jelszókezelőkkel szemben a jelszavak teljes cseréjének céljával kapcsolatban, vagyis hogy a webhelyeknek lehetőségük van kikényszeríteni. az SQRL használata a hagyományos jelszavakkal szemben. Mindaddig, amíg a felhasználóknak továbbra is van lehetőségük a gyenge biztonságra, ugyanazon jelszó újrafelhasználásával minden webhelyen, ez még mindig megtörténik. Ha az SQRL elkezdi széles körű elfogadását, a webhelyek valóban elkezdhetik fokozatosan megszüntetni a használatát jelszavak kezelőivel, mivel a jelszavak használatára támaszkodnak a munka érdekében.

A hátrányok szempontjából valójában nem tudok olyan helyzetre gondolni, amikor az SQRL feltétlenül rosszabb lenne, mint a jelszókezelők Biztonság. Az SQRL fő hátránya, hogy támogatást igényel a weboldal üzemeltetőitől, míg a jelszókezelők nem igényelnek külön támogatást a meglévő szolgáltatásoktól. Ez azt jelenti, hogy már most elkezdheti használni a jelszókezelőket, de az SQRL-nek meg kell várnia, amíg a webhelyek végrehajtják, mielőtt felhasználható lenne. Ez jelentős akadályt jelent az örökbefogadás előtt.

Ügyféltanúsítványok

Az SQRL elsődleges előnye az ügyféltanúsítványokkal szemben a kényelem. Az ügyféltanúsítványok beállítása jelenleg bonyolult, nehezen vihető át a számítógépek között, és adatvédelmi problémák merülnek fel, ha ugyanazt a tanúsítványt használják különböző helyeken. Míg elméletileg kliens tanúsítványok segítségével felépíthetnénk egy rendszert, amely megoldaná ezeket a problémákat, felmerülne a webes felhasználói felületekkel és a webszerverekkel való gyenge integráció problémája is, amelyeket nehezebb megoldani. Itt nem fogok túl részletezni, mivel már van egy kiváló cikk az ügyféltanúsítványok használhatósági kérdéseiről a browserauth.net oldalon.

A biztonság szempontjából az ügyféltanúsítványok hátránya, hogy megkövetelik a hitelesítésszolgáltató bevonását. Ez (potenciálisan) drága, és meg kell bízni a harmadik fél CA-jában. Továbbá, ha úgy dönt, hogy figyelmen kívül hagyja a hitelesítésszolgáltatókat, és inkább aláírja a tanúsítványokat, akkor foglalkoznia kell a tanúsítványok visszavonásával. Az ügyféltanúsítványoknak ugyanolyan biztonsági és kényelmi problémái vannak, mint a jelszókezelőknek, ha a felhasználók nem megbízható számítógépen szeretnének bejelentkezni; át kell adniuk a tanúsítványukat a nem megbízható számítógépre, ami egyszerre kellemetlen és potenciálisan kiteszi a fő identitásukat az adott számítógépen található rosszindulatú programok számára.

Röviden, amíg valaki jobb, felhasználóbarát megoldással nem áll elő kliens tanúsítványok, amelyek megoldják ezeket a problémákat (legalábbis a legtöbb), nem hiszem, hogy az ügyfél tanúsítványok komoly versenytársak az SQRL-nek (vagy ami azt illeti, a jelszavaknak).

2-faktoros hitelesítés

Csak gondoltam, hogy ezt megemlíteném: Az SQRL és a 2-faktoros hitelesítés nem kizárja egymást. Az SQRL helyettesíti a 2FA első tényezőjét: jelszavakat. Egyéb kiegészítő intézkedések, például OTP-kódok vagy FIDO U2F kulcsok továbbra is használhatók az SQRL-lel.

WebAuthn

Most itt “s ahol a dolgok érdekessé válnak. A WebAuthn egy új (jól, az SQRL-nél újabb) W3C szabvány, amelyet arra terveztek, hogy egy szabványos API-t biztosítson, amelyet a webhelyek felhasználhatnak a felhasználók nyilvános kulcsokkal történő hitelesítésére az interneten. Csakúgy, mint az SQRL, támogatja a felhasználást a felhasználó telefonjának használatával egy külső eszközön történő bejelentkezési munkamenet hitelesítéséhez , néhány egyéb hitelesítési módszer mellett (például a 2. faktor biztonsági kulcsai). .

Itt az SQRL végre megfelel a mérkőzésének, legalábbis biztonsági szempontból. A WebAuthn nemcsak ugyanazt a védelmet nyújtja a jelszavak újrafelhasználása, a gyenge jelszavak és a billentyűzárolás ellen, mint az SQRL, de még erősebb védelmet nyújt az adathalászat ellen azáltal, hogy integrálódik a felhasználó böngészőjébe akár a bejelentkezés engedélyezésekor. munkamenet PC-re, a felhasználó korábban nem állította be a hitelesítő kliens szoftverét. Ez azért lehetséges, mert ebben a helyzetben a WebAuthn közvetlenül kommunikál a felhasználó böngészőjével kétirányú kommunikációs protokollok segítségével, mint például a Blutooth vagy az NFC, ahelyett, hogy a felhasználó által használt weboldallal egyirányú QR-kódon keresztül kommunikálna.

Használhatóság szempontjából a dolgok valamivel bonyolultabbak. Legalábbis a felszínen a WebAuthn nyer. Mivel ez egy W3C szabvány, amelyet már több böngészőben is megvalósítottak , elméletileg a felhasználók azonnal megkezdhetik a WebAuthn használatát harmadik féltől származó szoftverek telepítése nélkül. A gyakorlatban azonban a legtöbb meglévő WebAuthn-implementáció arra összpontosít, hogy azt másodfaktoros hitelesítésként, vagy a felhasználó újhitelesítésének módjaként használja. aki korábban ugyanazon az eszközön más bejelentkezési módszerrel (általában jelszóval) jelentkezett be. Elsődleges hitelesítési tényezőként a WebAuthn még mindig hiányzik az életképes megvalósításokból.

További kisebb szempontok közé tartozik az a tény, hogy az SQRL rendelkezik egy buil t-in módszer a fiókok kulcsainak elforgatásához ellopott főkulcs esetén, míg a WebAuthn a webhelyekre támaszkodik, hogy saját rendszert hozzanak létre a kulcsok visszavonásához, és arra, hogy a WebAuthn bizonyos opcionális hardvereket (például Bluetooth vagy NFC) igényel távoli gépen történő hitelesítéshez, míg az SQRL bármely működő kijelzővel működő gépen működhet.

Összességében úgy gondolom, hogy nagyon valószínű, hogy a WebAuthn végül elavulttá teszi az SQRL-t. Lehet, hogy az SQRL-nek egyelőre van egy kis légzési helye, de a WebAuthn sokkal erősebb támogatást nyújt a böngésző gyártóktól, a webhely üzemeltetőitől és más harmadik felektől (például a W3C-től). Amint a WebAuthn megkap egy pár megvalósítást, amely lehetővé teszi az elsődleges hitelesítési tényezőként való használatát, arra számítok, hogy nagyon gyorsan el fogja kezdeni az internet átvitelét.

Figyelmeztetések

Az SQRL még aktív fejlesztés alatt áll, tehát az ebben a válaszban bemutatott anyag változhat. A fejlődés folytatása során arra számítok, hogy a válasz néhány sebezhetőségével és bizonytalanságával foglalkozunk. A vita nagy része jelenleg a SQRL hírcsoporton zajlik a grc.com címen.

Az SQRL kényelmes megoldás a felhasználónév problémájára / jelszó paradoxon. (azaz kényelmi / biztonsági kompromisszum) harmadik fél használata nélkül . Egyszerű alternatívát kínál a legnépszerűbb hitelesítési modellhez (felhasználónév & jelszó), a gyakorlatilag a biztonság szempontjából nincs kompromisszum. gyakorlatilag ugyanolyan biztonságos a manapság használt általános hitelesítési modellek bármelyikénél, mindaddig, amíg még mindig biztonságtudatos vagy . Ha SQRL-t használ, ez nem azt jelenti, hogy nem tudja követni a legjobb biztonsági gyakorlatokat, például ezt kombinálva többtényezős hitelesítéssel fontos fiókokhoz.

Fontos, hogy ne hagyja ki az SQRL lényegét. Az SQRL nem feltétlenül nyújt jobb vagy rosszabb biztonságot. Ha maga a számítógép / telefon is veszélybe kerül, vagy a felhasználót becsapják adathalászat, akkor ez egy mellékcsatornás támadás, nem pedig maga az SQRL hibája. Minden hagyományos hitelesítési módszernél felmerül az oldalsó csatorna támadások problémája mint például a betét kompromisszuma, vagy a rossz környezeti biztonság vagy megvalósítások.

Ha meghallgatta az ötlet eredeti javaslatát Steve Gibson “s podcast , amelyet a Q & A “követ, a veremszálon felvetett számos aggály megválaszolható. Steve azt mondta maga is, hogy ezt a nagyon “egyszerű” és “ötletes” (szavai) ötletet a biztonsági szakértőknek “át kell vizsgálniuk” és “be kell kalapálniuk”, mivel csak az idő fogja megmondani, hogy ez biztonságos megoldás-e.

Összegzésképpen elmondható, hogy az SQRL-sel szembeni érvek többsége kívül esik az SQRL tartományán, és inkább a rossz biztonságot gyakorló emberekkel kapcsolatos problémákat jelent. Az SQRL nem vezeti be a problémák új osztályozását, amelyek a hagyományos hitelesítési módszereinknél még nincsenek.

Az SQRL kiváló, ha biztonságtudatos emberek használják megfelelően. Meg kell értened, hogy mindig kompromisszum van a kényelem és a biztonság között , és valószínűleg ez a megoldás a a legjobb egyensúly a kettő közül, amit láttam.

Megjegyzések

• Köszönöm Ansichart. De vajon a ‘ t létező hitelesítési megoldások egyszerűen megtarthatják-e az SQRL-hez hasonló vagy magasabb szintű biztonsági szolgáltatásokat, és ezután automatizálással növelhetik felhasználói kényelmüket? Az SQRL ‘ felhasználói kényelmének milyen alapvető tulajdonsága nem az automatizálás miatt? Azért kérdezem, mert ha a felhasználónak két fekete doboza van, amelyek ugyanazt csinálják; az egyik ” Érett “, a másik ” SQRL ” és mindkettő fejleszthető / automatizálható, ugyanazzal az interfésszel / gombokkal a doboz külső oldalán – milyen hozzáadott értéket nyújt az SQRL?
• Megoldja a jelszó paradoxon problémáját harmadik fél igénybevétele nélkül.
• Úgy látom. Tehát ha valaki nem ‘ nem akarja az egyszeri bejelentkezés harmadik fél általi kockázatát, és megnyerte ‘ t, akkor nem generálja / tárolja a jelszavát jelszókezelővel, az SQRL fokozódhat. De ha az SQRL egy mobil fekete doboz, amely jelszót kér az SQRLID-ek regenerálásához / tárolásához használt fő kulcs feloldásához, majd az ‘ kliens cookie / QR-jének hátsó csatorna összekapcsolását hajtja végre. session_id a ‘ kiszolgálóval rögzítette az SQRLID-t a bejelentkezéshez – hogy van ez egy másik mobil black-box egy mobil jelszókezelőtől, ugyanazon a hátsó csatornán keresztül automatikusan bejelentkezve; vagy egy kétoldalú mobil kliens cert plugin automatikus generálás & bejelentkezéssel ugyanazon a hátsó csatornán keresztül?
• Az eredeti bejegyzésem néhány jelentős szerkesztését elvégeztem néhány másodperces megfontolás után, és jobban elolvasva mások mondanivalóját, mivel lehet, hogy túlságosan is hipnotizáltam. Gondolom, ha a mobiltelefon lenne a központi kulcs, ez áthelyezné a problémát, és fontosabbá tenné a telefon biztonságának megerősítését. Steve Gibson ezt is felveti a Q & A podcastban.

Bizonyos mértékben egyetértek a többi megjegyzéssel, de szerintem vannak bizonyos érdemei:

Az SQRL engedélyezéséhez létre kell hoznia a fő kulcsot, és el kell tárolnia a telefonján . KÉSZ. Ettől a pillanattól kezdve bejelentkezhet MINDEN weboldalra, amely az “SQRL” szót használja.És ez névtelen bejelentkezés lenne – mindaddig, amíg úgy dönt, hogy nem ad meg további információkat.

Ez SOKKAL könnyebb, mint a saját tanúsítvánnyal dolgozni; vagy kifejezett felhasználói fiókok létrehozása (valószínűleg érvényes e-mail cím megadását kéri). Talán nem használnám ugyanazt a fő kulcsot a banki, amazon, … számláimhoz – de különösen ezekhez a “szeretnék itt valamit közzétenni” helyzetekhez … tökéletes. Nincs többé “kérjük, értesítse a Google-t, a Facebook-ot vagy bármely más webhelyet arról, hogy itt szeretne közzétenni”.

Megjegyzések

• I ‘ nem vagyok biztos benne, hogy ez sok érvényes pont – ha ‘ engedélyezi a névtelen bejelentkezéseket, akkor miért kell elsősorban a bejelentkezéssel foglalkozni? Egy egyszerű captcha elegendő a spamek megakadályozásához.
• Mivel az anon bejelentkezés TE vagy, csak elutasítod a személyazonosságoddal kapcsolatos információk megadását; senki sem tudja hamisítani.
• Ez majdnem úgy hangzik, mint a Windows CardSpace félig-meddig újrakevert változata.
• Vagy egy captcha, ha olyan felhasználóval jelentkezik be, aki soha nem jelentkezett be előtt.
• ” Az SQRL engedélyezéséhez létre kell hoznia a fő kulcsot, és el kell tárolnia a telefonján. ” Valójában nem kell ‘ ezt megtenni, csak egy olyan szoftverre van szüksége a számítógépén, amely képes megnyitni az sqrl: // URL-eket.

Az SQRL nem nyújt úttörő fejlesztéseket. A QR-kódok egy optikai vonalkód-formátum, amely rövid tartalomterjesztéshez hasznos – semmi más.

Bármely “automatikus bejelentkezés” helyzet, amelyet az SQRL megpróbál megoldani, egyszerűen használhatja a mobilon tárolt kliens tanúsítványt.

Hipotetikusan egy HTTPS-oldalon lévő QR vonalkód visszaadhatja az ügyféltanúsítvány (vagy hasonló hitelesítő adatok) szerver által aláírt vagy titkosított verzióját, amint azt a szerver korábban ismerte, de miért? Hitelesítő adatok lejártához? A webhely egyszerűen elutasíthatja a lejárt hitelesítő adatokat.

Tehát a legnagyobb biztonsági probléma van ezzel A protokoll a következő: A négyzetkerék újrafeltalálása .

Update

Új válaszokat és megjegyzéseket olvasva szeretném felhívni a figyelmet arra, hogy mennyire egyszerű az SQRL-hez hasonló dolgot megtenni A kiforrott meglévő technológia egyszerű automatizálása:

1. A webhely bármilyen CAPTCHA-t vagy hasonló “I” ma human “ellenőrzést kér. Miután a felhasználó eleget tett (POSTed), a webhely HTTP 403.7 - Client Certificate Required vagy egy vanília 403 hibát ad vissza.
2. Az egyedi 403 oldal elég könnyen beállítható , és meglehetősen csinos és felhasználóbarát lehet. Még az alábbiakban megkövetelt funkciókat is képes feltölteni az “Adobe Reader szükséges” -hez hasonló módon sok webhelyen.
3. A Custom 403 oldal tartalmaz némi jelölést, amelyre egy egyéni böngésző plugin reagál. Nevezzük ezt az egyedi plugint “S403L-kompatibilisnek” az “SQRL-megfelelés” szellemében.
4. Az S403L beépülő modul szabványos ügyféltanúsítványt generál, amelyet a szokásos titkosított böngésző cert-gyorsítótárában (vagy egy harmadik party cache, ha a böngésző kulcstár-titkosítása szivárog). A plugin létrehoz egy szabványos CSR-t az ügyfélcert számára, és elküldi a CSR-t a 403-as jelölésben megadott URL-re (pl. <s403l ref="https://www.example.com/S403L" />)
5. Az S403L kompatibilis szerver a felhasználó session_id azonosítóját használja (amely cookie-kból vagy lekérdezési karaktersorozatból származik), hogy folytonosságot hozzon létre az 1. lépéssel, majd a kiszolgáló által aláírt CSR-t adja vissza. Az általános szerver-hitelesítés elfogad minden olyan ügyféltanúsítványt, amelyet a szerver írt alá (és így megfelelt az 1. lépésben megkövetelt regisztrációs feltételeknek).
6. Az S403L plugin tárolja az ügyféltanúsítványt a böngésző gyorsítótárában. majd a plugin segítség nélküli szabványos böngésző a tanúsítvány lejártáig “automatikusan bejelentkezhet” a szerverre a szokásos SSL / TLS módon.

A “mobil” és “vizuális” jelleg Az SQRL fájl egy félrevezetés, mivel nem nyújt leválasztott kétfaktoros hitelesítést, és most egy számítógép helyett két számítógépre van szükség az interneten való navigáláshoz. Hacsak nem az asztali számítógép USB-kameráját irányítja a saját monitorjára.

A jelszavak és a tanúsítványok közötti kompromisszumokat a biztonsági közösség jól meghatározza: A jelszavak beleférnek az emberi agyba; a tanúsítványok nem illenek be emberi agy ( általában ), de őrült entrópiája és jó PKI-kezelési funkciói lehetnek (lejárat , visszavonás, házirend-kiterjesztések stb.). Az SQRL tisztán illeszkedik egyik táborba sem; és ha úgy tűnik, a kevésbé emberibb, több számítógépes tábor felé sodródik – évekig tartó fejlesztési és biztonsági elemzés alatt áll, hogy megismételje az X.509 meglévő funkcióit.

Megjegyzések

• > egyszerűen használhatja a mobilon tárolt kliens tanúsítványt.— kivéve, hogy ez a technológia évek óta létezik mind mobilon, mind asztali számítógépen, és ‘ nem annyira elterjedt, mint azt szeretnénk. Az ügyféltanúsítvánnyal szemben az SQRL nem követeli meg, hogy igazolja valódi identitását, hogy létrehozhasson egy ” SQRL identitást “. Ha szeretné, annyi identitást hozhat létre, amennyit csak akar. Ez azt jelenti, hogy az ügyféltanúsítványokkal összehasonlítva az az előny, hogy névtelenek vagyunk az auth protokoll ‘ oldalán.
• @jpkrohling Általános tévhit, hogy az ügyféltanúsítványok megkövetelhetik a személyazonosság nyilvánosságra hozatalát. Ez a kereskedelmi aláíró hatóságok követelménye, hogy globálisan felcserélhető bizalmi láncukat használják. A gyakorlatban az ügyfél-tanúsítvány egyszerűen egy névtelen CSR lehet, amelyet az ügyfél hozott létre, és amelyet egy adott szerver írt alá, miután teljesítette a kívánt feltételeket (CAPTCHA-k, előzetes fiók, stb). A tanúsítványok beépített lejárattal is rendelkezhetnek. A Type 40-L QR vonalkódok szükség esetén elküldhetik / eltárolhatják az 1 KB X.509 ügyfél-tanúsítványt.
• Ok, igaz, rossz. Ebből a szempontból az ügyfél (például mobilalkalmazás) létrehozhat egy ügyfél-tanúsítványt minden egyes webhelyhez, amelyet a felhasználó regisztrál. Ez drágábban hangzik, mint néhány információ összegyűjtése, de érdekes megoldás lehet. Mindenesetre még mindig nem értek egyet

Szeretném megválaszolni az első kérdést: “Az egyik probléma, amire gondolni tudok, ha a QR-olvasó sérül, a www.google.com megjelenítése www.nsa-super-secret-place.gov/123 “helyett:

A mester kulcsot a HMAC magvaként használják, a weboldal címével (FQDN) együtt. Tehát bár a QR-kód teljesen más URL-t kódolhat, a protokoll NEM fedi fel azt a hitelesítési kódot, amelyet általában a www.google.com címre küldenének (a példában).

Másodszor, a közreműködők közül sokan megfeledkeznek a fő célkitűzésekről, amikor ezt az ötletet kidolgozzák:

1. névtelenség harmadik fél nem használatával
2. egyszerű használat
3. nem kell titkos hitelesítő adatokat megadni nem megbízható számítógépeken

Úgy gondolom, hogy a protokollok ezeket teljes mértékben kezelik!

Vannak azonban kompromisszumok, amelyek valójában az első objektívből származnak. Ha harmadik fél nem vesz részt a hitelesítésben, hogyan vonhatja vissza hitelesítési adatait? Ezenkívül a fő kulcs biztonsága nyilvánvaló aggodalomra ad okot. Úgy gondolom, hogy ezt a jövőbeni HSM-szerű chipben lévő mobil eszközök jól megvédik. Addig a kulcs csak egy fájl tűs mobil eszköz, amelyet jelszó védett, bár a PBDKF2 biztosítja, hogy nagyon lassú legyen a tényleges nyers erő.

Megjegyzések

• Ismét mi ‘ újdonság ebben az ötletben? Számomra primitív változatnak tűnik a mára megszűnt Windows CardSpace-en.
• Igen, igazad van a CardSpace-ben. Aztán ott van az U-Prove is, amely szintén a Microsoft tulajdonában van. A kérdés az, hogy hogyan használná a CardSpace-et vagy az U-Prove-ot egy olyan számítógépen, amelyben nem bízik (internet kávézó vagy barátok számítógépe). Steve ezt tette hozzá.
• Á, ok, ez ‘ hiányzik. Továbbra is egyetértek @TerryChia véleményével, hogy ez nem indító, a felhasználói kulcsok visszavonási mechanizmusa nélkül.
• @Xander Van egy a felhasználói kulcsok visszavonási mechanizmusa. grc.com/sqrl/idlock.htm