it-swarm-eu.dev

Best practice per l'archiviazione sicura dei token di accesso

Quali sarebbero le migliori pratiche per la memorizzazione dei token di accesso di un'altra API per i tuoi utenti? In particolare sto sviluppando un'applicazione con alcuni amici che consentono all'utente di accedere a Facebook per autenticarsi sul nostro interno REST api e renderlo in grado di recuperare i loro amici (e altre cose).

Stavo pensando di generare una chiave e usarla per crittografare il token di accesso a lungo termine per l'account Facebook dell'utente e possibilmente altre informazioni sensibili. Come schema di crittografia userei AES-256-CBC e la chiave verrebbe inviata al client, che lo mantiene (e lo aggiorna una volta ogni tanto). Ma se creo quella chiave con qualsiasi casualità, l'utente può usare solo un client. Poiché gli altri client avrebbero bisogno di quella chiave per decrittografare il token di accesso di Facebook e altri dati. Una soluzione sarebbe generare la chiave da qualcosa di unico durante l'accesso a Facebook, ma sfortunatamente l'unica cosa che riesco a trovare è userid, di cui ho bisogno per trovare il record dell'utente nel database.

In realtà ci sono molti argomenti al riguardo su StackOverflow, ma nulla risponde a ciò che voglio. Quello che voglio effettivamente è crittografare il token di accesso di Facebook e altri dati utilizzando una chiave che solo il lato client conosce. La creazione di tali chiavi dovrebbe essere possibile solo quando l'utente esegue l'autenticazione utilizzando lo sdk di Facebook o quando viene fornita la chiave corrente.

Qualche idea?

21

La somma di ciò che il client memorizza e di ciò che il server memorizza deve essere sufficiente per recuperare i dati segreti specifici dell'utente (ad es. Token di accesso a Facebook). Ciò che il client memorizza è, principalmente, la password dell'utente (l'unica area di archiviazione permanente sul lato client è il cervello dell'utente, se vogliamo consentire all'utente di utilizzare diverse macchine distinte a piacimento). Se ho capito bene, non vuoi il tuo server archiviare i dati "così come sono": nel caso in cui il tuo server sia completamente compromesso, i segreti dell'utente dovrebbero essere comunque al sicuro (per quanto possibile ).

Questo indica crittografia basata su password . Dalla password dell'utente deriva una chiave simmetrica [~ # ~] k [~ # ~] che viene utilizzata per crittografare simmetricamente un pacchetto che contiene i segreti dell'utente, ad es. l'account Facebook. Tecnicamente, questo sarebbe simile a questo:

  • Quando l'utente si registra, sceglie la sua password [~ # ~] p [~ # ~] e la invia al tuo server.
  • Il tuo server genera un valore salt casuale [~ # ~] s [~ # ~] e calcola PBKDF2 over [~ # ~] p [~ # ~] e [~ # ~] s [~ # ~], per produrre 256 bit di output [~ # ~] t [~ # ~ ]. Chiamiamo [~ # ~] a [~ # ~] i primi 128 bit di [~ # ~] t [~ # ~] e = [~ # ~] k [~ # ~] l'altra metà a 128 bit.
  • La prima metà ( [~ # ~] a [~ # ~]) è memorizzata nel database del server; questo verrà utilizzato per autenticare gli utenti.
  • La seconda metà ( [~ # ~] k [~ # ~]) è not memorizzata; questa è la chiave simmetrica per quell'utente. I segreti dell'utente verranno crittografati con [~ # ~] k [~ # ~].
  • Quando l'utente accede, invia il suo nome e [~ # ~] p [~ # ~] al tuo server (su HTTPS). Il tuo server recupera salt [~ # ~] s [~ # ~] per quell'utente (come memorizzato nel suo database) e ricalcola [~ # ~] t [~ # ~] (usando [~ # ~] p [~ # ~] e [~ # ~] s [~ # ~] con PBKDF2). Se la prima metà del ricalcolato [~ # ~] t [~ # ~] corrisponde al valore memorizzato [~ # ~] a [~ # ~] , quindi l'utente viene autenticato e la seconda metà di [~ # ~] t [~ # ~] è [~ # ~] k [~ # ~]. Il server può quindi decrittografare il pacchetto archiviato e accedere al token di accesso di Facebook.

Con questa configurazione, il server non = [archivia mai (sul suo disco o nel suo database) il token di accesso a Facebook in chiaro, ma può accedervi quando l'utente accede; spetta al server ricordare (nella RAM) il token di accesso di Facebook finché ne ha bisogno.

Nota che quando l'utente cambia la sua password, anche questo cambia [~ # ~] k [~ # ~] (il server deve anche generare un nuovo salt [~ # ~] s [~ # ~], ma anche se il server non lo avesse fatto per errore, [~ # ~] k [~ # ~] sarebbe comunque cambiato); pertanto, il server deve decrittografare il pacchetto archiviato con il vecchio [~ # ~] k [~ # ~] e crittografarlo nuovamente con il nuovo [~ # ~] k [ ~ # ~] quando la password viene cambiata. Non è difficile da integrare perché le interfacce di cambio password richiedono abitualmente la vecchia password e la nuova password, quindi a quel punto il server ha entrambe.

Inoltre, quando la password viene dimenticata, il pacchetto viene perso. Non c'è recupero per quel caso. Se l'utente dimentica la propria password, sarà necessario reimpostare la password, simile a una nuova registrazione; e dovrà essere ottenuto un nuovo token di accesso a Facebook.


In tutto quanto sopra, vediamo che il tuo server vede ancora la password dell'utente. Se il tuo server è completamente compromesso e violato, l'attaccante sarà in grado di osservare le password degli utenti e i token di accesso a Facebook degli utenti per tutti gli utenti che accedono mentre l'attaccante controlla il server. Prevenire quello è molto più difficile. Probabilmente, se il tuo server presenta solo un'interfaccia Web, dove tutta "l'intelligenza" sul lato client è Javascript inviata dal tuo server, allora è impossibile fare meglio di quello che fa lo schema sopra, in quella situazione.

14
Tom Leek
2
ma11hew28

Sono stato alla decima conferenza ISC di sicurezza e crittografia la scorsa settimana e lì ho visto qualcuno proporre un metodo per archiviare i token pass utente usando Neural Network . Ha creato un NN che apprende i token di passaggio utente e si è aggiornato usando un metodo di apprendimento NN veloce. È un nuovo metodo e promette sicurezza ma richiede molta attenzione all'apprendimento.

[~ ~ #] aggiornamento [~ ~ #]

L'articolo era in Farsi intitolato enter image description here significa User Access Control Using Neural Network and chaotic system

(lo stack non supporta i personaggi Farsi! Ho usato invece l'immagine !!!)

2
sajjadG