Gli hacker potrebbero ottenere questa chiave quando ottengono l'accesso al file binario del server.
Quando non vi è alcun motivo per cui gli utenti abbiano bisogno di un accesso legittimo ai file binari del server (che dovrebbe essere il caso quando interagiscono con il server tramite rete), dovrebbe essere possibile indurire sufficientemente il server per rendere impossibile l'accesso.
Ma tieni presente che quando si esegue l'hardcode di una chiave segreta nella propria applicazione, chiunque abbia accesso al codice sorgente può perdere la chiave di una terza parte, intenzionalmente o accidentalmente. Per questo motivo sarebbe molto più intelligente leggere la chiave da un file di configurazione. In questo modo il team di sviluppo può lavorare con la propria chiave di sviluppo, mentre il server di produzione utilizza una chiave diversa che è disponibile solo per il sysadmin che distribuisce e mantiene il server in produzione.
Un'altra cosa che potrebbe morderti sta usando C per un'applicazione server rilevante per la sicurezza. Non voglio avviare un linguaggio di programmazione flamewar, ma il linguaggio di programmazione C è noto per alcune funzionalità che scambiano la sicurezza per le prestazioni e facilmente portano a vulnerabilità come buffer overflow che consentono un accesso arbitrario alla memoria o addirittura al codice esecuzione. Un bug trascurato in una parte del tuo netcode completamente indipendente potrebbe facilmente consentire a un utente malintenzionato di estrarre la memoria che memorizza la tua chiave (indipendentemente dal fatto che sia codificata o letta da un file di configurazione). Ma quando insisti a scrivere un'applicazione che è rilevante per la sicurezza in C, almeno fai attenzione con certe funzioni come memcpy , strcpy , sprintf e molte altre che si occupano di matrici e non eseguono il limite automatico controllo (che, come e perché è abbastanza roba per un'altra domanda).