Risposta breve
Non puoi.
Se la password è memorizzata nell'elemento inviato all'utente finale, devi consideralo compromesso! Anche se l'artefatto è un binario compilato, ci sono sempre modi (più o meno complicati) per ottenere la password.
L'unico modo per proteggere le tue risorse è esporre solo un'API limitata all'utente finale. Crea un'API programmatica (REST, WS+SOAP, RMI, JavaEE+Servlet, ...) o esponi solo determinate funzionalità nel tuo DB tramite SPROC (vedi sotto).
Prima alcune cose...
La domanda qui non dovrebbe essere come nascondere la password, ma come proteggere il database. Ricorda che le sole password sono spesso una protezione molto debole e non devono essere considerate l'unico meccanismo di protezione del DB. Stai usando SSL? No? Bene, allora anche se riesci a nascondere la password nel codice dell'applicazione, è comunque facile sniffarla in rete!
Hai più opzioni. Il tutto con diversi gradi di sicurezza:
"Ruolo dell'applicazione"
Creare un utente di database per l'applicazione. Richiedi l'autorizzazione per questo ruolo. Una configurazione molto comune consiste nel consentire solo le operazioni CRUD.
Pro
- molto facile da configurare
- Previene
DROPquery (es. in SQL injection?)
Contro
- Chiunque vede la password ha accesso a tutti i dati nel database. Anche se tali dati sono normalmente nascosti nell'applicazione.
- Se la password è compromessa, l'utente può eseguire
UPDATEeDELETEquery senza criteri (es.:eliminare/aggiornare un'intera tabella in una volta).
Autenticazione atomica
Crea un utente del database per ogni applicazione/utente finale. Ciò consente di definire i diritti di accesso atomico anche per colonna. Ad esempio:l'utente X può selezionare solo colonne lontane e baz dalla tabella foo. E nient'altro. Ma l'utente Y può SELECT tutto, ma nessun aggiornamento, mentre l'utente Z ha pieno accesso CRUD (seleziona, inserisci, aggiorna, elimina).
Alcuni database consentono di riutilizzare le credenziali a livello di sistema operativo. Ciò rende trasparente l'autenticazione all'utente (è sufficiente effettuare il login alla workstation, l'identità viene quindi inoltrata al DB). Funziona più facilmente in uno stack MS completo (OS=Windows, Auth=ActiveDirectory, DB=MSSQL) ma, per quanto ne so, è possibile ottenerlo anche in altri DB.
Pro
- Abbastanza facile da configurare.
- Schema di autorizzazione molto atomico
Contro
- Può essere noioso impostare tutti i diritti di accesso nel DB.
- Utenti con
UPDATEeDELETEi diritti possono comunque eliminare/aggiornare accidentalmente (o intenzionalmente?) senza criteri. Rischi di perdere tutti i dati in una tabella.
Stored procedure con autenticazione e autenticazione atomica
Scrivi no Query SQL nella tua applicazione. Esegui tutto tramite SPROC. Quindi crea db-account per ogni utente e assegna i privilegi agli SPROC solo .
Pro
- Meccanismo di protezione più efficace.
- Gli SPROC possono costringere gli utenti a passare criteri a ogni query (incluso
DELETEeUPDATE)
Contro
- non sono sicuro che funzioni con MySQL (la mia conoscenza in quell'area è traballante).
- ciclo di sviluppo complesso:tutto ciò che vuoi fare, deve essere prima definito in una SPROC.
Pensieri finali
Non dovresti mai consentire attività di amministrazione del database all'applicazione. Il più delle volte, le uniche operazioni necessarie a un'applicazione sono SELECT , INSERT , DELETE e UPDATE . Se si seguono queste linee guida, non c'è quasi alcun rischio che gli utenti scoprano la password. Tranne i punti sopra menzionati.
In ogni caso, conserva i backup. Presumo che tu voglia proiettare il tuo database contro eliminazioni o aggiornamenti accidentali. Ma gli incidenti accadono... tienilo a mente;)
