Comprensione della sicurezza di uno schema a chiave pubblica federato tramite WebCrypto

Question

Comprensione della sicurezza di uno schema a chiave pubblica federato tramite WebCrypto

#1 da (1 voti)

2

Sto proponendo questo schema per l'autenticazione federata e WebCrypto. Non sono sicuro che esista qualcosa di simile (o migliore), per favore inviami materiale correlato.

Enti

Browser di Alice, BROWSER
Il server di Bob, BOB
Il server di Alice, ALICE

Sfondo

Le identità sono nomi di dominio e ogni server ha un elenco di controllo di accesso su ciascuna risorsa.

Bob scrive nel file di controllo degli accessi "alice.com" può leggere "/ foo"
Alice vuole leggere foo

Protocollo

tl; dr versione:

Il browser di Alice tenta di accedere a una risorsa sul server di Bob, risponde Bob con un messaggio non autorizzato e un nonce
Alice genera una chiave nel suo browser con webcrypto e la tiene in memoria
Alice carica la sua chiave sul suo sito web
Alice firma il nonce, l'indirizzo del server bob e l'indirizzo della sua chiave
Bob riceve il messaggio e controlla se la posizione indicata da Alice ha la chiave pubblica che verifica la firma

Schema

1. Alice's Browser tries to access a resource on Bob's server

BROWSER   -------------- GET /foo ---------------------->  BOB
BROWSER   <------------- RESPONSE 401 {nonce} -----------  BOB

2. BROWSER uses WebCrypto to generate Pub/Priv key pair

3. Alice's post her new key on her server

BROWSER   -------------- POST /keys/nonce -------------->  ALICE
                         { Pub }
BROWSER   <------------- RESPONSE 200 -------------------  ALICE

4. Alice's Browser signs the location of the key, the nonce and
   the Bob's Server origin

BROWSER   -------------- POST /foo --------------------->  BOB
                         Sign(location, nonce, bob)

5. Bob's server gets the advertised location

          BOB -------------- GET /keys/nonce --------------->  ALICE
          BOB <------------- RESPONSE {Pub} -----------------  ALICE

6. Bob's server verifies the signature

BROWSER   <------------- RESPONSE 200 -------------------  BOB
                         {set cookie}

Domande

C'è qualche trappola che non vedo?
Si può verificare un attacco nel punto # 4 del diagramma?
Questo schema esiste o ha un nome?

authentication

posta nick 06.05.2016 - 20:09

fonte

1 risposta

Leggi altre domande sui tag authentication

Qual è l'algoritmo corretto durante il checksum di una porzione di codice? Quali payload SQL possono essere iniettati per un campo numerico?

score 1 · Answer 1

Quello che stai descrivendo è molto simile a PoP / RFC7800 (Semantica chiave di prova di possesso per i token Web JSON ). (È anche in qualche modo simile a ciò che sta cercando di fare AC / DC (codice di dominio incrociato di autorizzazione).

Con PoP, i passaggi proposti 1 e amp; 2 sono gli stessi: BOB (chiamato Recipient) emette un nonce con la risposta 401, Browser (chiamato Presenter) genera una coppia di chiavi Public / Private da inviare al server ALICE (chiamato Issuer). Anche il passaggio 3 è molto simile: Browser / Presenter invia la richiesta con la chiave pubblica a ALICE / Emittente.

PoP e il tuo protocollo proposto divergono leggermente dopo il Passo 3 - mentre tu memorizzi la chiave pubblica + nonce firmata sul server di ALICE, in PoP, ALICE / Emittente semplicemente firma la chiave pubblica e ritorna nella risposta (in un JWT). Il Browser / Presenter inoltra quindi il JWT dall'Emittente, aggiungendo il nonce (che si firma con la sua chiave privata) al Destinatario.

Il Destinatario può quindi verificare diverse cose: a) che il Browser / Presentatore è quello che ha ricevuto il nonce iniziale (ciò impedisce il dirottamento del token del client) eb) che il Browser / Presentatore detiene realmente il JWT firmato dall'Emittente .

Is there any pitfall I am not seeing?

Sia la tua proposta che PoP ottengono quanto segue:

Proteggono contro il dirottamento dei token client verificando che Browser / Presenter sia lo stesso che ha ricevuto il nonce nella risposta non autorizzata 401 originale.
Verificano che Browser / Presenter sia stato autenticato correttamente per l'Emittente - con la tua proposta, perché l'Emittente ha permesso il POST a /keys/nonce , e con PoP, perché l'Emittente ha restituito un JWT, firmato da solo, che includeva la chiave pubblica del browser.

Ciò che la tua proposta fa non indirizzo è il seguente importante problema:

Dato che stai parlando di un'applicazione nel browser (il Browser / Presenter), in che modo l'applicazione autentica con ALICE / Emittente? Cioè, dato che l'Emittente accetta un POST a /keys/nonce , presumibilmente ha verificato il cliente e ha autenticato l'utente. Ma come? OAuth2 e OpenID Connect (con cui PoP è progettato per funzionare) dispongono di meccanismi molto specifici per l'autenticazione di app client pubbliche (nel browser) all'emittente, con protezione di reindirizzamento e così via, perché non è un'attività facile e soggetta a molto di buchi di sicurezza. È probabile che tu abbia intenzione di utilizzare una sorta di meccanismo dei cookie, ma se l'app / Presenter sul lato browser è in esecuzione da un'origine diversa dall'Emittente, in che modo l'emittente intende autenticarlo?

Questo è rilevante per le app nel browser, ma è particolarmente rilevante per le app native, le app per dispositivi mobili o le tradizionali applicazioni Web lato server. In che modo lo schema proposto tenta di affrontare l'autenticazione con quelli?

Can any attack happen in point #4 of the diagram?

Non che io possa vedere, anche se non hai nemmeno bisogno di fare un POST qui, puoi fare un semplice GET e includere la parte Sign(location, nonce, bob) nell'intestazione Authorization: , stile token bearer.