Come si può proteggere una password / chiave nel codice sorgente [duplicato]

Risposta breve: non puoi .

Non puoi mai proteggere una password che stai distribuendo. Potresti nasconderlo tra alcune stringhe e usare altre operazioni per "coprire" la password ma, alla fine, dovrai metterlo insieme per far funzionare la tua funzione. E qui è dove il cracker sta per prenderlo.

Non esiste un modo semplice per risolvere questo problema e in genere significa che non hai scelto il miglior schema di sicurezza o, se ritieni che sia sufficiente, forse significa che non hai proprio bisogno di questo tipo di sicurezza.

E se davvero, davvero, davvero hai bisogno di fare in quel modo devi andare con "sicurezza per oscurità" dopo tutto, più tempo ci vuole per essere incrinato, meglio è. È meglio avere un sistema di rilevamento per quando succede.

Ad esempio, considera l'industria del gioco in tutti questi anni con le loro protezioni di copia e così via, se ci fosse stato un modo per ottenere sicurezza all'interno del codice stesso, significherebbe la fine della "pirateria".

Mentre la risposta di @kiBytes è corretta da un punto di vista pratico, vorrei aggiungere per aggiungere che un documento recente di Amit Sahai suggerisce un modo (teorico) per costruire un obfuscator black box che sia crittograficamente "difficile" invertire. (Vedi qui per un articolo cablato su di esso).

Tuttavia, non è come se si potesse o addirittura si dovesse implementarlo: finora è completamente poco pratico da utilizzare su software reali e non è stato ancora adeguatamente controllato. È comunque interessante.

Come dice @kiBytes, semplicemente non è possibile proteggere una password o una chiave all'interno del codice sorgente. Vorrei aggiungere (nel caso in cui le persone arrivino a questa domanda cercando di risolvere un problema generale) che nell'esempio fornito (un'app che utilizza un'API), non è necessario che la chiave API sia memorizzata nel codice sorgente dell'app.

In genere, la chiave API è memorizzata su un server che controlli. Per accedere all'API, la tua app invia una richiesta al server, che a sua volta effettua una richiesta all'API, quindi risponde alla tua app con le informazioni che ha recuperato dall'API.

Per inciso, idealmente la chiave API non è memorizzata nel codice sorgente sul server, dal momento che è presumibilmente controllata in controllo di versione e quindi potenzialmente insicura.

Qualcosa che ho fatto 20 anni fa era dividere la chiave nei suoi singoli caratteri, quindi creare una collezione di oggetti che restituivano esplicitamente quei caratteri nella sequenza corretta una volta ordinati gli oggetti in base a un altro attributo delle classi. Con l'offuscamento, questo è piuttosto difficile da decifrare specialmente se l'ordine corretto degli oggetti è difficile da determinare (ad esempio, cambia a seconda dell'ambiente dell'applicazione).

Si noti che la pratica standard per memorizzare le password OVUNQUE è di non memorizzare mai la password stessa. Invece, memorizza il risultato di un hash crittografico (una "trappola", o unidirezionale, cifrario) della password. Quando l'utente immette una password, esegue l'hash allo stesso modo e confronta le versioni crittografate.

In questo caso, come sottolinea Brendan, la domanda è quella di autenticare il client piuttosto che il server. Questo è più difficile dal momento che il codice del cliente può teoricamente essere decodificato. Il miglior suggerimento che posso offrire è di far sì che il client stesso agisca come password in un sistema challenge-response: l'host invia una richiesta che un checksum crittografico venga calcolato da un (n apparentemente) sottoinsieme selezionato casualmente del programma, che l'host verificherà un risultato precompilato rispetto alla stessa versione del codice client.

Questo non protegge dalla pirateria, di per sé. Protegge contro l'accesso da parte di clienti diversi da quello approvato. Non so se risponde ai tuoi bisogni o no.