Mi piace l'idea, ma anch'io ho molte domande lasciate aperte. Si prega di non vedere questo come una forma di piagnisteo, perché l'ho scritto cercando di applicare la mia esperienza di autenticazione a questo nuovo schema.

Sono preoccupato per (in nessun ordine particolare):

1. Uso non autorizzato della chiave privata
2. Supporto client avanzato (Outlook, Note, ecc.)
3. Utilizzo da più computer
4. Protezione della chiave privata o crittografia (sul client)
5. Autenticazione delle richieste di generazione della chiave
6. Privacy

Dettagli sotto. Prima un riassunto di una riga (in grassetto corsivo ) e alcuni chiarimenti.

1. Uso non autorizzato della chiave privata

La chiave privata sarà protetta dal client, con vari gradi di sicurezza.

Sono preoccupato che qualsiasi chiave privata venga utilizzata senza il mio consenso. Quando si tenta di autenticare, avrà luogo un'operazione di firma. Devo essere avvisato prima che venga utilizzato, altrimenti uno script canaglia potrebbe convincere il mio browser a firmare un ticket di accesso e inviarlo. Lo script canaglia potrebbe provenire da un widget, da un add o da un altro XSS. L'implementazione di questo meccanismo varierà in ogni browser, e anche su piattaforme diverse per lo stesso browser, o versioni diverse, ecc. Con una visuale piuttosto incoerente, gli utenti corrono un rischio maggiore di essere attirati per approvare una richiesta di accesso.

2. Supporto client avanzato (Outlook, Note, ecc.)

È stato progettato per funzionare con gli account di posta elettronica. I client di posta "grassi" aziendali sono in qualche modo lasciati indietro.

Perché l'ID del browser funzioni, è necessario un browser che lo supporti. Nel frattempo, alcuni browserid.org hanno rilasciato "shim JavaScript che implementa la funzionalità mancante utilizzando le tecniche HTML5 standard e le routine di crittografia implementate in JavaScript".

Gli utenti in un ambiente aziendale che utilizzano client di posta grossa (Outlook, Notes, Thunderbird) saranno in ritardo, perché il protocollo dovrà essere implementato anche in quei client. Per non parlare del fatto che Outlook non condivide un keystore con Firefox o Thunderbird con IE.

3. Utilizzo da più computer

Porta a una proliferazione di chiavi private, perché lo schema non ha un'autorità centrale.

E c'è un problema di mobilità. Dovrò registrarmi (generare una chiave privata) per ogni computer che uso. Come faccio a cancellare la mia chiave privata in un chiosco Internet o in un computer preso in prestito? Anche con un singolo computer, come posso revocare una chiave memorizzata in un computer rubato? Poiché per un singolo utente, più chiavi di firma sono valide (poiché ogni mio computer ha una propria chiave privata valida), dal punto di vista del fornitore di servizi, qualsiasi token di accesso firmato da un'autorità nota deve essere valido.

4. Protezione della chiave privata o crittografia (sul client)

L'accesso alla chiave deve essere autenticato, il che riporta le password nella foto.

Può essere protetto da una password (limitando il suo riutilizzo malevolo), ma se dovessi cambiare la mia password da qualche parte, non si sincronizzerà a meno che non utilizzi una rete di sincronizzazione basata su browser / cloud. Avere una password da ricordare in qualche modo sconfigge lo scopo di questo schema. È probabile che la stessa password verrà utilizzata per proteggere ogni chiave, proprio come la stessa password viene utilizzata ora per l'autenticazione su più siti Web.

5. Autenticazione delle richieste di generazione della chiave

C'è una discrepanza tra la richiesta di accesso e la generazione della chiave, che un utente malintenzionato potrebbe utilizzare per il phishing.

Non mi è chiaro in che modo l'autorità di certificazione / provider di posta elettronica gestirà i problemi di CSRF. Come faranno a sapere che una richiesta di generazione di chiavi è legittima? La mia cartella spam verrà riempita con richieste di generazione di certificati? O il tasto verrà emesso solo con i server di posta DKIM? Cosa succede se la richiesta è stata intercettata sul suo modo SMTP al server, potrebbe essere modificata?

6. Privacy

L'utilizzo di un tag consente a browserid.org di rompere lo stesso criterio di origine.

E l'utilizzo di un tag script per includere browserid.js consente loro di aggirare lo stesso criterio di origine. BrowserID.org avrà (ha il potere di) conoscere ogni tentativo di accesso che fai. Oppure dovrai ospitare lo script tu stesso (assumendo che sia autonomo) e aggiornarlo se / quando verranno identificati difetti di sicurezza in esso.

Lo scambio di stack ha anche un confronto dettagliato di BrowserId e WebID . Come sostenuto, BrowserId è molto vicino a WebID (un gruppo di incubatori W3C al W3C). Ecco alcuni punti che devono essere fatti in difesa di entrambi i protocolli perché sono molto diversi da come la crittografia a chiave pubblica viene solitamente eseguita.

1. Uso non autorizzato dello script della chiave . D'accordo che questo dovrà essere implementato con molta attenzione dalla gente BrowserID. Come si basa WebID costruito in certificati del browser che sono stati in giro per 13 anni, I pensa che questa parte sia stata trattata molto tempo fa: -)
2. Se desideri il supporto per i client Rich , utilizza WebID. Richiede solo un TLS layer - ottimizzato un po 'sul lato server. Tutti i sistemi operativi e tutti i linguaggi di programmazione sono dotati di TLS integrato.
3. Utilizzo da più computer : sia BrowserID che WebID consentono di avere un numero qualsiasi di certificati, uno per ogni computer. Questo non è un problema. Per WebID vedi questo video Creazione e utilizzo WebID in 4 minuti

4. Crittografia della chiave privata sul client : tutti i computer moderni sono dotati un portachiavi che memorizza password e chiavi e che sono protetti con una password.

   C'è molto che i fornitori di sistemi operativi possono migliorare per migliorare sicurezza qui. Su OSX mi viene richiesta una password speciale e posso dare diversi strumenti per accedere al portachiavi più o meno facilmente. Ovviamente il il portachiavi non dovrebbe MAI dare la chiave privata. Dando la chiave pubblica non è affatto un problema: -)

   Ma ovviamente per i desktop si può andare ancora oltre e utilizzare i tasti di crittografia come mostrato nel video Cryptokeys, WebID e Internet caffè - anche se richiederebbe venditori di browser per migliorare l'interfaccia utente. Qui hai un hardware token per garantire che la chiave privata non sia stata copiata. Comunque per BrowserID avrebbero bisogno di integrarlo nel portachiavi, o trovare un modo JavaScript per inviare certificati x509 memorizzati nel file portachiavi sul filo.

5. Autenticazione delle richieste di generazione della chiave : l'utilizzo della posta elettronica è pratico ma intrinsecamente pericoloso. La gente lo sta ancora usando e il vantaggio di BrowserID è che funziona con questo, senza richiedere l'aggiornamento delle persone a TLS. WebID funziona su tutto il TLS, quindi è possibile ottenere la sicurezza commerciale fuori dalla scatola.
6. Privacy : io non sono molto bravo con JavaScript e lo ho sul mio elenco di cose da imparare - divertendosi troppo ora con Scala. Ad ogni modo, non posso commentare questo problema JavaScript con BrowserId - ma piacerebbe capirlo meglio Con WebID non c'è JavaScript coinvolti al momento, quindi non esiste un problema di politica di origine identica da affrontare. La selezione di identità è direttamente nel browser, come mostrato con video menzionato sopra.

Oh Dio! Dovrei creare un account qui ancora una volta per pubblicare questo commento! Non c'è da stupirsi che Facebook abbia distrutto la Blogosfera. Lì hai solo bisogno di 1 password e puoi commentare tutto ciò che desideri.

Invio una risposta ai sei punti della risposta accettata come nuova risposta ...

1. Uso non autorizzato della chiave privata

Nel caso dell'implementazione del browserID Javascript, la chiave privata è memorizzata in memoria locale sotto il dominio login.persona.org. Quindi uno script canaglia dovrebbe essere ospitato su quel dominio per avere accesso ad esso. Gli script ospitati altrove possono accedere alla chiave solo indirettamente tramite una postMessage API basata su restrizioni

2. Supporto client avanzato (Outlook, Note, ecc.)

BrowserID funziona con qualsiasi account e-mail o client di posta. Lo shim Javascript è lì per supportare i browser senza un'implementazione nativa. Nulla deve essere aggiunto ai client di posta.

3. Utilizzo da più computer

Una cosa importante da sottolineare qui è che le chiavi sono di breve durata. Se sei su un chiosco Internet, le chiavi sono valide per 1 ora, se sei sul tuo dispositivo, sono valide per 1 giorno. Ne verrà generato uno nuovo quando necessario una volta scaduto, a condizione che tu sia ancora autenticato con login.persona.org. Nessuna necessità di backup.

Se vuoi cancellare la tua chiave privata, cancella i cookie (che cancellano anche la memoria locale - dove sono memorizzate le chiavi).

Se il tuo computer viene rubato, c'è una piccola finestra durante la quale un utente malintenzionato può usare la chiave, ma finché cambi la password su login.persona.org , la login.persona.org verrà invalidata e il ladro non sarà in grado di ottenere una nuova chiave.

4. Protezione della chiave privata o crittografia (sul client)

Per ottenere una nuova chiave firmata dal tuo provider di identità, devi essere autenticato con esso. Se l'autenticazione scade, dovrai digitare nuovamente la password. Questo è simile alle sessioni basate sui cookie che sembrano essere la norma sul web.

La chiave privata non è così importante perché è di breve durata. A tale riguardo, ha più in comune con i cookie che con i certificati client X.509.

5. Autenticazione delle richieste di generazione della chiave

Il provider di identità sa che una richiesta è legittima perché l'utente è autenticato con loro. Il provider di identità di fallback firma solo le chiavi dopo che ha confermato la proprietà dell'indirizzo email (nello standard "invia agli utenti un collegamento con un token casuale per fare clic sul modo").

La generazione / firma del certificato avviene tra il browser e il provider di identità tramite un'API JavaScript. Non si basa sull'invio di e-mail, pertanto gli utenti non riceveranno e-mail oltre al messaggio "Conferma il tuo indirizzo email" che il provider di identità di fallback invia all'ora di creazione dell'account.

6. Privacy

Una volta che l'API è abbastanza stabile, per gli altri sarà possibile ospitare include.js . Al momento, ti consigliamo di non farlo.

Un altro punto in cui persona.org può vedere i siti ai quali accedi è con lo strumento di verifica online a https://verifier.login.persona.org/verify . Una volta risolto il formato dei dati, incoraggeremo le persone a verificare le asserzioni stesse (ad esempio utilizzando una libreria Open Source) e persona.org non otterrà più questi dati.

BrowserID è progettato per essere un protocollo completamente decentralizzato per consentire la privacy reale. Tuttavia, fornisce anche fallback centralizzati per aggirare l'attuale mancanza di supporto nativo.

Uno svantaggio di BrowserID nella sua forma attuale rispetto a alcuni delle alternative è che qualsiasi cosa oltre la funzionalità di base è difficile: l'ulteriore scoperta di informazioni richiede altri protocolli come WebFinger, mentre ad es. un URL OpenID può fornire collegamenti. Ad esempio, è difficile ottenere un nome visualizzato o un'immagine del profilo da BrowserID (sebbene, dal momento che BrowserID ti fornisce un indirizzo email, puoi ottenere quest'ultimo da Gravatar).

Un altro protocollo concorrente da aggiungere alla lista: WebID: link

Per informazioni più estese su BrowserId / Persona, alla fine ho trovato ciò che Daniel ha contribuito alla relativa Q & A su BrowserId / Persona e WebID . (Ho cercato di convincerlo a postare qui, ma mi ha suggerito di farlo.)

Requisiti di sicurezza, privacy e usabilità per l'identità federata di Michael Hackett e Kirstie Hawkey forniscono un confronto tra WebID e Mozilla Persona, che al momento era ancora indicato come BrowserID.

Le principali differenze rilevate (nella Tabella 1) sono:

• Le chiavi delle persone sono di breve durata e dovrebbero essere protette con una password. Le chiavi WebID sono longeve ma possono essere facilmente disabilitate da un profilo protetto da password.
• L'attuale implementazione di Persona utilizza finestre standard del browser, quindi è difficile individuare lo spoofing (questo potrebbe cambiare una volta che i browser avranno il supporto nativo per Persona). WebID utilizza l'interfaccia utente di selezione del certificato nativo del browser, quindi nessuna possibilità di phishing.
• Le identità di Persona e WebID possono essere compromesse se il controllo sull'e-mail / URI del proprietario viene perso.
• Gli IdP di persone non hanno conoscenza degli SP che utilizzano un'identità. Gli IdP WebID conoscono ogni SP che utilizza un'identità.
• Se un SP persona ha una cache della chiave pubblica di IdP e il browser ha ancora un certificato valido, dovrebbe essere ancora possibile verificare le identità. I profili WebID devono essere raggiungibili altrimenti le identità non saranno utilizzabili.
• Persona ha un buon design UX, mentre WebID è l'opposto.

Suggerisco di leggere la carta per ulteriori dettagli. È disponibile gratuitamente online, non è necessario l'accesso alle librerie digitali.