Applicazione desktop e sicurezza open source

Question

Applicazione desktop e sicurezza open source

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

0

Attualmente sto lavorando a un'applicazione desktop in Java (utilizzando JavaFX).

Questa applicazione memorizza alcune informazioni dell'utente, parti delle quali sono sensibili. Ad esempio, se l'utente configura un proxy, lo memorizzerà in un file con crittografia. Inoltre, la mia applicazione sta chiamando un'API Web per eseguire gli aggiornamenti automatici (con uno schema di autenticazione di base).

Attualmente la mia applicazione è closed source e viene utilizzata in un contesto che non richiede un'elevata sicurezza. L'implementazione contiene fondamentalmente tutte le credenziali necessarie per l'autenticazione nell'API o per crittografare le impostazioni dell'utente. Fondamentalmente, contiene qualcosa di simile (semplificato, non è "così ovvio").

String login = "mysuperlogin", password = "mysuperpassword";
authenticateToApi(login, password);

String encryptionKey = "mysuperencryptionkey";
encryptDataToFile(data, file, encryptionKey);

Ma : so che questo modo di fare le cose non è affatto sicuro! So che è possibile "decompilare" Java e vedere le credenziali / i metodi usati dall'applicazione, e quindi usarli per accedere alle informazioni "sensibili".

Sto pianificando di aprire il mio progetto quest'anno, quindi so che devo fare le cose per fornire un livello di sicurezza migliore, ecco le opzioni che vedo:

Uso delle proprietà compilate durante il tempo di compilazione per includere le mie credenziali direttamente nel codice, senza includerle nel codice sorgente: questo non risolve il problema "decompilare"
Utilizzo di una chiave inserita dall'utente per garantire ogni informazione: non mi piace questa soluzione perché la mia applicazione deve essere utilizzata con l'intervento "tecnico" dell'utente più basso. Inoltre, questo non risolve i problemi delle credenziali API.
Genera una chiave dal sistema corrente per crittografare i dati. Ma nella versione open-source, sarà possibile trovare la chiave di sistema corrente e quindi utilizzarla per accedere ai dati crittografati.

Suppongo che siano un sacco di programmi closed / open source che hanno questo problema, ma non riesco a capire quale sia la "meno peggio" soluzione.

java security encryption applications client

posta zimath 02.03.2018 - 09:26

fonte

2 risposte

0

Proverò a semplificare la tua affermazione sul problema: sembra che stia memorizzando le credenziali immesse dall'utente in modo simile a un browser Web per le password salvate.

Per impostazione predefinita, le password salvate del browser Web sono vulnerabili allo stesso modo delle credenziali salvate. Inoltre, puoi utilizzare la stessa soluzione dei browser Web: una password principale per proteggere il tuo negozio di credenziali.

Quando l'applicazione si avvia per la prima volta, richiede all'utente di specificare una password principale.

Utilizzare questa password principale come chiave per un keystore [1] in cui conservare tutte le credenziali salvate in una forma crittografata (possibilmente utilizzando le classi Java KeyStore o qualcos'altro di propria scelta).

Non salvare mai la password principale immessa dall'utente sul disco.

Quando l'applicazione si avvia in seguito, sarà necessario chiedere all'utente la propria password principale per poter aprire il keystore e decrittografare le credenziali salvate.

Dato che la master password non è nota al tuo software (o qualsiasi altra cosa - dobbiamo supporre che la macchina locale sia libera da keylogger o rootkit ecc. che significherebbe che tutte le puntate sono disattivate), e non tenuta da nessuna parte su disco, quindi il keystore dovrebbe essere ragionevolmente sicuro.

Lo svantaggio è che l'utente deve reinserire questa password ogni volta che viene lanciata l'applicazione e, se la dimentica, l'archivio delle credenziali viene perso.

[1] Tralascio molti dettagli qui in termini di salatura, tipi di crittografia ecc.

risposta data 20.03.2018 - 13:20

fonte

Leggi altre domande sui tag java security encryption applications client

È possibile archiviare e interrogare combinazioni di informazioni di tipo booleano in un numero intero? Strategia per aggiornare l'indice di ricerca dopo aver corretto la generazione dell'indice

score 3 · Accepted Answer

L'unico modo per garantire che le credenziali utilizzate da una particolare installazione del tuo programma non possano essere abusate è:

A) Usa una chiave privata che solo tu sai per generare una password hash e non una vera e propria password.

B) Aggiungi un componente casuale nell'hash della password generato in modo tale che ogni installazione abbia il proprio hash della password.

C) Fai funzionare la password esattamente una volta sul tuo server. Dopo il primo accesso, richiedi che vengano creati un nome utente e una password.

D) Fa fallire il programma se questa convalida iniziale fallisce.

Utilizza una chiave privata

Usando una chiave privata, l'hash che viene generato è a senso unico e solo tu puoi convertire una password nel proprio hash. Ciò significa che il cliente, nonostante sappia come funziona il programma e conoscendo l'hash della password esatta, non può mai sperare di generare il proprio hash della password per altri utenti da utilizzare in altre installazioni. L'hash generato può essere inviato al tuo server solo per la convalida.

Aggiungi un componente casuale

Se si utilizza un componente casuale oltre alla chiave privata, non solo è possibile garantire che solo l'utente possa autenticarlo, ma è possibile sapere esattamente quale sia l'installazione. Quando si genera l'hash, si utilizza la propria chiave privata e un ID univoco casuale e si associano entrambi con il nome utente sul server privato. Quando il software client invia questo nome utente e l'hash generato, è possibile utilizzare la chiave privata e il componente casuale associato per ottenere, se possibile, il passaggio dell'hash e confrontarli.

Fai in modo che la password funzioni esattamente una volta

Questo è l'ultimo chiodo nella bara e garantisce che non possano copiare e incollare l'intera installazione su un altro computer e installarlo lì. Se vuoi essere in grado di consentire, ad esempio, 100 installazioni possibili per un'azienda, puoi anche far funzionare la stessa chiave generata 100 volte. Ogni volta che il tuo server riceve una richiesta, decrementi quel contatore e quando raggiunge 0, il tuo server risponde che il programma ha esaurito tutte le licenze.

Ovviamente per far funzionare tutto questo, è ovvio che la prima volta che viene utilizzato il programma, richiede un nome utente e una password. Se la chiave generata è valida, il client deve seguire un nome utente e una password da associare a tale chiave / installazione. Possono quindi effettuare il login ogni volta successiva per l'installazione utilizzando il nome utente e la password forniti.

Rendi il programma fallito

Se la validazione fallisce, l'utente non dovrebbe essere in grado di fornire le credenziali per accedere al programma. Si dovrebbe fornire l'errore corretto indicativo del tipo di problema riscontrato con un messaggio che l'utente deve contattare l'amministratore o inviare una mail a questo indirizzo.

Certamente, usare questo metodo significa che l'utente deve avere accesso a Internet, ma è l'unico modo per essere sicuri. Non è possibile fare affidamento sul computer di installazione per la convalida. Anche dire, il numero di serie del disco rigido può essere falsificato eseguendo l'installazione su una macchina virtuale. Tuttavia per l'utente finale, questo sarebbe tutto trasparente tranne che per l'additivo minore che il computer dell'installazione deve avere accesso a Internet, e con ogni probabilità questo non dovrebbe causare alcun problema.