Dove archiviare hash, sali, chiavi in ​​Applicazioni desktop

Question

Sto cercando di capire dove o come dovrei memorizzare i segreti dell'applicazione e le chiavi all'interno di un'applicazione desktop.
Ad esempio una chiave di app di Facebook o una chiave dropbox e un segreto.

Quindi ho letto che dovrei fare hash, salare, crittografare ecc. Ecc. Questi valori. Questo per impedire a qualcuno di decodificare il mio codice e vedere le chiavi.

Il tutto va bene e bene, ma con tutti questi metodi, sto semplicemente memorizzando un valore salt o hash da qualche parte invece della chiave stessa, alla fine. Sicuramente se un hacker può raggiungere il sale/hash e possibilmente il codice sorgente, sarà in grado di decifrare la chiave crittografata e ottenere comunque la mia password/chiave/segreto?

Un'opzione che ho letto su questo sembra la più sicura è quella di non memorizzare questo valore nell'app desktop, ma di chiamare un servizio Web per ottenere la chiave (probabilmente crittografata). Ma la mia domanda è, anche in questo caso, un hacker decente farà sicuramente un dump della memoria o qualcosa per vedere qual è il valore restituito dal servizio web, e quindi torniamo al punto 1.

Il la prossima alternativa migliore sembra essere l'oscurità.

Mi manca qualcosa completamente?

Nota a margine, a che cosa servirà comunque un hacker di Facebook/twitter/dropbox/etc/secret per un hacker? Sicuramente avrebbero ancora bisogno delle credenziali di un utente o del token di accesso per poterlo comunque utilizzare?

Qualsiasi consiglio o suggerimento sarà apprezzato.

Answer 1

Per ciascun account utente generare un nuovo token di accesso per l'applicazione quando si accede correttamente al servizio. Il vostro servizio di accesso dovrebbe essere progettato molto simile a un account di accesso per un sito web:

• L'API dovrebbe consentire solo un determinato numero (diciamo 5) cattivi tentativi di accesso che i rapporti al client desktop che il nome utente/password non corrispondono .
• L'API deve restituire un gettone affiliato con solo l'utente quando l'utente accede con successo.
• Usa SSL e un metodo di hashing localizzato per passare le password degli utenti al tuo API

Questo Auth Token fornito dal L'API funzionerà solo per il singolo account e in quanto tale dovrebbe consentire all'utente di eseguire operazioni sul suo singolo account. Ad esempio, se un utente desidera eseguire un'operazione, deve essere in grado di fornire un token di autenticazione valido per completare l'azione. Utilizzando questo metodo, gli autori di attacchi saranno comunque in grado di ottenere una chiave di autenticazione, ma quella chiave di autorizzazione sarà in grado di eseguire solo le operazioni per l'account in cui è stata generata. Non sarà in grado di eseguire operazioni su nessun altro account. L'idea è di lasciarli confondere con i dati ma di mantenere la cattiva attività compartimentalizzata su un account.

Da lì, se si dispone di chiamate API generiche (ad esempio una ricerca di immagini) che accede ai dati da più account assicurarsi che non siete mai restituente o permettere a qualsiasi account per l'accesso tutte i dati nel vostro sistema a titolo definitivo. Fornire solo un numero limitato di record. In questo caso il sistema sta ancora eseguendo il proprio lavoro, ma in nessun momento consente l'accesso a tutti i record del proprio sistema.

io di solito implementano un servizio come questo:

• utente accede e ottiene un token di autenticazione. Conservo detto token di autenticazione in un database associato a quell'utente.
• L'utente chiama il servizio Web con token di autenticazione. Ricerco l'account utente entro il il token di autenticazione trasmesso e l'ID utente (due forme di autenticazione) e utilizzo l'account utente rilevato per eseguire tutte le operazioni. Non presumo solo che l'ID utente sia corretto, deve essere quello con il token di autenticazione autenticato.
• Se un utente deve eseguire un'operazione delicata come reimpostare una password, la mia app apre una finestra del browser o un'attività del browser nell'app in cui l'utente può richiedere e amministrare un ripristino. Posso proteggere più facilmente un'applicazione Web rispetto a una su un client sconosciuto.

Utilizzando questi metodi si dovrebbe essere in grado di realizzare un'applicazione desktop pienamente operativa. Ci sono valori anomali a questa funzionalità, se ne hai pubblicati nei commenti e possiamo approfondire ulteriormente il problema e vedere se questa soluzione può ancora funzionare per te.