Dove memorizzare gli hash, i sali, le chiavi nelle applicazioni desktop

Question

Dove memorizzare gli hash, i sali, le chiavi nelle applicazioni desktop

#1 da (5 voti)

5

Sto cercando di capire dove o come dovrei conservare i segreti e le chiavi delle applicazioni all'interno di un'applicazione desktop. Ad esempio una chiave di app di Facebook o una chiave di Dropbox e un segreto.

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

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 decodificare 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 quale sia il valore restituito dal servizio web, e poi torniamo al punto 1.

La prossima alternativa migliore sembra essere l'oscurità.

Mi manca qualcosa completamente?

Nota a margine, a 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.

encryption passwords password-management

posta user177950 07.05.2015 - 06:16

fonte

1 risposta

Leggi altre domande sui tag encryption passwords password-management

È conforme a Heroku PCI? SSH: sicurezza dell'autenticazione Pubkey vs password

score 5 · Answer 1

TLDR : non puoi mantenere nulla di segreto in un'applicazione client, puoi solo renderlo più difficile da trovare. Hai bisogno di offuscare la chiave segreta per renderla abbastanza difficile da consentire a un utente malintenzionato di decodificarlo.

Le applicazioni client, che devono essere implementate sul dispositivo dell'utente finale, sono soggette al reverse engineering e quindi NULLA può essere tenuto segreto. Ma è vero che si può fare il processo di reverse engineering alcune parti della vostra applicazione duro, a volte abbastanza duro per renderlo non vale la pena, utilizzando offuscamento .

usare un hash e un salt non ti aiuterà dato che una funzione hash è una funzione unidirezionale - può essere usata per convalidare l'hash di un dato input è identica a quanto previsto. Non può essere utilizzato per crittografare i dati, poiché non esiste un metodo per decodificare.

È possibile utilizzare la crittografia simmetrica come AES, ma sarà comunque necessaria la chiave di crittografia per decrittografare i dati e quindi sarà disponibile anche per l'autore dell'attacco.

Mantenere il segreto su un server e chiamare un servizio Web, come hai notato, è inutile in quanto l'utente malintenzionato può chiamare il servizio web proprio come può fare l'applicazione client.

Quindi il vero unico mezzo per proteggere il tuo segreto è l'uso dell'offuscamento, che renderà non utile a un utente malintenzionato fare lo sforzo di decodificarlo.

IMHO nel tuo caso, una chiave segreta per un'API sono dati sensibili, ma non critici. Chiunque può ottenere una propria chiave API e, come da lei indicato, non concede le autorizzazioni ai dati degli utenti. È giusto che il fornitore di servizi tenga traccia di chi sta effettuando le chiamate API e, a volte, di determinate API per monitorare l'utilizzo, i limiti e persino le tariffe. Quindi rischi che qualcuno stia rubando la larghezza di banda delle tue API e forse ti stia causando il pagamento dell'utilizzo dell'API. Il lato positivo - tali chiavi (Facebook, Twitter ...) sono molto comuni, oggi quasi in ogni applicazione, e quindi la sua abbastanza per il vostro per fare solo un po 'più difficile del solito in modo che l'attaccante di lasciare appena la vostra applicazione da solo e vai a prendere una chiave API sercret da un'altra applicazione in cui si trova semplicemente in testo normale.

Qui è un post del blog con alcune semplici idee.