In che modo i dati privati ​​possono essere protetti con l'autenticazione OAuth2?

Question

Sto configurando un sito Web per utilizzare l'interfaccia OAuth2 di Google per l'autenticazione dell'utente. Il sito Web memorizzerà i dati privati ​​associati a ciascun utente, che ho intenzione di crittografare.

Se ho implementato il mio metodo di autenticazione per il sito Web, potrei facilmente ricavare una chiave dalle credenziali dell'utente (che includono la password dell'utente), consentendo la protezione dei dati per ciascun utente. Ma con OAuth2, credo di poter ricevere un solo token di accesso, garantendo tale autorizzazione all'utente per un periodo di tempo - il problema è che il valore del token di accesso cambierà nel tempo.

C'è un modo in cui OAuth2 può fornirmi un segreto immutabile legato all'utente che posso utilizzare per derivare una chiave sicura? O c'è qualche altro metodo per creare un segreto persistente sicuro usando OAuth2?

--- --- Modifica

In risposta alle domande e commenti, qui ci sono alcune riflessioni da considerare:

• Tutte le informazioni utente deve sempre essere protetto con crittografia forte e autenticazione degli utenti - la ragione per cui leggiamo così tanti articoli di notizie sugli intrusioni nel database del sito web & è perché gli sviluppatori dicono "abbiamo davvero bisogno di proteggerlo" e poi rispondiamo con "No - perché nessuno, ma noi saremo in grado di accedere al database, la sicurezza è difficile , eccetera". L'hacker scarica il database e viola. Carte di credito, indirizzi e-mail, numeri di telefono, password, tu lo chiami e poi vieni compromesso.
• Ci sono solo due veri segreti: uno è una password memorizzata nella testa di qualcuno, l'altro è un forte valore casuale a cui solo l'utente autorizzato ha accesso (come un token fisico). Se si ritiene che una chiave sicura possa essere derivata da un solo indirizzo e-mail o che un segreto debba essere memorizzato in un database, non si capisce veramente la sicurezza.

Credo che quello che stavo cercando di scoprire era se un provider di OAuth in grado di fornire al cliente OAuth un valore immutabile legato saldamente sia utente e cliente - in modo efficace, questo sarebbe una chiave che può essere sbloccata solo dal Provider OAuth che utilizza una combinazione del segreto dell'utente (la sua password di autenticazione) e il segreto del client (utilizzato nel protocollo OAuth). Il client potrebbe quindi utilizzare questo valore per fornire un ragionevole livello di sicurezza per i dati dell'utente.

Ovviamente questa implementazione non è perfetta dall'abuso, ma implementata correttamente, potrebbe fornire un modo ragionevole per proteggere i dati mentre si utilizzano ancora le buone pratiche dello schema OAuth.

Answer 1

Il punto del token è che è possibile utilizzare il token per ottenere informazioni da Google sull'utente. Durante l'autenticazione iniziale, si dirà che l'utente e Google, a cui si desidera accedere a determinate informazioni sull'utente:

https://developers.google.com/+/api/oauth

Supponendo che l'utente consente di accedere ai propri dati, come ad esempio il loro indirizzo e-mail , puoi quindi ottenere il loro indirizzo email da google. Una volta ottenuto il loro indirizzo email, è possibile generare una chiave segreta per il proprio utente, archiviarla nella tabella utente e utilizzarla per crittografare i propri dati. Quindi, quando effettuano nuovamente l'accesso, puoi cercare il loro indirizzo email e trovare la chiave.

Esiste una necessità specifica che l'informazione immutabile sia "segreta"? O è solo una chiave per identificare un utente?

Se le informazioni che stai memorizzando sono veramente private e vuoi far sì che tu non possa accedere ai dati dell'utente, tutto ciò che devi fare è archiviare il blob crittografato per i tuoi utenti. Una volta che l'utente ha scaricato i propri dati, possono utilizzare la propria chiave per decrittografare i dati sul lato client.

Answer 2

La mia prima domanda sarebbe: Perché vuoi ottenere le chiavi di crittografia da alcuni token?

I token e le chiavi di crittografia potrebbero rimanere indipendenti e possono essere associati a un utente identificato da un ID univoco. L'autenticazione dell'utente può essere eseguita in qualsiasi modo sia tramite le credenziali o l'autenticazione con ID aperto o altro. Ma, una volta che un utente è autenticato, le API di decrittografia possono recuperare la chiave di decrittografia associata all'utente autenticato e fare qualsiasi decrittazione a farlo.

In questo modo è possibile consentire agli utenti di collegare più account ID aperti con lo stesso utente in modo analogo a quanto fa StackOverflow. Posso associare i miei account yahoo, facebook e google al mio utente StackOverflow e posso accedere con uno qualsiasi di questi provider. Posso dissociare quegli account ogni volta che voglio. Ma ciò non influisce sul mio profilo StackOverflow e sui dati.

Quindi, non è una buona idea derivare le chiavi da qualcosa che non è costante e continua a cambiare. Invece, tienili separati.

Answer 3

Quello che ti serve è una chiave sicura (casuale) costante per ogni utente che puoi ottenere dal servizio di autenticazione che fornisce l'endpoint OAuth2 (in questo caso, Google).

Il protocollo OAuth2 non fornisce tale valore - Il server di autenticazione utilizza valori generati che non sono costanti. Ma OAuth2 non proibisce di fornire questo valore dal server delle risorse (insieme a ID utente, e-mail, ecc.). Quindi, in pratica, OAuth2 ti consente di proteggere i dati nel modo desiderato, ma Google, che usi attualmente, non fornisce questo tipo di valore casuale costante.

Si noti inoltre che ciò non funzionerebbe se si consentisse all'utente di relazionare alcuni account, come Google e Facebook, in quanto darebbero chiavi casuali diverse.

Se si ricava il segreto dalle credenziali, ciò significherebbe anche che la reimpostazione della password reimposterà l'account utente.

Inoltre, se si codificano i dati come le e-mail in questo modo, diventa impossibile decrittografarli senza l'utente attualmente connesso. Quindi la newsletter via email diventa praticamente impossibile. Non è possibile interrogare i dati anche in SQL.

potevo solo suggerire alcune contromisure:

• Non memorizzare dati sensibili a tutti, o conservarlo hash. Le password devono essere sottoposte a hash, non crittografate. Non memorizzare numeri CC, memorizzare token che li rappresentano.
• Utilizzare la crittografia con chiave, memorizzata in un'altra origine dati. Ciò aggiunge almeno un po 'di sicurezza: l'utente malintenzionato deve ottenere non solo la copia del DB, ma anche la chiave di crittografia.
• Poiché i dati sono crittografati, non è più necessario memorizzarli nel database. È possibile memorizzare i dati crittografati in file o in un'altra fonte, dove è più sicuro di DB (nessun rischio di iniezioni SQL ecc.)

Answer 4

Ho riscontrato questo stesso problema. Finora, non riesco a trovare un modo sicuro per aggirarlo.

Fondamentalmente, abbiamo bisogno di un segreto generato a caso per sito fornito solo con un flusso implicito che può essere utilizzato per ricavare credenziali per accedere ai sistemi e decrittografare i dati.

Perché voglio proteggere i dati da me stesso, potrei scrivere il client in modo che salti/esegui l'hash del segreto in due modi: un modo per recuperare i dati e un altro per decrittografarlo.

Ahimè, questo non è il caso.

ho potuto ricavare le credenziali dalle cose nella dotazione di base del OAuth e che avrei proteggere i dati contro me, ma che lascia l'utente spalancata per le vulnerabilità di cross-site, e inoltre, dati personali rende per un povero segreto

Il meglio che ho è utilizzare il flusso implicito oAuth2 per acquisire l'indirizzo email dell'utente, generare in modo casuale un segreto del client e forzare l'utente a inviare via email il segreto (come chiave di ripristino), quindi archiviare il segreto in localStorage . Salt/Hash la variabile di scope secret + oauth per ricavare il lato client delle credenziali (quindi l'utente deve essere loggato) necessario per accedere, crittografare e decrittografare i dati.

Se l'utente cancella il proprio LocalStorage, è necessario fare clic sul collegamento nell'e-mail di ripristino, che riporta il segreto in localStorage.

In questo modo l'area di vulnerabilità ritorna sul client, ma è resistente alle macchine pubbliche (dovrebbe sapere chi ha effettuato l'ultimo accesso e ottenere l'accesso al token di localStorage), consente il ripristino e richiede debolmente all'utente per essere loggato. Ancora vulnerabile agli attacchi di plugin injection e all'accesso fisico + conoscendo l'utente.

Aggiornamento: Ho deciso di utilizzare alcune estensioni oAuth (hello.js, API di cartella) per archiviare le chiavi nell'account utente come file. Richiede alcune autorizzazioni e alcune API da implementare, ma sembra essere fattibile.