Archiviare in modo sicuro una password nel codice del programma?

Question

La mia applicazione utilizza la classe Rijndaelmanaged per crittografare i dati. Come parte di questa crittografia, utilizzo un oggetto Securestring caricato con una password che viene convertita in un array di byte e caricato nella chiave dell'oggetto Rajindaelmanaged in fase di esecuzione.

La domanda che ho è lo stoccaggio di questo securioso. Una password inserita dall'utente può essere inserita in fase di esecuzione e questo può essere "in modo sicuro" caricato in un oggetto selettore, ma se non viene fornita alcuna password inserita dall'utente, devo predefinire qualcosa.

Quindi alla fine il Quesiton si riduce a:

Se devo avere qualche array di stringhe o byte noto da caricare in un oggetto secravo ogni volta che esegue la mia applicazione, come posso farlo? I dati "crittografati" alla fine vengono decrittografati da un'altra applicazione, quindi anche se non viene specificata alcuna password inserita dall'utente, ho ancora bisogno che i dati vengano crittografati mentre vanno da un'app all'altra. Ciò significa che non posso avere la password predefinita essere casuale, perché l'altra app non sarebbe in grado di decrittarla correttamente.

Una possibile soluzione che sto pensando è quella di creare una DLL che sputa solo una singola passphrase, quindi uso quella passphrase e lo eseguo attraverso un paio di diverse funzioni di hashing/riorganizzazione in fase di esecuzione prima che alla fine lo inserisca nell'oggetto lassore. Sarebbe abbastanza sicuro?

Modifica per chiarezza*: i dati crittografati vengono passati tramite file tra macchine. Pensalo come un file zip che ha sempre una password, si assume una predefinita se nulla viene inserito direttamente dall'utente.

Answer 1

Non ha senso crittografare simmetricamente con una stringa che è codificabile nel tuo eseguibile. Darà solo un falso senso di sicurezza. Nessuna quantità di hashing corregge questo schema.

Vedere Questa FAQ di Pidgin per lo stesso punto in un contesto diverso.

Non sono chiaro perché pensi di aver bisogno della comunicazione inter-app per essere crittografata. Se questa comunicazione è locale per la macchina, non vedo la necessità di crittografia, in particolare la crittografia che non è specifica dell'utente. È uno schema DRM?

EDIT: se viene passato a una macchina diversa, forse puoi codificare a un chiave pubblica, quindi avere l'altra macchina a decrittografare con la chiave privata corrispondente.

Answer 2

Lasciami affrontare prima la tua ultima domanda.

"Sarebbe abbastanza sicuro?"

L'unico a cui può rispondere che sei tu. Nessuno qui sa cosa significhi "abbastanza sicuro" nel contesto della tua applicazione.

Stai costruendo un'applicazione per mantenere il diario delle ragazze adolescenti? Certo, sarebbe "abbastanza sicuro".

Stai costruendo un'applicazione per crittografare informazioni o autenticazione per sistemi sicuri per il grado militare? No, nemmeno vicino.

Puoi fare affidamento su un tipo di sicurezza solo se si intende archiviare la password nel codice sorgente e quindi eseguibile, e questo è Sicurezza per oscurità.

Se il tuo problema è che non è possibile o non si memorizza la password nel codice sorgente, quindi spostarla in una DLL separata non risolve nulla, hai appena spostato il problema in un progetto diverso.

Tuttavia, mi chiedo qualcosa. Dici "Devo inadempienza a qualcosa". È quello? Stai cercando di archiviare un valore predefinito per la stringa di password sicura nel codice sorgente? Che ne dici di "thisisnotapassword"?

Answer 3

Eric Lippert's Vuoi sale con quello? (Post sul blog originale)

Leggi anche il suo post a Usa lo strumento giusto per il lavoro Dove finisce con i seguenti suggerimenti:

0) Se puoi, semplicemente non andarci. La crittografia è estremamente difficile da avere ragione ed è spesso la soluzione sbagliata in primo luogo. Usa altre tecniche per risolvere i tuoi problemi di sicurezza.

1) Se il problema è un cliente inaffidabile, non creare una soluzione di sicurezza che richiede la fiducia nel cliente.

2) Se è possibile utilizzare le parti standard, fallo.

3) Se non è possibile utilizzare le parti off-the-shelf e devi usare un criptosistema, non utilizzare un criptosistema che non si capisce completamente.

4) Se devi usare un criptosistema che non si capisce completamente, almeno non usarlo per risolvere i problemi che non è stato progettato per risolvere.

5) Se devi usare un criptosistema per sciare attraverso gli alberi, almeno non consentire al cliente presumibilmente ostile di scegliere il messaggio crittografato. Scegli tu stesso il token. Se il token deve includere le informazioni del cliente, quindi disinfettarle in qualche modo; Richiedi che sia solo testo ascii diritto, inserisci spazi bianchi casuali e così via.

6) Se è necessario consentire al client di scegliere il token, non crittografare il token stesso. Firma un hash crittograficamente sicuro del token. È molto più difficile per l'attaccante scegliere un segno che produce un hash desiderato.

7) Non utilizzare la stessa coppia di chiavi per crittografare i messaggi in uscita come fai per proteggere i messaggi in arrivo. Ottieni una coppia di chiavi per ogni operazione logicamente diversa che stai per eseguire.

8) Crittografare le comunicazioni in entrambi i modi.

9) Prendi in considerazione l'idea di avere un meccanismo di revoca, in modo che una volta che sai che Eva ti sta attaccando, puoi almeno revocare la sua licenza. (Oppure puoi revocare una licenza compromessa nota e così via.)

Answer 4

Questo articolo su proteggere le stringhe di connessione SQL Dovrebbe essere altrettanto applicabile per la memorizzazione di password crittografate, in cui si consente al sistema operativo di gestire la crittografia del seme di salata per la tua decrittografia.

Answer 5

Mi sembra che forse dovresti usare una soluzione PKI invece di crittografia/decrittazione. Se hai un'altra applicazione che deve consumare i dati crittografati, potresti avere una coppia di chiavi per quell'applicazione e fornire la chiave pubblica all'app che sta facendo la crittografia. In questo modo stai ancora mantenendo i tuoi dati sicuri, ma non introduci un mucchio di codice aggiuntivo che alla fine non dà così tanta protezione.

Una rapida ricerca di Google mi ha dato questo Articolo del progetto del codice che parla dell'utilizzo dell'archivio di certificati Windows in .NET