Recentemente ho discusso con alcuni dei miei colleghi nel mio lavoro perché hanno detto che è meglio avere in .DLL una connessione stringa crittografata. E ho detto perché non usare la connessione stringa definita nel web.config crittografato? è lo stesso ed è meglio perché il framework di entità, ad esempio, cerca il nome della connessione nella configurazione web dell'applicazione, Ora voglio sapere da un punto di sicurezza cosa c'è di meglio o qual è la migliore pratica?
Non c'è alcuna differenza sostanziale, tranne il fatto che dovrai effettivamente creare un binario se vuoi apportare una modifica alla configurazione se la inserisci in una DLL, mentre un amministratore potrebbe semplicemente modificare la configurazione con il ben noto off-the -sei strumenti se è nella configurazione. C'è già un meccanismo per crittografare le stringhe di configurazione e indicazioni aggiuntive su MSDN . Le versioni correnti di Asp.Net possono avere meccanismi alternativi, quindi fare qualche ricerca aggiuntiva prima di impegnarsi in un approccio.
Solo perché qualcosa è seduto in una DLL, non lo rende più sicuro. Un editor di testo può anche aprire file binari, strumenti come Reflector possono fornire un'interfaccia più gradevole per navigare in una DLL .Net; una DLL non fornirà alcuna crittografia "extra".
Non importa dove i dati crittografati sono archiviati, importa come è crittografato.
Le sezioni crittografate in un web.config sono normalmente crittografate con l'API Data Protection , che è estremamente difficile da decifrare senza compromettere l'intera macchina. Puoi anche utilizzare un contenitore di chiavi RSA, che è simile (difficile da togliere quelli dalla macchina).
Se vuoi memorizzare la stringa crittografata nella DLL, va bene, immagino, anche se non è intrinsecamente più sicuro di un web.config crittografato (chiunque può dare un'occhiata a quella DLL con Reflector ), ed è ovviamente più difficile da modificare (è necessario ricompilare). Ma ancora una volta, ciò che è molto più importante è come è stata generata quella stringa crittografata; presumibilmente non stai utilizzando gli stessi provider di un web.config crittografato, quindi cosa stai usando?
Uno schema di crittografia è strong quanto la chiave privata o il segreto condiviso. Se quella chiave è anche memorizzata nell'assieme, allora potreste anche non avere alcuna crittografia. Se è memorizzato in un database esterno, solleva la questione di come è protetta la stringa di connessione del tale database. Questo in realtà può solo portare a una sicurezza più debole in generale.
D'altra parte, se tu fossi un fornitore di servizi e la stringa di connessione fosse crittografata con una password utente , allora sarebbe più sicura rispetto all'utilizzo di una macchina statica chiave. Inoltre, se si utilizzano le password utente per crittografare, è improbabile che si stiano codificando i dati crittografati nell'assembly, poiché deve essere generato e archiviato in risposta all'azione dell'utente (non dello sviluppatore).
In realtà non riesco a pensare a troppe situazioni in cui l'hard-coding di una stringa di connessione (crittografata) nella DLL è più sicuro della crittografia della relativa sezione web.config. Nella migliore delle ipotesi è solo l'aggiunta di inconvenienti, nel peggiore dei casi si basa su una sicurezza personalizzata goffamente scritta piena di buchi. Fai un favore a te stesso e fai ciò che Microsoft consiglia: basta crittografare il tuo web.config se ci sono dati sensibili lì dentro.
Le best practice per ASP.NET sono tutte le configurazioni / impostazioni nel file web.config o nel file app.config (per altri tipi di progetto).
Informazioni sulla crittografia e il motivo per usarlo sulle stringhe di connessione devono essere un caso molto speciale. Poiché la maggior parte dei casi fino al 99% non è necessario crittografare le stringhe di connessione. Le proprie applicazioni aziendali hanno la loro stringa di connessione esposta nel file web.config / app.config. Penso che tu stia finendo per complicare la sicurezza.
Un'altra cosa, l'hard-coding delle stringhe di connessione è una cattiva pratica. Ad esempio, non inserire alcuna stringa di connessione (aka connectionstring) in una DLL o .aspx / .ascx / .cshtml o code-behind.
Leggi altre domande sui tag c# web-development security asp.net entity-framework