È sicuro memorizzare una password nel codice compilato? [duplicare]

No, non è sicuro.

Qualsiasi applicazione compilata può essere smontata ed esaminata. Il bytecode CIL generato dal compilatore C # può essere seguito da istruzioni come qualsiasi altro linguaggio di programmazione. Quando si esegue l'hardcode della chiave crittografica, questa verrà visualizzata da qualche parte nell'assieme. (lo stesso vale per il codice macchina generato dai compilatori "reali", tra l'altro). Non è se qualcuno troverà la tua chiave, la domanda è quando .

Potresti codificare la tua chiave, ma l'algoritmo di codifica deve anche far parte dell'assembly, quindi può essere trovato e utilizzato dall'hacker.

Potresti usare qualche codice offuscatore che rende l'assembly meno leggibile, ma che di solito influisce negativamente sulle prestazioni ed è anche solo un ulteriore ostacolo che costerà più tempo all'attaccante ma non gli impedirà di trovarlo quando è sufficientemente diligente.

Per aggiungere alla risposta di Philipp:

Non è né sicuro, né può essere reso sicuro, indipendentemente da quanto impegno ci metti.

Ma puoi rendere più facile affrontare i problemi. Se la chiave viene archiviata in un file esterno invece che nel codice del programma, è molto più semplice da modificare. Pertanto, mentre non è possibile proteggere la chiave dall'essere rubata e i dati da decrittografare, è possibile semplificare la sostituzione periodica della chiave, in modo che un utente malintenzionato debba periodicamente recuperare l'accesso alla chiave se desidera continuare a leggere i dati crittografati . Ciò aumenta le possibilità di essere scoperto (potrebbe inciampare prima o poi in qualche tipo di sistema di rilevamento delle intrusioni, o fare uno stupido errore)

Separare chiave e applicazione facilita anche la protezione della chiave: ora è sufficiente proteggere un file di piccole dimensioni senza doversi preoccupare di dove possono essere archiviati il binario dell'applicazione e il codice sorgente (si pensi ai sistemi di controllo della versione, pacchetto manager, ambienti di build automatizzati, backup, ecc.)

Mantenere la chiave in un file esterno è anche una buona idea perché, a seconda della piattaforma su cui si sta eseguendo, l'applicazione può iniziare con autorizzazioni elevate che gli consentono di leggere la chiave e quindi rilasciare queste autorizzazioni in modo che, mentre è in esecuzione, non avrà più accesso alla chiave memorizzata. Ciò impedirà alcuni tipi di attacchi, anche se un attaccante sofisticato può sempre estrarre la chiave dalla memoria dell'applicazione.

A seconda di ciò che fa l'applicazione, potrebbe anche essere possibile ridurre in modo significativo la superficie di attacco. Se una parte dell'applicazione scrive sempre solo dati segreti, è possibile suddividere l'applicazione in due parti e utilizzare la crittografia a chiave pubblica per evitare di doversi preoccupare della prima applicazione, quella che deve solo scrivere i dati, ma non leggerla di nuovo. In tal caso, si fornisce alla prima applicazione una chiave pubblica per crittografare una chiave di sessione, che si utilizza per scrivere i dati segreti. Ora devi solo proteggere la seconda applicazione, che legge i dati indietro, o meglio, la chiave privata a cui questa applicazione ha accesso.

No, non è sicuro e devi modificare la tua architettura se vuoi proteggerla.

La tua architettura attuale

Client application < -- > Web services

Per comunicare con i servizi Web è necessaria una password segreta che l'utente non dovrebbe conoscere. Ma poiché l'applicazione client è installata sul computer dell'utente, non c'è modo di proteggere quella password come le altre risposte hanno menzionato.

Ora per proteggere, queste password sono necessarie per cambiare la tua architettura.

Una nuova architettura

Client application < -- > Intermediate Server < -- > Web services

Ora è possibile memorizzare in modo sicuro le password dei servizi Web sul server intermedio. Di solito, lo fai usando un file di configurazione esterno al tuo codice sorgente per il server intermedio.

E ...

Ora, la domanda è: come proteggi l'accesso al server intermedio? Ma probabilmente dovrebbe essere un'altra domanda.

Come hanno spiegato le altre risposte, il tuo approccio è insicuro. Tuttavia, per aggiungere alle altre risposte, esiste un concetto che tenta di risolvere un problema simile (almeno dal punto di vista pratico: principalmente, se il segreto è in possesso dell'attaccante, comunque offuscato, è necessario considerarlo liberamente utilizzabile dall'attaccante), che si chiama crittografia white-box. Vedi per es. questa domanda e whiteboxcrypto.com :

The challenge that white-box cryptography aims to address is to implement a cryptographic algorithm in software in such a way that cryptographic assets remain secure even when subject to white-box attacks.

Il punto è che non puoi usare concetti e metodi "classici", ad es. "Hard-coding la passphrase nella mia classe" mentre scrivi. Dovresti "inserire" l'algoritmo di crittografia e la chiave in una trasformazione "offuscata".