Come posso proteggere il nome utente e la password di MySQL dalla decompilazione?

StackOverflow https://stackoverflow.com/questions/442862

Domanda

I file

Java .class possono essere decompilati abbastanza facilmente. Come posso proteggere il mio database se devo usare i dati di accesso nel codice?

È stato utile?

Soluzione

Non inserire mai password nel tuo codice. Questo è stato riportato di recente negli I 25 errori di programmazione più pericolosi :

  

Codifica hard di un account segreto e   password nel tuo software è   estremamente conveniente - per esperti   ingegneri inversi. Se la password è   lo stesso su tutto il software,   quindi ogni cliente diventa vulnerabile   quando quella password diventa inevitabilmente   conosciuto. E poiché è codificato,   è un grande dolore da risolvere.

È necessario archiviare le informazioni di configurazione, comprese le password, in un file separato che l'applicazione legge all'avvio. Questo è l'unico vero modo per impedire la perdita della password a causa della decompilazione (per cominciare, non compilarla mai nel binario).

Per ulteriori informazioni su questo errore comune, è possibile leggere Articolo CWE-259 . L'articolo contiene una definizione più approfondita, esempi e molte altre informazioni sul problema.

In Java, uno dei modi più semplici per farlo è usare 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);
  }

  // your code here
}

Nel codice sopra, è possibile chiamare il metodo setCredentials dopo aver mostrato una finestra di dialogo che richiede nome utente e password. Quando è necessario connettersi al database, è possibile utilizzare i metodi getUsername e getPassword per recuperare i valori memorizzati. Le credenziali di accesso non saranno codificate nei file binari, quindi la decompilazione non costituirà un rischio per la sicurezza.

Nota importante: i file delle preferenze sono solo file XML di testo semplice. Assicurarsi di adottare le misure appropriate per impedire agli utenti non autorizzati di visualizzare i file non elaborati (autorizzazioni UNIX, autorizzazioni di Windows, ecc.). Almeno in Linux questo non è un problema, perché la chiamata di Preferences.userNodeForPackage creerà il file XML nella home directory dell'utente corrente, che comunque non è leggibile da altri utenti. In Windows, la situazione potrebbe essere diversa.

Note più importanti: C'è stata molta discussione nei commenti di questa risposta e altri su quale sia l'architettura corretta per questa situazione. La domanda originale in realtà non menziona il contesto in cui l'applicazione viene utilizzata, quindi parlerò delle due situazioni che mi vengono in mente. 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 le credenziali del database segrete alla 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 classe Java Preference memorizzerà il nome utente e la password in testo semplice, 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, dal momento che th

Altri suggerimenti

Metti la password in un file che l'applicazione leggerà. Non incorporare MAI le password in un file sorgente. Periodo.

Ruby ha un modulo poco noto chiamato DBI :: DBRC per tale utilizzo. Non ho dubbi che Java abbia un equivalente. Comunque, non è difficile scriverne uno.

Stai scrivendo un'applicazione web? In tal caso, utilizzare JNDI per configurarlo esternamente all'applicazione. Una panoramica è disponibile qui :

  

JNDI fornisce un modo uniforme per un   applicazione per trovare e accedere al telecomando   servizi in rete. Il remoto   il servizio può essere qualsiasi servizio aziendale,   tra cui un servizio di messaggistica o un   servizio specifico dell'applicazione, ma di   ovviamente, è un'applicazione JDBC   interessato principalmente a un database   servizio. Una volta che un oggetto DataSource è   creato e registrato con un JNDI   servizio di denominazione, un'applicazione può utilizzare   l'API JNDI per accedere a tale origine dati   oggetto, che può quindi essere utilizzato per   connettersi all'origine dati   rappresenta.

Indipendentemente da ciò che fai, le informazioni sensibili verranno archiviate in qualche file da qualche parte. Il tuo obiettivo è renderlo il più difficile possibile. Quanto puoi ottenere dipende dal tuo progetto, dalle esigenze e dallo spessore del portafoglio della tua azienda.

Il modo migliore non è memorizzare alcuna password ovunque. Ciò si ottiene utilizzando le funzioni hash per generare e archiviare gli hash delle password: 

hash("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
hash("hbllo") = 58756879c05c68dfac9866712fad6a93f8146f337a69afe7dd238f3364946366
  

Gli algoritmi hash sono funzioni a senso unico. Trasformano qualsiasi quantità di dati   in una "impronta digitale" a lunghezza fissa " che non può essere invertito. Essi anche   hanno la proprietà che se l'input cambia anche di un pochino, il   l'hash risultante è completamente diverso (vedi l'esempio sopra). Questo   è ottimo per proteggere le password, perché vogliamo archiviare le password   in una forma che li protegge anche se lo stesso file di password è   compromesso, ma allo stesso tempo, dobbiamo essere in grado di verificare che a   la password dell'utente è corretta.

Nota non correlata: Ai vecchi tempi di Internet, quando si fa clic sul collegamento "password dimenticata", i siti Web inviano tramite e-mail la password in chiaro. Probabilmente stavano memorizzando quelli in un database da qualche parte. Quando gli hacker avessero accesso al loro database, avrebbero avuto accesso a tutte le password. Poiché molti utenti usavano la stessa password in più siti Web, questo era un enorme problema di sicurezza. Fortunatamente, al giorno d'oggi questa non è una pratica comune.

Ora arriva la domanda: qual è il modo migliore per archiviare le password? Considererei questa (soluzione del percorso di tempesta del servizio di gestione degli utenti e di autenticazione) una dannata ideale:

  1. L'utente inserisce le credenziali e questo viene convalidato rispetto a hash della password
  2. Gli hash delle password vengono generati e memorizzati, non le password
  3. Gli hash vengono eseguiti più volte
  4. Gli hash vengono generati utilizzando un salt generato in modo casuale
  5. Gli hash sono crittografati con una chiave privata
  6. La chiave privata viene archiviata in un luogo fisicamente diverso dagli hash
  7. Le chiavi private sono aggiornate in base al tempo
  8. Gli hash crittografati sono divisi in blocchi
  9. Questi blocchi sono memorizzati in posizioni fisicamente separate

Ovviamente non sei il google o una banca, quindi questa è una soluzione eccessiva per te. Ma poi arriva la domanda: quanta sicurezza richiede il tuo progetto, quanto tempo e denaro hai?

Per molte applicazioni, sebbene non sia raccomandato, l'archiviazione di password hardcoded nel codice potrebbe essere una soluzione abbastanza valida. Tuttavia, aggiungendo facilmente un paio di passaggi aggiuntivi di sicurezza dall'elenco sopra, puoi rendere la tua applicazione molto più sicura.

Ad esempio, supponiamo che il passaggio 1 non sia una soluzione accettabile per il tuo progetto. Non si desidera che gli utenti immettano la password ogni volta o che non si desideri / non sia nemmeno necessario che gli utenti conoscano la password. Hai ancora informazioni sensibili da qualche parte e vuoi proteggerle. Hai una semplice applicazione, non esiste un server per archiviare i tuoi file o questo è troppo fastidioso per il tuo progetto. L'applicazione viene eseguita in ambienti in cui non è possibile archiviare i file in modo sicuro. Questo è uno dei casi peggiori, ma con qualche ulteriore misura di sicurezza puoi avere una soluzione molto più sicura. Ad esempio, è possibile archiviare le informazioni sensibili in un file e crittografare il file. È possibile avere la chiave privata di crittografia codificata nel codice. Puoi offuscare il codice, quindi rendi un po 'più difficile per qualcuno decifrarlo. Esistono molte librerie per questo scopo, vedi questo link . (Voglio avvertirti ancora una volta che questo non è sicuro al 100%. Un hacker intelligente con le giuste conoscenze e strumenti può hackerarlo. Ma basato su

Questa domanda mostra come archiviare password e altri dati in un file crittografato: Crittografia basata su password AES a 256 bit Java

MD5 è un algoritmo di hash, non un algoritmo di crittografia, in breve non puoi tornare indietro con l'hash, puoi solo confrontare. Dovrebbe essere idealmente usato quando si memorizzano le informazioni di autenticazione dell'utente e non nome utente e password db. db username e pwd dovrebbero essere crittografati e tenuti in un file di configurazione, per non dire altro.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top