Come posso archiviare le informazioni in modo sicuro quando non riesco a utilizzare crypt o hash?

2

Sto creando un'applicazione per Google Glass (tecnicamente è Glassware , ma qualunque sia). L'utente eseguirà le seguenti operazioni durante l'installazione di Glassware:

  1. Vai al mio sito web, reindirizzato tramite la pagina Glassware.
  2. Ricevi reindirizzato alla pagina Google OAuth in modo che possano accedere.
  3. Ricevi reindirizzati al mio URI di reindirizzamento OAuth (modo carino per dire la pagina di destinazione).
  4. Ti viene richiesto di visitare un sito Web di terze parti (qualcosa come Facebook, Twitter o Instagram, non ancora sicuro).
  5. Passare attraverso la danza OAuth o una danza di autenticazione per ottenere una chiave API / chiave OAuth.
  6. Sii grato che tutto è finito.

Quindi ora quello che ho tra le mani sono un paio di token API / OAuth, un ID utente internamente e l'ID Google di un utente. Potrei avere qualche altro punto di dati, come CreationDate e cose del genere, ma nessuno così importante come questi dati.

Ora che ho tutti questi dati, è ora di memorizzarli. Probabilmente verrà memorizzato in un database come MySQL. Dal momento che ho tutti questi dati importanti su un utente, come posso renderlo sicuro in modo che gli hacker non possano accedervi? Non riesco a utilizzare un hash o un PHP crypt , poiché l'utente non inserirà password ogni volta che ho bisogno di usare i loro token. Infatti, l'utente avrà no nome utente e password specifici per il mio servizio. Mi rendo conto che questo rende difficile la sicurezza, tuttavia, la memorizzazione di tutto questo come testo semplice sembra insicuro ... o è?

Quindi, come posso proteggere i token di un utente quando l'utente non ha una password associata al mio servizio e l'utente non accederà al servizio ogni volta che devo usare i token?

    
posta hichris123 04.03.2014 - 23:57
fonte

1 risposta

1

Chiedi all'applicazione client di inviare una chiave di crittografia generata casualmente durante il processo di autenticazione iniziale. A seconda della frequenza con cui si desidera che l'utente effettui il login, la chiave potrebbe essere generata per singola sessione o globalmente per il dispositivo client.

Per l'applicazione server contenere due copie dei token di autenticazione: la prima copia è crittografata dalla chiave client per la persistenza, la seconda è non criptata ma transitoria nella memoria del server. La seconda copia transitoria viene cancellata dopo che il client non è stato ascoltato da un po 'di tempo o si è disconnesso / disinstallato.

In questo modo un hacker con accesso al dispositivo client non ha i token OAuth e può solo abusare del tuo servizio specifico. Un hacker con accesso al server non ha la chiave di decrittografia e quindi i token OAuth sono inutili.

Tuttavia, un hacker potrebbe semplicemente modificare l'applicazione server per raccogliere futuri token OAuth. Pertanto, il server Web dovrebbe proibire lo scambio di applicazioni hot-swapping senza riavvio e richiede una password fornita dalla console per il certificato SSL del server all'avvio, che l'applicazione client controlla esplicitamente anziché il trust store CA standard catch-all.

    
risposta data 08.03.2014 - 04:10
fonte

Leggi altre domande sui tag