Un modo ragionevole per archiviare password crittografate nel database di una webapp, Linux

Hai solo bisogno di memorizzare la configurazione in un file accessibile solo all'utente in cui PHP è in esecuzione. Puoi impedire ad un utente web di accedere al file, ma PHP deve essere in grado di ottenere le credenziali e, indipendentemente da ciò che fai, saranno effettivamente non protette. Qualsiasi segreto che potresti fornire all'applicazione potrebbe essere scoperto, quindi non c'è alcun reale vantaggio nel tentativo di creare una catena complessa.

Oltre al solo file di configurazione, dovresti anche assicurarti che l'account SQL utilizzato dal tuo server web possa essere utilizzato solo dall'IP del server web e che abbia solo i diritti necessari per il server web. Se il tuo server web viene hackerato, otterrà l'accesso del server web al DB, ma se il tuo server web è hackerato, potrebbero anche solo sostituire gli script per fare in modo che il server web lo acceda come vogliono comunque.

Suppongo che tu sia su un server dedicato? Se sei su hosting condiviso è quasi impossibile proteggere gli script PHP.

Un approccio ragionevole è quello di memorizzare le password in un file di configurazione dedicato e limitare i permessi dei file in modo che questo sia leggibile solo dal proprietario .

Mi aspetto che le persone piangano "oh, ma non sono crittografate". Il fatto è che l'applicazione richiede le password in chiaro per connettersi al database. Quindi, se crittografate le password, è anche necessario avere la chiave disponibile, che sconfigge il punto. Ho visto ogni sorta di pazze proposte per migliorare su questo, ma tutto ciò che fanno è aggiungere complessità senza aggiungere alcuna sicurezza significativa.

Un'altra soluzione è implementare direttamente un client ssh all'interno dell'applicazione e dipendere da librerie di terze parti come JSch o estendere ssh/ssh-agent per ricevere e decifrare direttamente la chiave dal tuo database.

*EDIT*

La cosa importante è ciò che stai cercando di ottenere memorizzando la chiave nel database crittografato.

Un utente malintenzionato che è in grado di accedere al file della chiave privata temporanea sarà in grado di leggere anche la memoria del processo client ssh (e quindi di accedere ai dati della chiave), poiché entrambi questi dati devono avere sostanzialmente lo stesso accesso permessi: provare a nascondere il file non sembra renderlo più sicuro.

Se utilizzi utenti diversi per la connessione db, webapp e ssh, memorizzando la chiave nel db, decifrandola nella webapp e alimentandola con ssh, stai semplicemente aprendo i potenziali vettori di attacco diffondendo la chiave su tutto il processi. Se si sta utilizzando un solo utente per tutti questi (db, app, ssh), non si guadagna nulla se non per la complessità del codice.

L'unico vantaggio sembra essere un trasferimento più semplice del sistema a un host diverso e un potenziale guadagno nel caso in cui i dati DB vengano rubati, ma la webapp (che AFAIU contiene l'algoritmo e la password di decrittografia) non lo è. Ma è probabile?

Detto questo, se si desidera proteggere la chiave, è anche possibile utilizzare la crittografia interna della ssh delle chiavi e caricarle in un ssh-agent quando si avvia il servizio (ricordarsi di rimuoverlo quando si arresta!). Ma ricorda ancora che lo ssh-agent mantiene le chiavi in memoria non criptate, quindi può potenzialmente essere letto. Ancora una volta: è questo il problema che stai cercando di risolvere?

Se hai solo bisogno di proteggere le comunicazioni tra due macchine, stunnel potrebbe essere un servizio migliore di ssh.

Risposta generica sul titolo della domanda

Ci sono due modi per farlo.

1. Avere password non memorizzata nel server

Potrebbe essere, ma ovviamente niente potrebbe funzionare senza questa chiave essenziale!

In questo caso, il server delle applicazioni deve chiedere la password ad ogni avvio .

Ciò richiede un amministratore umano responsabile dell'avvio del server ogni volta che un errore si verifica e / o la manutenzione impone il riavvio del server.

2. Avere password memorizzata nel server.

Ovviamente, il livello dei diritti utilizzato per servire le pagine web non è uguale al livello corretto utilizzato per gestire il server!

Ma questa è l'unica cosa veramente importante.

Potresti fare un po 'di hardening: nascondi la password usando i file hiden, l'immagine stegano, o altro, ma questo è un po' inutile:

L'unica cosa importante è prevenire l'escalation dei privilegi :

Una volta che i cattivi raggiungono alti privilegi nel tuo server, seguendo passo dopo passo il processo di avvio per recuperare il modo in cui il server utilizza per leggere le sue credenziali è facile come mangiare un pezzo di torta .

Risposta generica sull'app sviluppata su GNU / Linux.

Il modo più semplice per garantire la corretta memorizzazione di tutte le credenziali su sistemi strutturati complessi è semplicemente installare Debian GNU / Linux con il solo sistema di base , piuttosto che installare solo i server richiesti seguendo prima la documentazione di Debian.

Una volta installato correttamente, mi prendo un sacco di tempo per sfogliare tutti i documenti, prima di eseguire la mia configurazione.

Arriva un test, rendendoli in esecuzione nel mio dominio locale.

Solo quando penso di aver compreso a sufficienza come funziona, potrei inserirlo nella rete pubblica.