Quali sono le soluzioni sicure per proteggere credenziali importanti nel codice sorgente [duplicato]

Ci sono 2 ovvi problemi con le credenziali memorizzate nel codice sorgente:

1. Il codice sorgente può essere facilmente decodificato e le credenziali estratte.
2. Se le credenziali sono trapelate, dovresti cambiare la password sul server, cambiare la password nel codice, ricostruire e ridistribuire

Quindi un'opzione per aggirare entrambi questi problemi non è avere le credenziali nel codice sorgente. Un file di configurazione adeguatamente protetto può essere tutto ciò che serve, leggere le credenziali quando necessario, usarle e quindi cancellare la memoria dopo l'uso.

This also brings up the point that what if you have information such as FTP or DB login information in the client side application?

In questo caso sembra che tu voglia nascondere le credenziali nel tuo codice Java che sono molto probabilmente delle costanti String. Se questo è il caso questa domanda di StackOverflow può essere utile .

Quello che vuoi (e ho detto ciò che vuoi , che non è necessariamente ciò che hai bisogno come evidenziato da altre risposte e commenti) è chiamato offuscamento del codice .

L'offuscamento del codice è un insieme di tecniche che, dato un codice sorgente come input, producono un codice sorgente funzionalmente equivalente ma molto difficile da leggere / capire sull'output.

Tuttavia, tieni presente le conseguenze, non solo a monte, ma anche in futuro, poiché il tuo software diventerà molto più difficile da mantenere.

Ad esempio, Java si affida molto alle tracce dello stack per diagnosticare i problemi, in genere tale traccia dello stack fornisce informazioni chiare su dove si è verificato l'errore. Con un codice correttamente offuscato, la traccia dello stack non avrà più significato:

• I clienti non avranno alcun mezzo per risolvere anche problemi di base, aumentando così le chiamate ai tuoi servizi di supporto.
• Il tuo supporto avrà meno elementi da indagare dal cliente (in base alla mia esperienza, almeno che funge da cliente per tale azienda, sembra che non abbiano un mezzo facile per offuscare la propria traccia dello stack).

Nel campo del software aziendale, questo è usato raramente poiché il costo di solito va oltre i benefici (ma alcuni lo usano davvero) e una società davvero disposta a decodificare il software lo farà molto probabilmente comunque.

Questo potrebbe essere più frequente in alcuni domini specifici, come i giochi online (MMORPG per esempio) che si rivolgono a un pubblico sostanzialmente più ampio e dove i rischi associati al reverse engineering possono essere più alto Questo però non conta come una protezione affidabile, solo una misura tra le altre ideate per rallentare gli aggressori e scoraggiare i cracker occasionali (con gli stessi svantaggi per quanto riguarda i problemi di supporto e la scarsa relazione con i clienti).

Pensiamo a quale codice è per un secondo. Il codice è un elenco di istruzioni per un dispositivo (un processore) per fare qualcosa. I processori sono progettati dall'uomo, quindi è logico che un essere umano sia in grado di capire il codice progettato per esso ed essere in grado di replicare la sua funzionalità con un tempo e uno sforzo sufficienti.

Quello che stai cercando è essenzialmente impossibile - forse sarà con la crittografia quantistica dove semplicemente cercare a informazioni lo cambierà, ma nel frattempo non lo è.

Forse le soluzioni che descrivi saranno sufficienti per proteggere il tuo codice. Se stai solo cercando di impedire ai bambini di usare il tuo software questo farà il trucco, ma quegli stessi bambini probabilmente non avranno mai i soldi per comprare il tuo software comunque, quindi non è che stai perdendo molto. D'altra parte, immagina se da bambino ti trovassi di fronte a due società: una ti dà apertamente il codice e una che fa del suo meglio per impedirti di usarla - una volta adulto con soldi, se dovessi fare affari con una delle due loro, quale sceglieresti? Personalmente sceglierei il primo, perché mi aiutavano ancora mentre non avevo soldi per pagarli. Stai sostanzialmente risparmiando denaro a breve termine senza pensare a lungo termine.

Questo è simile alla pirateria. Alcune persone verseranno una quantità illimitata di denaro nel tentativo di prevenirlo, ma anche in quel caso alla fine verranno violate e tutti i soldi andranno sprecati.

Suggerisco un approccio diverso, invece di cercare di prevenire il furto / la pirateria che non sarai mai in grado di raggiungere completamente, prova invece a fare appello ai tuoi clienti paganti. Ne vale la pena per essere un cliente pagante. Forse è difficile da credere, ma ci sono persone che sono disposte a pagare per un buon software. Concentrati su di loro: hanno una richiesta di funzionalità o cercano supporto tecnico? Investi i tuoi soldi lì.

Se vuoi ancora provare a proteggere il tuo codice, c'è un modo per farlo. Inseritelo su un computer ospitato a casa e tenetelo d'occhio 24/24. O ancora meglio, non scrivere nemmeno codice (cosa succederebbe se la tua macchina di sviluppo fosse già compromessa?) E fare tutto ciò che fa la tua preziosa app, ma direttamente nella tua testa . Questo dovrebbe essere abbastanza sicuro e non devi fidarti di un fornitore di hosting o di dipendenti.

Spero che questo spieghi abbastanza bene perché hai per fidarti di qualcuno, come un fornitore di infrastrutture. Fortunatamente, non tutti sono un truffatore, e la maggior parte delle aziende di infrastrutture là fuori accoglieranno felicemente la tua applicazione, guadagnando bene da ciò che già fanno meglio senza tradire la tua fiducia e rubare la tua applicazione.

Vorrei raccomandare l'offuscamento, quindi rendere la password simile al codice offuscato, quindi lasciare un po 'di password honeypot.