Mozilla lanserte sin BrowserID prosjektet i juni som et alternativ til det nå vanlig praksis for å stole på tredjeparts kommersielle webtjenester som " identitets meglere ". Hvis du ønsker å tilby brukerne en ikke-påtrengende måte å etablere en identitet, uten overhead og sikkerhet bekymringer av en vanskelig off-site autorisasjonsprosessen, er det verdt å ta en titt.

BrowserID lar eiere tilby sin besøkende en måte å logge inn og legge inn kommentarer eller bruke web-applikasjoner, men en som er avhengig bare på e-post adresse verifisering:. no per-site passord, ingen sentraliserte, eksterne identitetsleverandører

Den fugleperspektiv Anmeldelser

I motsetning OpenID, som assosierer hver " desentralisert " identitet med en bestemt nettadresse som brukeren er ansvarlig for å opprettholde, gjelder BrowserID e-postadresser som brukerens identitet. Alle har en e-postadresse, og de allerede ser det som personlig identifikator – uten ekstra konseptuelle arbeidet som kreves

påloggingen for en BrowserID-kompatibel stedet starter med området ber om en e-postadresse og proof-of-eierskap. (som kalles en " påstand " i offisielle BrowserID språkbruk) . I den enkle metoden, for å kunne logge inn, brukerens nettleser og e-postleverandøren vil begge trenger å støtte påstanden generasjon prosess, men det er bestemmelser for arbeid rundt dette. I alle tilfelle, men det er generert, returnerer leseren en påstand som inkluderer e-postadresse i spørsmålet, et " utløpsdato " (slik at ne'er-do-brønner ikke kan fange opp og replay pålogginger senere), og en adresse-eierskap sertifikat.

Den påstanden er i JSON-format, men det er også kryptografisk signert med en privat nøkkel som aldri forlater leseren maskinen. Området kan bekrefte gyldigheten av påstanden fordi eierskap sertifikat inneholder offentlig
tasten som er tilknyttet den private nøkkelen som signerte

Faktisk inneholder sertifikatet tre deler:. Den offentlige nøkkelen, e-postadressen, og en annen " utløpsdato " – dette en for selve sertifikatet, ikke for den påstanden. Selve sertifikatet er signert av e-postleverandøren, ved hjelp av e-postleverandøren nøkkel (ikke brukerens tasten). Området kan sjekke at signaturen ved å spørre den e-postleverandøren.

Så til slutt området sjekker to utløpsdatoer og to signaturer. Nettstedet bekrefter at det kan stole på påstanden ved å sjekke brukerens signatur på påstanden, og det bekrefter at det kan stole på sertifikatet ved å sjekke e-postleverandøren underskrift på sertifikatet. Påstanden utløpsdato er trolig ganske kortsiktig, fordi brukeren ikke ønsker å bo logget inn for dager om gangen. E-postleverandøren kan bestemme hvor lenge utløpsdatoen på sertifikatet er.

I øyeblikket Gmail krever at brukerne å re-log-in omtrent en gang annenhver uke. Det ville være en rimelig høy levetid for et sertifikat, selv om BrowserID utviklere tyder mye kortere tid, nærmere nettleser-session-levetid. På den måten er det aldri behov for å " tilbakekalle " et sertifikat, fordi det raskt vil utløpe på egen hånd. Når brukeren trenger å generere en ny
sertifikat, han eller hun ville gjøre det ved å gå til postleverandøren. Her igjen, kan prosessen variere litt, men generelt sett, vil nettleseren inkludere innebygde rutiner for å generere nøkkelpar trengs. Det er en subtil, men stor seier; vurdere hvor vellykket verk-in-the-bakgrunn krypten av SSL er sammenlignet med make-the-user-do-it tilnærmingen tatt av OpenPGP.

Implementering og Sikkerhet

Selvfølgelig , i øyeblikket de fleste av verdens e-postleverandører ikke utføre BrowserID sertifikat generasjon prosess eller signatur-kontroll av prosessen. Protokollen inneholder et middel for sekundær domene å utstede et sertifikat med en utstedt-by-feltet, og Mozilla kjører en server hos browserid.org å sørge for at sekundær service.

Fra et sikkerhetssynspunkt, et nettsted eieren ville ikke ønsker å stole på bare en vilkårlig domene som sier det kan signere for en brukers e-postadresse – sekundær modellen er spesielt designet for å være troverdig fordi browserid.org domenet er administrert av nettleseren maker i spørsmålet (i dette tilfellet, Mozilla). Den sekundære tjenesten må bruke et egnet middel til å verifisere eierskapet til angitte e-postadressen. Browserid.org gjør dette ved hjelp av standard send-a-verifikasjon-post teknikker, hvor e-postbekreftelse inneholder en klikkbar lenke.

På nettleser-side, avhengig av protokollen på noen nye klientsiden funksjonalitet, for eksempel navigator.id.registerVerifiedEmail () og navigator.id.getVerifiedEmail (). Serverne er involvert i sign-in og sertifisering generasjon prosessen vil kalle en av disse funksjonene, og påberope riktig nettleserfunksjoner. Utvikling bygger på Firefox inneholde den nødvendige koden, men det kan også bli implementert i Javascript for å støtte andre nettlesere. Mozillas BrowserID lag har et eksempel nettstedet kjører på myfavoritebeer.org som fungerer i Chrome, eldre versjoner av Firefox, og andre støtter Javascript lesere.

Den ikke-native klient metode har sine egne sikkerhetsrisikoer. Når området (som myfavoritebeer.org) lagrer sertifikater og nøkler lokalt, den bare har tilgang til nettleserens HTML5 lokal lagring område. Det er en sikkerhetsvegg reist for å holde områdene fra å ha full skrivetilgang til brukerens harddisk, men i dette tilfellet er det mulig at en annen ondsinnet nettsted kunne finne en helhet og tukle med lokal lagring sertifikater og nøkler. En innfødt leseren gjennomføring vil være bedre, fordi det kan få tilgang til mer sikre områder som din Firefox profil, som allerede lagrer sensitiv informasjon som passord og cookies.

BrowserID er faktisk en forenkling av bekreftet Email Protocol, med den ekstra nytte at det ikke er avhengig av webfinger eller andre eksterne teknologier til også
bli gjennomført av serverne involvert.

Naturligvis, selv i den sterkeste tilfellet er BrowserID bare så sikker som din e-postkonto . La deg selv logget på Yahoo eller Gmail når du er borte fra kontoret, og alle kan kapre din identitet på en BrowserID stedet. Men det er minst sikrere enn å legge et annet sett med brukernavn og passord til listen over ting du må huske. Hvis du ikke tar vare på din e-post passord, er du allerede har høy risiko

Side Adopsjon

Det er dokumentasjon på BrowserID side om gjennomføringen av protokollen som en påloggingsalternativ for området, samt grunnleggende utvikler dokumentasjon av protokollen selv. Kanskje den enkleste måten å bli kjent med BrowserID, derimot, er å prøve browserid.org tjenesten selv. Jeg fant ut at dette kan klare opp en rekke enkle å forvirre deler av håndtrykk prosessen. For eksempel, kommenterte flere personer på Mozilla blogginnlegg og diskusjonsgrupper som spør hvordan BrowserID klarer med å logge inn fra flere maskiner. Svaret er at du får et eget nøkkelpar generert på hver klient; med en browserid.org konto, kan du se alle dine nøkkelpar

Utviklere begynner å arbeide på BrowserID test implementeringer for eksisterende web rammeverk.; kan du allerede teste en WordPress plug-in og en Drupal modul. Men prosessen er fortsatt i utvikling — et faktum Mozilla-teamet er ganske åpen om.

For de som fortsatt er forvirret om hvordan BrowserID skiller seg fra andre desentralisert identitets tjenester som OpenID er en god leser Ben Adida blogginnlegg på forskjellene mellom de to. Den korte versjonen er at BrowserID kan implementeres direkte i nettleseren (som gir ett færre partier deg som bruker må stole med din private informasjon), og mindre forvirrende forholdet mellom nettstedet du forsøker å logge inn på og det partiet som går god for identiteten din.

Nye godkjenningsmetoder er alltid kontroversielt i starten, og sikkerhets mavens er i sin natur skeptiske. Så du bør forvente mye diskusjon om BrowserID i de kommende månedene. En ting er sikkert, skjønt – en identitet system som ikke er avhengig av kommersielle tjenester er noe som brukerne er etterlyst for, og BrowserID tilbyr en forholdsvis enkel implementering støttet av sterk kryptografi. Anmeldelser