Salvataggio di token di autenticazione su siti Web di terze parti

Question

Salvataggio di token di autenticazione su siti Web di terze parti

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

5

Quindi Flickr ti consente di autenticare gli utenti nella tua app tramite app_key e secret e restituisce un token di autenticazione. Voglio salvare in modo sicuro il token di autenticazione nel mio database, ma anche poterlo invertire in modo che l'applicazione possa effettuare chiamate autenticate per quell'utente. Non sono sicuro di quale sia il modo migliore per farlo o se è quello che dovrei fare? Voglio mantenere quel token di autenticazione in modo che quando un utente si collega di nuovo al mio sito, avrà già il token di autenticazione.

authentication encryption token

posta mnguyen 18.06.2015 - 07:36

fonte

2 risposte

Leggi altre domande sui tag authentication encryption token

È sicuro riutilizzare una scheda in un browser per diversi siti Web? AWS-S3 Problema di sicurezza dell'URL firmato

score 1 · Answer 1

La risposta rapida è che l'archiviazione dei token di autorizzazione in testo in un database non è un problema, ma ci sono altri aspetti che sono più critici nel mantenere i token (e il loro uso) sicuri.

Assicurati che oauth_consumer_key (chiave app) e oauth_token (token di autorizzazione) non vengano mai inviati o memorizzati sul lato client (browser utenti, telefono, ecc.). Ciò significa che le richieste al fornitore di servizi (Flickr) devono sempre essere eseguite da un server che ha accesso al database e quindi i dati ricevuti dai dati del fornitore del servizio possono essere inoltrati al client. Se memorizzi la chiave e il token dal lato degli utenti, saranno in grado di impersonare la tua applicazione e accedere ai dati riservati.

Per proteggere la chiave e i token durante la richiesta dal tuo server a Flickr, esegui la richiesta come POST su HTTPS. In questo modo un intercettatore non può mettere le mani sui token mentre sono diretti a Flickr.

Proteggi il tuo database, non crittografando i token, ma assicurandoti che qualsiasi accesso non autorizzato al database non sia possibile. Se il tuo database viene compromesso (ad esempio SQL injection, qualsiasi altra iniezione), le misure precedenti non hanno alcun effetto. Questa è una buona cosa da fare in generale, e consiglierei su come crittografare i token nel database.

Fonti: OAUTH v1.0 e API di autenticazione Flickr .

score 0 · Answer 2

Quindi ho pensato che è possibile salvare un lato client chiave hash in una sessione / cookie. Questo in pratica significa che chiunque sia il server non sarà in grado di fare nulla con nessuna informazione perché non ha la mappa che dice che questa persona è connessa con questa API / proprietà. Quindi il client ha 1 metà della chiave e il server ha l'altra metà della chiave. Vorrei cancellarlo con qualcosa come email + password, password come chiave. L'unico problema è sincronizzare le proprietà quando le password cambiano inevitabilmente. Mi piace questo approccio a mezza chiave e vorrei applicarlo ad altri modi. Sarebbe bello creare un database pubblico, ma impossibile ottenere informazioni preziose senza l'altra metà della "chiave". Non lo so, sembra anche che ci stiamo allontanando comunque dalle "password di accesso".