Codifica il file web.config utilizzando l'API di Data Protection

Dipende.

• Se l'attaccante ottiene l'accesso solo al web.config , quindi non è in grado di decrittografarlo senza la chiave, che si presume non possieda.

• Se hai impostato useMachineProtection su true nel DpapiProtectedConfigurationProvider configurazioni e l'utente malintenzionato accede al tuo computer (remoto o non) con qualsiasi account , quindi qualsiasi processo in esecuzione sulla macchina potrebbe decrittografare il file web.config , incluso tutto ciò che l'utente malintenzionato potrebbe eseguire.

• Se hai impostato useMachineProtection su falso nelle configurazioni DpapiProtectedConfigurationProvider , l'utente malintenzionato deve accedere all'account utente utilizzato per il processo (remoto o non).

Devi sapere che DPAPI fornisce una protezione basata su password . Pertanto, supponendo che si stia utilizzando l'opzione n. 3, anche se l'utente malintenzionato ottiene l'accesso fisico alla macchina, ha comunque bisogno della password dell'account per decrittografare le chiavi di crittografia che decrittografano i dati. Ovviamente, l'utente malintenzionato può facilmente reimpostare la password, ma ciò renderebbe inutilizzabili le chiavi crittografate e renderà i dati inaccessibili.

Nota che fino a .Net 3.5 SP1, useMachineProtection è impostato su true (cattivo) per impostazione predefinita. Non ho informazioni sulle versioni successive.

Aggiornamento: .Net 4.0 utilizza il valore predefinito true anche per useMachineProtection .

Suppongo che tu stia lavorando in .Net o forse in un livello inferiore come C ++. Di aver recentemente consumato queste API ecco cosa consiglierei.

Sono disponibili 2 provider di configurazioni protette, DPAPI (più appropriato per le applicazioni desktop lato client) e Provider RSA . Quest'ultimo è più appropriato per crittografare web.configs in quanto si tratta di una configurazione a chiave pubblica in cui solo il servizio ASP.NET ha la chiave privata per decrittografare i dati, questo può essere definito sia dall'utente che macchina, simile a DPAPI.

Qui è una vecchia, ma solida procedura di esso in ASP.Net. Mi scuso se non stai usando .Net, non è chiaro. Comunque penso che il provider RSA sia il modo corretto per andare qui.

Per quanto riguarda la rottura della crittografia DPAPI, sì la maggior parte degli attacchi dovrebbe essere orchestrata sulla macchina di destinazione, di solito coinvolgendo un tentativo con i file SAM della password o script di reimpostazione della password destinati agli amministratori di sistema. Documento relativo alla conferenza - rottura di DPAPI offline: BlackHat 2010 .