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

Non esiste una soluzione sicura al 100%. Qualsiasi cosa tu realizzi deve essere eseguibile da un computer deterministico, quindi qualcuno e sostituirlo e scartare le barriere tecniche che hai messo sulla loro strada. Puoi renderlo tecnicamente più impegnativo e un processo più complesso e lento, ma in tempo utile se gli incentivi ci sono, qualcuno lo infrangerà.

Se stai implementando questo in .NET, per impostazione predefinita è banale che qualcuno possa ottenere il codice sorgente in stile C # nella tua applicazione e poi passare attraverso il codice C # in un debugger. È un po 'più complesso in C / C ++, ma di nuovo non impossibile. Non so quanta sfida ci sia in JAVA, ma non mi aspetterei che sia un ostacolo significativo.

Ci sono processi che possono essere applicati per rendere il codice più difficile da leggere per un essere umano, ma fanno molto poco per rendere più difficile per un computer un singolo passaggio attraverso il codice. Qualcuno può inserire un punto di interruzione nella libreria di sistema e quindi tracciare di nuovo lo stack delle chiamate per vedere se questa chiamata a un socket di rete è di interesse senza dover capire il codice base.

Ho anche visto tecniche di crittografia utilizzate, in cui un programma decrittografa il codice effettivo durante l'esecuzione. Tuttavia, ancora una volta, un hacker determinato può semplicemente eseguire questa parte del codice, ottenere il codice decrittografato e quindi decodificarlo nel codice sorgente.

La soluzione migliore è presumere che sarà compromessa e quindi garantire che il processo per la modifica dei dati sensibili sia banale per te e che elaborare per compromettere i dati sensibili sia il più difficile possibile per tutti gli altri. Ecco perché alcuni sistemi richiedono una chiamata web per ottenere i dati. Puoi quindi bloccare le chiamate da IP o da certificati client di cui non ti fidi più e assegnare a tutti gli altri la chiave dell'applicazione "mesi".

Alla fine, devi considerare le conseguenze per avere i dati pubblicamente noti, e poi decidere quanto lontano devi andare, per rendere il processo per ottenerlo più qualificato e più dispendioso in termini di tempo.

Penso che ci siano due problemi distinti qui

1: Posso impedire a un utente che ha accesso al codice sorgente del client di ottenere una chiave / password hardcoded o configurata che il client deve accedere a un servizio

2: Posso impedire a un hacker che accede al pc degli utenti di accedere agli username e alla password memorizzati nella cache che la mia app sta utilizzando.

quindi con 1, non dovresti avere questo tipo di chiave condivisa usata da tutti i tuoi clienti. garantire che ogni utente abbia le proprie credenziali per il servizio. Questo rende quindi responsabile solo la propria informazione e ti permette di bandire gli abusanti

con 2, come nella risposta di @ ptolemy, non memorizzare il proprio nome utente / password per memorizzare un hash, o meglio ancora usare il nome utente / pass una volta per ottenere una chiave API e memorizzarla. Invalidare dopo un periodo di tempo o quando si rileva un comportamento sospetto come più connessioni simultanee ecc.

Dovresti utilizzare una funzione di hash crittografica : una funzione hash che è considerata praticamente impossibile da invertire, ovvero, per ricreare i dati di input solo dal suo valore hash.

Per autenticare un utente la tua applicazione:

• hash la password presentata;
• confronta il valore con l'hash memorizzato.

In questo modo, se il file della password viene compromesso, non si ha una grande violazione della sicurezza: l'applicazione richiede una password, non una chiave hash e l'hacker non può recuperare la password (la funzione unidirezionale impedisce il password originale da recuperare anche se dimenticata o persa).

Il reverse engineering della funzione / dell'applicazione hash non è significativo in quanto non c'è nulla nascosto nel codice. Le password sono protette dalla complessità di invertire la funzione di hash.

Ad ogni modo l'hacker potrebbe tentare un attacco di dizionario usando una lunga lista di hash precomputer per le password di uso comune. Di solito anche un piccolo dizionario (o il suo equivalente ad hash, una tabella arcobaleno ) ha una probabilità significativa di scomporre le parole più usate.

Quindi l'accesso ai dati hash dovrebbe essere limitato (ad esempio, vedi File shadow per i sistemi operativi di tipo Unix) .