Non inserire mai password nel codice. Questo è stato recentemente menzionato nella Top 25 degli errori di programmazione più pericolosi :
L'hardcoding di un account e di una password segreti nel tuo software è estremamente conveniente, per i tecnici esperti. Se la password è la stessa in tutto il software, ogni cliente diventa vulnerabile quando la password diventa inevitabilmente nota. E poiché è hard-coded, è un enorme problema da risolvere.
È necessario memorizzare le informazioni di configurazione, comprese le password, in un file separato che l'applicazione legge all'avvio. Questo è l'unico vero modo per evitare che la password venga persa a causa della decompilazione (non compilarla mai nel binario per cominciare).
Per ulteriori informazioni su questo errore comune, puoi leggere l' articolo CWE-259 . L'articolo contiene una definizione più completa, esempi e molte altre informazioni sul problema.
In Java, uno dei modi più semplici per farlo è utilizzare la classe Preferenze. È progettato per memorizzare tutti i tipi di impostazioni del programma, alcune delle quali potrebbero includere un nome utente e una password.
import java.util.prefs.Preferences;
public class DemoApplication {
Preferences preferences =
Preferences.userNodeForPackage(DemoApplication.class);
public void setCredentials(String username, String password) {
preferences.put("db_username", username);
preferences.put("db_password", password);
}
public String getUsername() {
return preferences.get("db_username", null);
}
public String getPassword() {
return preferences.get("db_password", null);
}
}
Nel codice sopra, puoi chiamare il setCredentialsmetodo dopo aver mostrato una finestra di dialogo che chiede il nome utente e la password. Quando è necessario connettersi al database, è possibile utilizzare semplicemente i metodi getUsernamee getPasswordper recuperare i valori memorizzati. Le credenziali di accesso non saranno codificate nei tuoi file binari, quindi la decompilazione non rappresenterà un rischio per la sicurezza.
Nota importante: i file delle preferenze sono solo file XML di testo semplice. Assicurati di adottare le misure appropriate per impedire agli utenti non autorizzati di visualizzare i file raw (autorizzazioni UNIX, autorizzazioni Windows, ecc.). In Linux, almeno, questo non è un problema, perché la chiamata Preferences.userNodeForPackagecreerà il file XML nella directory home dell'utente corrente, che comunque non è leggibile da altri utenti. In Windows, la situazione potrebbe essere diversa.
Note più importanti: ci sono state molte discussioni nei commenti di questa risposta e di altri su quale sia l'architettura corretta per questa situazione. La domanda originale in realtà non menziona il contesto in cui viene utilizzata l'applicazione, quindi parlerò delle due situazioni a cui riesco a pensare. Il primo è il caso in cui la persona che utilizza il programma conosce già (ed è autorizzata a conoscere) le credenziali del database. Il secondo è il caso in cui tu, lo sviluppatore, stai cercando di mantenere segrete le credenziali del database dalla persona che utilizza il programma.
Primo caso: l'utente è autorizzato a conoscere le credenziali di accesso al database
In questo caso, la soluzione che ho menzionato sopra funzionerà. La Preferenceclasse Java memorizzerà il nome utente e la password in testo normale, ma il file delle preferenze sarà leggibile solo dall'utente autorizzato. L'utente può semplicemente aprire il file XML delle preferenze e leggere le credenziali di accesso, ma questo non è un rischio per la sicurezza perché l'utente conosceva le credenziali per cominciare.
Secondo caso: tentativo di nascondere le credenziali di accesso all'utente
Questo è il caso più complicato: l'utente non dovrebbe conoscere le credenziali di accesso ma deve comunque accedere al database. In questo caso, l'utente che esegue l'applicazione ha accesso diretto al database, il che significa che il programma deve conoscere in anticipo le credenziali di accesso. La soluzione che ho menzionato sopra non è appropriata per questo caso. È possibile memorizzare le credenziali di accesso al database in un file delle preferenze, ma l'utente sarà in grado di leggere quel file, poiché sarà il proprietario. In effetti, non esiste davvero un buon modo per utilizzare questa custodia in modo sicuro.
Caso corretto: utilizzo di un'architettura multilivello
Il modo corretto per farlo è disporre di un livello intermedio, tra il server del database e l'applicazione client, che autentichi i singoli utenti e consenta di eseguire un insieme limitato di operazioni. Ogni utente avrebbe le proprie credenziali di accesso, ma non per il server del database. Le credenziali consentirebbero l'accesso al livello intermedio (il livello della logica aziendale) e sarebbero diverse per ogni utente.
Ogni utente avrebbe il proprio nome utente e password, che potrebbero essere memorizzati localmente in un file delle preferenze senza alcun rischio per la sicurezza. Questa è chiamata architettura a tre livelli (i livelli sono il server di database, il server della logica di business e l'applicazione client). È più complesso, ma è davvero il modo più sicuro per fare questo genere di cose.
L'ordine di base delle operazioni è:
- Il client si autentica con il livello di logica aziendale utilizzando il nome utente / password personali dell'utente. Il nome utente e la password sono noti all'utente e non sono correlati in alcun modo alle credenziali di accesso al database.
- Se l'autenticazione ha esito positivo, il client effettua una richiesta al livello di logica aziendale chiedendo alcune informazioni dal database. Ad esempio, un inventario di prodotti. Notare che la richiesta del client non è una query SQL; è una chiamata di procedura remota come
getInventoryList.
- Il livello di logica aziendale si connette al database e recupera le informazioni richieste. Il livello di logica aziendale è incaricato di formare una query SQL sicura in base alla richiesta dell'utente. Tutti i parametri della query SQL devono essere disinfettati per prevenire attacchi di SQL injection.
- Il livello di logica aziendale invia l'elenco di inventario all'applicazione client.
- Il cliente mostra l'elenco dell'inventario all'utente.
Notare che durante l'intero processo, l'applicazione client non si connette mai direttamente al database . Il livello di logica aziendale riceve una richiesta da un utente autenticato, elabora la richiesta del client per un elenco di inventario e solo successivamente esegue una query SQL.