Mozilla presenteert eigen 'single sign on'-framework

Mozilla heeft een framework gepresenteerd waarmee websitebouwers hun gebruikers via een en hetzelfde systeem kunnen laten inloggen. 'BrowserID' moet uiteindelijk in browsers worden ingebouwd, maar werkt nu al via een pop-up.

BrowserID werkt op basis van e-mailadressen: gebruikers hoeven enkel een e-mailadres en wachtwoord op te geven om op een website in te loggen. Ontwikkelaars kunnen hun eigen login-systeem vervangen door BrowserID, waarbij gebruikers een BrowserID-pop-up krijgen om in te loggen. Uiteindelijk moet die pop-up worden vervangen door native browsersupport, maar wanneer die er komt, is onbekend. Het ligt voor de hand dat in ieder geval Mozilla's eigen Firefox-browser van ondersteuning wordt voorzien.

BrowserID is eenvoudig in een website te integreren door een javascript-bestand van de BrowserID-server te laden en een paar regels javascript-code in te voegen voor het afhandelen van de logins. Om te controleren of een gebruiker is ingelogd, dienen ontwikkelaars een ajax-call naar de BrowserID-servers te maken. Voor authenticatie wordt public key cryptography gebruikt.

Het is de bedoeling dat bijvoorbeeld e-mailproviders als authenticatieprovider gaan meewerken aan het framework, zodat er geen apart BrowserID-account hoeft te worden aangemaakt: inloggen met het e-mailaccount is dan al genoeg. Volgens Mozilla kunnen zowel de BrowserID-servers als andere authenticatieproviders niet zien welke websites worden bezocht.

Helaas!
De video die je probeert te bekijken is niet langer beschikbaar op Tweakers.net.

Reacties (37)

[Verwijderd]

Wat bied dit ten op zichte van een Openid?
Lijkt een beetje hetzelfde als ik het zo lees.

[Rob Coops]

OpenID is nog al lastig omdat het tot op heden niet echt makkelijk was op te zetten, op het moment gaat het een stuk makkelijker omdat er verschillende aanbieders zijn die dit mogelijk maken op een simpelere wijze maar toch OpenID is tot op heden niet echt van de grond gekomen.

OAuth (aangeboden door onder andere Google, Twitter, Facebook en Yahoo), is een veel meer gebruikte techniek die op veel sites in middels mogelijk is.

Dit lijkt nog het meeste op de tweede optie waarbij een gebruiker bijvoorbeeld inlogged op zijn Google account. Technisch gezien is dat namelijk de zelfde oplossing gebruiker klikt op login en wordt naar een Google pagina gestuurd daar wordt gekeken of de gebruiker is ingelogged (zo niet wordt een inlog scherm getoont) en als de gebruiker is ingelogged of de gebruiker deze website toestemming heeft gegeven om zijn Google account te gebruiken om in te loggen, als dat is wordt de gebruiker terug gestuurd naar de site met informatie van de Google server. De informatie bevat niet veel meer dan gebruikers nickname naam Google account ID en de URL waar de gebruiker weer kan uitloggen uit de Google account.
Dit zelfde kun je ook bij alle andere OAuth aanbieders doen natuurlijk.

Ik zie in deze nieuwe oplossing eigenlijk niets anders dan wat OAuth al bied en ik vermoed dat de techniek er achter waarschijnlijk gewoon een OAuth implementatie is maar dit keer met een Mozilla account. Ik denk dan ook dat veel sites dit gewoon zullen toevoegen als een extra optie naast de optie om in te loggen met je Google, Facebook, Yahoo, Twitter etc account.

[J-San]

Wat jij beschrijft is wat openid doet. oauth is een techniek om website x op jouw Twitter account te laten inloggen zonder hier bij jouw wachtwoord aan website x te overhandigen.

[Rob Coops]

@J-San
Dat is waar alleen is het delen van deze informatie wel iets dat je apart moet goedkeuren, en niet iets dat zo maar mogelijk is.

@tiddo3
Dit systeem mag dan alleen op inloggen gericht zijn maar in principe is OAuth niet veel anders alleen heeft het als extra voordeel dat je ook optioneel data kunt delen. De techniek lijkt me dan ook nog steeds niets anders alleen heeft Mozilla op het moment voor zo ver wij weten geen data over ons op geslagen op haar servers dus valt er weinig te delen.

Het lijkt me een handig iets als het onderdeel van een browser is maar dat werkt alleen als iedere gebruiker op een PC een eigen account heeft omdat je anders steeds maar inlogged als je moeder of collega en dat kan toch best lastig zijn

Persoonlijk geef ik althans op basis van de info die ik er tot noch toe over gelezen heb de voorkeur aan een G, F, T, Y etc account omdat dat net even makkelijker is juist omdat je ook zo makkelijk informatie kunt delen en zo lang je dat zelf goed in de gaten houd is het helemaal zo vervelend nog niet.
Kijk bijvoorbeeld maar eens naar veel Facebook apps die toegang tot alles willen hebben vaak kun je 90% daar van weer uitzetten zonder dat de app dienst weigert, zo niet gewoon weg donderen en de concurrerende app gebruiken

[Verwijderd]

Er zit alleen wel 1 verschil met het OAuth systeem: Bij OAuth moet je meteen bijvoorbeeld een google account hebben, wat veel meer is dan alleen maar een login-mogelijkheid. Met dit systeem is je account niks meer dan een email-adres met een wachtwoord om overal mee in te loggen.

Bovendien is OAuth ook gericht op het delen van gegevens tussen sites. Dit systeem is echt alleen gericht op het inloggen. Dit is dus gewoon veel simpeler en eenvoudiger, en voor een hoop dingen dus beter.

[sab]

Dat een OpenID provider wel kan zien op welke sites je allemaal inlogt.

[Verwijderd]

Alsof we er hier nog niet genoeg van hebben. Met Google, Twitter en Facebook kan je op de meeste grote sites inloggen. En anders hebben we ook nog OpenID.
Vind het dus een beetje overbodig, tenzij het een meerwaarde heeft ( die ik nog niet zie ).

[BumEyes]

Het was even zoeken, maar volgens mij is er wel een meerwaarde in BrowserID. Voor de gebruiker is het namelijk simpeler.

Met OpenID gebruik je een endpoint/url om je te identificeren. Ik heb hier minstens drie van:

• myopenid.com/mijnnaam
• google.com/accounts/o8/f123456789abcdef
• mijnsite.com

Bij het inloggen moet je kiezen welke je wil gebruiken, dit gaat gewoonlijk via een interface waar je eerst de provider kiest, waarna je via een paar redirects wordt ingelogd. Elke keer als je inlogt op dezelfde site moet je dezelfde endpoint gebruiken.

Nou is dit voor ons nerds misschien redelijk te bevatten, je hoeft er alleen maar voor te zorgen dat je altijd dezelfde kiest. Voor de meeste gebruikers is dit verwarrend. Ze klikken op de verkeerde provider en kunnen niet inloggen, of ze weten niet wat ze moeten doen en vertrekken gewoon. De voornaamste reden dat openid niet werkt is omdat gebruikers het niet snappen.

BrowserID doet dit anders, zij gebruiken je e-mailadres om je te identificeren. Dit maakt het makkelijker. Gebruikers kiezen geen provider maar vullen hun e-mailadres in. Als mijn e-mailprovider ook BrowserID provider is ben ik direct ingelogd. Als mijn e-mailprovider dat niet ondersteund kan ik mijn adres ook bij BrowserID registreren, dan werkt die als provider.

In plaats van inloggen met een van mijn 3 openids (of facebook of twitter), kan ik straks gewoon inloggen met BrowserID. Daar heb ik er maar 1 van.

Veel eenvoudiger dan dat wordt het niet!

[Reactie gewijzigd door BumEyes op 23 juli 2024 22:19]

[Aham brahmasmi]

Het was even zoeken, maar volgens mij is er wel een meerwaarde in BrowserID. Voor de gebruiker is het namelijk simpeler.

Met OpenID gebruik je een endpoint/url om je te identificeren. Ik heb hier minstens drie van:

• myopenid.com/mijnnaam
• google.com/accounts/o8/f123456789abcdef
• mijnsite.com

Bij het inloggen moet je kiezen welke je wil gebruiken, dit gaat gewoonlijk via een interface waar je eerst de provider kiest, waarna je via een paar redirects wordt ingelogd. Elke keer als je inlogt op dezelfde site moet je dezelfde endpoint gebruiken.

Nou is dit voor ons nerds misschien redelijk te bevatten, je hoeft er alleen maar voor te zorgen dat je altijd dezelfde kiest. Voor de meeste gebruikers is dit verwarrend. Ze klikken op de verkeerde provider en kunnen niet inloggen, of ze weten niet wat ze moeten doen en vertrekken gewoon. De voornaamste reden dat openid niet werkt is omdat gebruikers het niet snappen.

+1 Ik ben genoeg technisch onderlegd, maar een inlogsysteem moet simpel simpel in elkaar zitten, anders laat ik het ook gewoon zitten. Ik gebruik het ook niet vaak genoeg, maar de eerste keer dat ik OpenID probeerde ging het ook niet meteen goed.

[Sjah]

Js maar daar zit allemaal een addertje (belangen?) achter, Mozilla heb ik zo hoog zitten, dat ik liever hun oplossing kies. Zal mijn fout wezen.

[SuperDre]

En jij denkt dat dat addertje ook niet bij mozilla zit? think again...

[Sorcix]

Als je inlogt met Google op een andere site dan is dat trouwens óók met OpenID. Al heeft google wel enkele wijzigingen gemaakt.

[bitflusher]

Naar mijn mening zijn er inderdaad genoeg alternatieven. er zijn er inderdaad zoveel, je noemt er zelf een aantal, er is er geen waar je overal mee terecht kan. Ik zie wel wat in een single sign in voor alle single sign networks.

[RielN]

NIks zo veilig als verschillende wachtwoorden. Je hebt toch ook niet een sleutel voor je deuren?

Veiligheid kost nu eenmaal wat moeite

[_wm_]

Het idee is dat je ipv het onthouden van 10 simpele wachtwoorden gewoon 1 ingewikkelde onthoudt die veel minder snel te kraken is. Tenminste, het lijkt me inderdaad wel handig dat je dat ene wachtwoord goed sterk maakt

[Verwijderd]

Punt is dat wachtwoorden kraken heel moeilijk is.

Systemen kraken daarintegen, gebeurt nogal regelmatig, en is een kwestie van de zwakste schakel uitbuiten.

Wachtwoorden van 8 tekens zijn goed te onthouden, en als er cijfers en letter in zitten heb je al genoeg veiligheid (36⁸ = 3 x 10¹² mogelijkheden... zat).

Als je dan 4 verschillende wachtwoorden hebt zit je goed. Dubbel gebruik van wachtwoorden kan, zolang je beide sites vertrouwt (bv. je google en yahoo email account), én als de accounts niet aan elkaar te linken zijn.

Daarnaast heb je nog een probleem; er moet altijd een partij zijn die een database heeft met de loginsystemen van iedereen die dit "single sign-on" systeem gebruikt. Deze database wordt dus heel... geliefd bij crackers. Waar een onbenullig, makkelijk te kraken website'je dus gespaard word, kan een goed beveiligde grote website dus wel op de knieën worden gebracht.

Centralisatie is goed voor het gebruikersgemak, maar vrijwel altijd negatief voor veiligheid.

[DDemolition]

Als je er van uit gaat dat de programmeur een hash (en eventueel een salt) gebruikt.
Ik wil ze niet in de kost hebben die het niet doen...

[Verwijderd]

Over het algemeen gebruik ik gewoon een whirlpool hash met een random salt per user.
Dan kunnen ze geen rainbow tables gebruiken

[Fred-Erik]

Maar wat is waarschijnlijker: dat iemand jouw specifieke wachtwoord weet te 'kraken', of dat een heel systeem gehackt wordt, waardoor de gegevens van iedereen op straat liggen? Als dat laatste waarschijnlijker is (je hoort het vaak genoeg de laatste tijd), lijkt me meerdere niet bijzonder veilige wachtwoorden veiliger.

[mxcreep]

Nog veiliger : geen wachtwoorden, RSA keys met daarop weer een wachtwoord...

[niki_lauda]

@ ReiIn

Ik heb idd een sleutel voor al de deuren van mijn huis. Makkelijk joh

[Reactie gewijzigd door niki_lauda op 23 juli 2024 22:19]

[reckik]

een loper bedoel je

[Cubic X]

Opzich een prima idee! Heb inmiddels tig wachtwoorden en gebruikersnamen en (wanneer de cookies/sessies zijn verwijderd) is het soms best nadenken en proberen welke combinatie ook alweer voor de specifieke website is.

Het nadeel is echter dat ALS het systeem gekraakt wordt, wel al je gebruikersnamen en wachtwoorden op straat liggen. Hopelijk is het systeem voldoende veilig .

[Room42]

Het nadeel is echter dat ALS het systeem gekraakt wordt, wel al je gebruikersnamen en wachtwoorden op straat liggen. Hopelijk is het systeem voldoende veilig .

Het is geen database met al je gebruikersnamen en wachtwoorden (zoals bijvoorbeeld Lastpass) maar één enkele authenticator voor verschillende sites. Die sites krijgen alleen een goedkeuring terug (plus je e-mail adres, zoals hier beschreven staat.), verder niets.

Als het gehackt wordt, hoef je dus niet tientallen wachtwoorden te gaan resetten (maar één), maar krijgt de hacker wel direct toegang tot alle sites waarbij je met de authenticator bent ingelogd. Maar dat geldt ook voor de andere providers (Twitter, Facebook, Google, OpenID).

[Reactie gewijzigd door Room42 op 23 juli 2024 22:19]

[Precision]

Maar er staat ook in de tekst dat er niet geweten is waar je ingelogd bent, misschien dat er intern wel logboeken van zijn, zou de server zijde open source zijn?

Edit: blijkbaar wel: https://github.com/mozilla/browserid

[Reactie gewijzigd door Precision op 23 juli 2024 22:19]

[Verwijderd]

Zou graag een aanvullende iPhone App hebben zodat je werkt volgens het "iets wat je hebt, en iets wat je weet principe". Elke keer als ik wil inloggen met browserId, krijg ik een push notification via de iPhone/Android App met een random token die naast het e-mailadres en wachtwoord ingevuld moet worden.

Een soort van RSA SecureId, maar dan gewoon een random token wat niet berekend hoeft te worden omdat de server weet welk random token uitgegeven is.

[BumEyes]

Voor als mensen meer willen weten over het "iets wat je hebt, en iets wat je weet principe": http://en.wikipedia.org/wiki/Two-factor_authentication

[sjongenelen]

Zoals hierboven staat: niets nieuws... Waarom hier resources aan worden besteedt begrijp ik wel, maar nergens voor nodig echter

[Franckey]

Alweer een single-sign-on initiatief. Microsoft heeft het al een paar keer geprobeerd, Google heeft iets, onze overheid heeft DigID en nu Mozilla. Het lijkt er een beetje op dat elke leverancier zijn eigen "single-sign-on" krijgt. Maar dat is nog altijd beter dan bij elke (web)app apart te hoeven inloggen.

[martijnsch]

Waarom bouwen ze OpenID niet in de browser? Het enige bezwaar tegen OpenID is dat je telkens de url van je accountprovider moet invullen. Als je die nou kon invullen in je browser, dan hoef je dat niet te doen voor elke website waar je wilt inloggen. Dan is het alleen nog op Inloggen klikken en vervolgens op Accepteren...

[Verwijderd]

Alle voorgaande reacties hiervoor gaan voorbij aan het fundamentele principe van dit project: decentralisatie en dus betere privacy en data-bescherming. Net als openid maakt dit systeem mogelijk om je eigen authenticatie-systeem te beheren. Het verschil met openid is dat dit systeem niet weet welke websites je bezoekt en dat een email-adres als inlog-token veel logischer voor de gemiddelde gebruiker is dan een url.

Ik heb niet zo graag dat bv facebook alles van mij weet, dus als dit in de browser-omgeving wordt geintegreerd en hopelijk ook door websites wordt ondersteund lijkt me dit een hele belangrijke ontwikkeling

[Verwijderd]

Voor mensen die per site een verschillend email-adres gebruiken is het dan weer niet zo handig...

[Verwijderd]

Misschien is een oplossing zoals de Rabobank gebruikt met de Random Reader iets voor logins. (Zelfde systeem wordt o.a. ook door Blizzard in hun game inlogs gebruikt) je hebt een apparaatje die genereert een code waarmee je in kan loggen.

[Verwijderd]

Dat vind ik een hele goeie!

E-mail is al zo oud en ook redelijk onveilig. Je kan niet bewijzen dat je de afzender bent of iemand anders dat niet is, en ook de link waarop je moet klikken om je BrowserID te bevestigen, gaat zonder enige vorm van encryptie vanaf de BrowserID server naar de mail server van je e-mail adres.

Verder hoeft de BrowserID server helemaal niet te wachten tot je reageert op bevestiging, waardoor het een soort gigantische moedersleutel is voor alle mogelijke accounts. Maar omdat je de BrowserID server toch al moet vertrouwen is dit niet een heel groot probleem.

Ben ook erg benieuwd of er een systeem komt om je wachtwoord te resetten en hoe veilig dat dan weer is.