Het artikel reflecteert op de voorspellende waarde van SQRL (Secure Quick Reliable Login), een door Steve Gibson ontwikkeld systeem dat al vroeg inzette op wachtwoordloze authenticatie via publieke sleutelcryptografie. Hoewel het concept technisch elegant was en phishing effectief kon tegengaan, ontbrak het aan de nodige coördinatie tussen browsers, besturingssystemen en websites om een brede adoptie te realiseren.
De auteur vergelijkt dit met de huidige opkomst van passkeys. Hoewel de technische implementaties verschillen, is het uitgangspunt hetzelfde: het elimineren van gedeelde geheimen (wachtwoorden). Passkeys zijn wel succesvol geworden omdat zij worden ondersteund door platformgiganten als Apple, Google en Microsoft, waardoor de technologie naadloos in bestaande workflows is geïntegreerd. De conclusie is dat SQRL niet ongelijk had over de richting van authenticatie, maar simpelweg te vroeg was voor de industrie.
SQRL had niet ongelijk. Het was te vroeg
Af en toe kom ik een stuk technologie tegen dat me eraan herinnert hoeveel timing ertoe doet. Passkeys zijn daar een voorbeeld van. Telkens wanneer Apple, Google, Microsoft of een aanbieder van wachtwoordbeheerders iets nieuws aankondigen, denk ik terug aan een rit naar mijn werk ergens rond 2013 of 2014.
Zoals bij veel van mijn ritten in die tijd, luisterde ik naar Security Now!. Steve Gibson introduceerde iets waar hij aan had gewerkt genaamd SQRL, kort voor Secure Quick Reliable Login. Ik kan me nog herinneren dat ik die ochtend op kantoor aankwam en het grootste deel van de dag over dit onderwerp sprak.
De timing kon voor mij niet beter zijn geweest. Bij Wirehive waren we bezig met de overstap van SSH-sleutels naar SSH-certificaten, dus authenticatie en identiteit kwamen bijna dagelijks ter sprake. We dachten al na over hoe asymmetrische cryptografie gedeelde geheimen (shared secrets) in één deel van de stack kon vervangen, en toen beschreef Steve hoe hetzelfde idee zou kunnen werken voor het inloggen op websites.
Het klikte onmiddellijk. Ik herinner me dat ik dacht dat dit veel interessanter was dan nog een wachtwoordbeheerder of een nieuwe poging om wachtwoorden iets minder verschrikkelijk te maken. SQRL stelde een grotere vraag: "Wat als we simpelweg zouden stoppen met het gebruik van wachtwoorden?"
Het concept hield in dat je aan elke website een andere cryptografische identiteit zou presenteren. Er zou geen wachtwoord zijn om te onthouden of te hergebruiken, en er zou geen gedeeld geheim in een database staan dat gestolen kon worden. Een phishing-site zou vrijwel niets van waarde kunnen onderscheppen. Publieke sleutelcryptografie deed het werk, terwijl de authenticatie zelf bijna uit het zicht verdween.
Ik was er dol op.
Ik ben er vrij zeker van dat ik Robin kort daarna heb overtuigd om SQRL-ondersteuning toe te voegen aan het Wirehive-portaal. Dat is hoe we destijds werkten. Als we iets interessants vonden, bouwden we het. Er was geen commissie, geen sturingsgroep of een ontdekkingstraject van zes maanden. Iemand verdween een paar dagen en meldde dan terloops dat hij ondersteuning ervoor had toegevoegd.
Als ik terugkijk, mis ik dat.
Een tijd lang volgde ik SQRL op de voet en verwachtte ik dat dit de richting was die authenticatie op zou gaan. Daarna gebeurde er niet veel meer. Er waren implementaties en een toegewijde gemeenschap, maar SQRL kwam nooit veel verder dan die gemeenschap. Na verloop van tijd hoorde ik er weinig meer over.
Een decennium later zijn passkeys ingebouwd in besturingssystemen, browsers en wachtwoordbeheerders. Banken en identiteitsproviders voor bedrijven nemen ze over. Wachtwoordloze authenticatie is verschoven van beveiligingspodcasts naar producten die gewone mensen gebruiken zonder dat ze de onderliggende cryptografie hoeven te begrijpen.
Telkens wanneer ik die vooruitgang zie, denk ik aan SQRL in volwassen vorm.
De architecturen zijn verschillend. Moderne passkeys maken afzonderlijke inloggegevens (credentials) aan voor elke dienst en kunnen deze synchroniseren tussen apparaten. SQRL leidde de identiteit van elke website deterministisch af uit een hoofdidentiteit. Ze maakten verschillende technische keuzes, maar vertrokken vanuit hetzelfde uitgangspunt: mensen zouden geen gedeeld geheim hoeven te onthouden voor elke dienst die ze gebruiken.
Ik heb nooit bewijs gezien dat de FIDO Alliance heeft voortgebouwd op het werk van Steve Gibson, en ik beweer niet dat er een directe lijn loopt van SQRL naar WebAuthn of passkeys. Authenticatie met publieke sleutels bestond al vóór SQRL, en veel slimme mensen werkten destijds aan wachtwoordloze authenticatie.
Toch verdient Steve erkenning voor het tonen — in concrete technische details — hoe wachtwoordloze webauthenticatie zou kunnen werken, jaren voordat de industrie klaar was om dit op grote schaal uit te rollen.
Het grootste probleem van SQRL was coördinatie. Hoe elegant het protocol ook was, browsers, besturingssystemen, websites en gebruikers moesten allemaal gelijktijdig overstappen voordat het een normale manier van inloggen kon worden. Dat is nooit gebeurd.
Passkeys bereikten hetzelfde terrein via een andere route. Apple, Google en Microsoft steunden gemeenschappelijke standaarden en integreerden deze in hun platforms. Browsers kregen ondersteuning, wachtwoordbeheerders volgden, en websites konden passkeys adopteren zonder gebruikers eerst te moeten overtuigen om een onbekend authenticatiesysteem op te zoeken.
Die ondersteuning is precies wat SQRL miste. Inloggen met publieke sleutels werd praktisch omdat de software die mensen al gebruikten dit ongeveer op hetzelfde moment begon te ondersteunen.
We hebben de neiging om de technologie te onthouden die standaard is geworden en de mensen te vergeten die het idee eerder hebben gedemonstreerd. SQRL is niet de authenticatiestandaard voor het web geworden, maar het liet zien hoe wachtwoordloze authenticatie eruit zou kunnen zien lang voordat de grootste platformleveranciers er klaar voor waren om dit te leveren.
Elke keer als ik iets ontgrendel met een passkey, denk ik terug aan die rit naar mijn werk en het binnenstappen in het Wirehive-kantoor, waarbij ik iedereen die wilde luisteren probeerde uit te leggen waarom dit vreemde ding genaamd SQRL zomaar de toekomst zou kunnen zijn.
Zoals blijkt, denk ik niet dat ik ongelijk had. Ik hoorde er alleen tien jaar eerder over dan alle anderen.
SQRL had niet ongelijk. Het was te vroeg
Af en toe kom ik een stuk technologie tegen dat me eraan herinnert hoeveel timing ertoe doet. Passkeys zijn daar een voorbeeld van. Telkens wanneer Apple, Google, Microsoft of een aanbieder van wachtwoordbeheerders iets nieuws aankondigen, denk ik terug aan een rit naar mijn werk ergens rond 2013 of 2014.
Zoals bij veel van mijn ritten in die tijd, luisterde ik naar Security Now!. Steve Gibson introduceerde iets waar hij aan had gewerkt genaamd SQRL, kort voor Secure Quick Reliable Login. Ik kan me nog herinneren dat ik die ochtend op kantoor aankwam en het grootste deel van de dag over dit onderwerp sprak.
De timing kon voor mij niet beter zijn geweest. Bij Wirehive waren we bezig met de overstap van SSH-sleutels naar SSH-certificaten, dus authenticatie en identiteit kwamen bijna dagelijks ter sprake. We dachten al na over hoe asymmetrische cryptografie gedeelde geheimen (shared secrets) in één deel van de stack kon vervangen, en toen beschreef Steve hoe hetzelfde idee zou kunnen werken voor het inloggen op websites.
Het klikte onmiddellijk. Ik herinner me dat ik dacht dat dit veel interessanter was dan nog een wachtwoordbeheerder of een nieuwe poging om wachtwoorden iets minder verschrikkelijk te maken. SQRL stelde een grotere vraag: "Wat als we simpelweg zouden stoppen met het gebruik van wachtwoorden?"
Het concept hield in dat je aan elke website een andere cryptografische identiteit zou presenteren. Er zou geen wachtwoord zijn om te onthouden of te hergebruiken, en er zou geen gedeeld geheim in een database staan dat gestolen kon worden. Een phishing-site zou vrijwel niets van waarde kunnen onderscheppen. Publieke sleutelcryptografie deed het werk, terwijl de authenticatie zelf bijna uit het zicht verdween.
Ik was er dol op.
Ik ben er vrij zeker van dat ik Robin kort daarna heb overtuigd om SQRL-ondersteuning toe te voegen aan het Wirehive-portaal. Dat is hoe we destijds werkten. Als we iets interessants vonden, bouwden we het. Er was geen commissie, geen sturingsgroep of een ontdekkingstraject van zes maanden. Iemand verdween een paar dagen en meldde dan terloops dat hij ondersteuning ervoor had toegevoegd.
Als ik terugkijk, mis ik dat.
Een tijd lang volgde ik SQRL op de voet en verwachtte ik dat dit de richting was die authenticatie op zou gaan. Daarna gebeurde er niet veel meer. Er waren implementaties en een toegewijde gemeenschap, maar SQRL kwam nooit veel verder dan die gemeenschap. Na verloop van tijd hoorde ik er weinig meer over.
Een decennium later zijn passkeys ingebouwd in besturingssystemen, browsers en wachtwoordbeheerders. Banken en identiteitsproviders voor bedrijven nemen ze over. Wachtwoordloze authenticatie is verschoven van beveiligingspodcasts naar producten die gewone mensen gebruiken zonder dat ze de onderliggende cryptografie hoeven te begrijpen.
Telkens wanneer ik die vooruitgang zie, denk ik aan SQRL in volwassen vorm.
De architecturen zijn verschillend. Moderne passkeys maken afzonderlijke inloggegevens (credentials) aan voor elke dienst en kunnen deze synchroniseren tussen apparaten. SQRL leidde de identiteit van elke website deterministisch af uit een hoofdidentiteit. Ze maakten verschillende technische keuzes, maar vertrokken vanuit hetzelfde uitgangspunt: mensen zouden geen gedeeld geheim hoeven te onthouden voor elke dienst die ze gebruiken.
Ik heb nooit bewijs gezien dat de FIDO Alliance heeft voortgebouwd op het werk van Steve Gibson, en ik beweer niet dat er een directe lijn loopt van SQRL naar WebAuthn of passkeys. Authenticatie met publieke sleutels bestond al vóór SQRL, en veel slimme mensen werkten destijds aan wachtwoordloze authenticatie.
Toch verdient Steve erkenning voor het tonen — in concrete technische details — hoe wachtwoordloze webauthenticatie zou kunnen werken, jaren voordat de industrie klaar was om dit op grote schaal uit te rollen.
Het grootste probleem van SQRL was coördinatie. Hoe elegant het protocol ook was, browsers, besturingssystemen, websites en gebruikers moesten allemaal gelijktijdig overstappen voordat het een normale manier van inloggen kon worden. Dat is nooit gebeurd.
Passkeys bereikten hetzelfde terrein via een andere route. Apple, Google en Microsoft steunden gemeenschappelijke standaarden en integreerden deze in hun platforms. Browsers kregen ondersteuning, wachtwoordbeheerders volgden, en websites konden passkeys adopteren zonder gebruikers eerst te moeten overtuigen om een onbekend authenticatiesysteem op te zoeken.
Die ondersteuning is precies wat SQRL miste. Inloggen met publieke sleutels werd praktisch omdat de software die mensen al gebruikten dit ongeveer op hetzelfde moment begon te ondersteunen.
We hebben de neiging om de technologie te onthouden die standaard is geworden en de mensen te vergeten die het idee eerder hebben gedemonstreerd. SQRL is niet de authenticatiestandaard voor het web geworden, maar het liet zien hoe wachtwoordloze authenticatie eruit zou kunnen zien lang voordat de grootste platformleveranciers er klaar voor waren om dit te leveren.
Elke keer als ik iets ontgrendel met een passkey, denk ik terug aan die rit naar mijn werk en het binnenstappen in het Wirehive-kantoor, waarbij ik iedereen die wilde luisteren probeerde uit te leggen waarom dit vreemde ding genaamd SQRL zomaar de toekomst zou kunnen zijn.
Zoals blijkt, denk ik niet dat ik ongelijk had. Ik hoorde er alleen tien jaar eerder over dan alle anderen.