Autorizzazione / Controllo degli accessi in un ambiente di crittografia lato client

Question

Autorizzazione / Controllo degli accessi in un ambiente di crittografia lato client

#1 da (0 voti)
#2 da (0 voti)

0

Sto pensando a un concetto di crittografia sul lato client in cui solo il client conosce il master secret (una password utente). Si presuppone una corretta implementazione, con KDF e soluzioni di crittografia autenticate dovrebbe essere possibile garantire la riservatezza e l'integrità senza inoltrare il segreto (dalla chiave derivata dalla password) al server e anche senza salvare il segreto sul server.

Ma che cos'è l'autorizzazione in questo scenario? Come posso controllare l'accesso alle risorse senza un "processo di accesso" sul server? Per esempio. come posso evitare che un utente cancelli una risorsa da un altro utente?

La mia unica idea è usare un CSPRNG per generare un ID casuale per ogni risorsa. Ma poi gli ID delle risorse saranno trasformati in informazioni sensibili, ciò che non mi sembra perfettamente ragionevole.

Ci sono strategie / tecnologie che mi mancano? Grazie per avermi indicato in una nuova direzione.

authorization access-control

posta Peter83672 09.11.2017 - 09:40

fonte

2 risposte

0

È possibile memorizzare una mappatura delle informazioni utente associate a ciascuna chiave in un database e effettuare una ricerca e impostarla in un cookie di sessione crittografato che il client può trasmettere avanti e indietro. Questa è ovviamente una soluzione orribile, ma può essere implementata. Il modo corretto sarebbe avere un meccanismo di accesso se hai bisogno di ruoli specifici dell'utente. Quello che stai descrivendo è fondamentalmente come funziona oauth e non dovrebbe essere usato in casi come questo. Questo tipo di auh che descrivi è in genere per il servizio di autenticazione del servizio senza restrizioni.

risposta data 10.11.2017 - 05:56

fonte

Leggi altre domande sui tag authorization access-control

Connessioni di blocco proxy sconosciute sulla porta 8080 Come viene distribuito il malware all'interno dei file zip?

score 0 · Accepted Answer

In breve, è necessario un meccanismo di autenticazione separato, ovvero l'utente deve accedere al server in qualche modo. Il tuo approccio con ID casuale ha diversi problemi:

Come hai sottolineato, questi devono essere archiviati in modo sicuro dall'utente. Devi anche essere certo che non possano essere intercettati.
Non hai idea di cosa appartenga a chi. Se un utente perde il proprio set di ID, ha documenti obsoleti sul server ma non ha idea di quali siano i documenti. Inoltre, non puoi limitare lo spazio di archiviazione degli utenti, ecc.

Sto assumendo perché hai chiesto di non voler che gli utenti debbano memorizzare più password. Il che lascia davvero tre approcci: entrambi richiedono un ID utente o un nome utente per il caso in cui più utenti scelgono la stessa password.

Sul lato client si prende un hash crittograficamente sicuro della password dell'utente. Questa diventa la password di autenticazione dell'utente (quindi si memorizza un hash dell'hash sul server). Questo è abbastanza semplice da implementare. In teoria dovrebbe essere sicuro, ma il riutilizzo della passphrase non è consigliabile.
L'utente genera una coppia di chiavi privata / pubblica dall'ID utente + passphrase (utilizzando una funzione di derivazione della chiave per generare il seed su un CSPRNG che viene utilizzato per generare la chiave privata). Dovresti quindi generare una chiave di crittografia simmetrica interamente casuale, crittografarla con la chiave privata e inviare sia la chiave simmetrica crittografata che la chiave pubblica asimmetrica al tuo server. La chiave privata può essere ripristinata con la passphrase. L'applicazione ottiene la chiave di crittografia richiedendo la versione crittografata dal server e decodificandola con la chiave privata. L'utente autentica firmando i messaggi con la chiave privata e il server può verificarli con la chiave pubblica.