La sicurezza è una cosa relativa. Niente è completamente sicuro. L'idea di sicurezza è quella di rendere abbastanza difficile sfondare la tua sicurezza che, si spera, non valga il tempo e gli sforzi necessari. Ciò dipende dalla motivazione della persona malintenzionata che di solito dipende dal tipo di informazioni elaborate o archiviate o dai servizi che vengono eseguiti. Puoi paragonarlo a mettere un lucchetto sulla tua porta di casa. La maggior parte delle serrature non sono molto sicure in quanto qualcuno addestrato a sceglierle/bypassarle in genere può farlo molto facilmente. Ma impediscono alla persona media di scegliere di aprire la porta solo per tentazione casuale o curiosità.
Se la natura dell'applicazione che si sta facendo è che deve essere il più sicuro possibile, allora mi sembra che Electron non sia la soluzione migliore. Le persone possono visualizzare il tuo codice direttamente.Anche se è offuscato, questo li lascia ancora con il codice javascript, e come sottolineato da @ Cenebyte321, può essere un po '"abbellito". Sebbene una versione abbellita di codice correttamente offuscato non sarebbe codice pulito o leggibile in termini dei concetti presentati da esso. Non sarebbe nulla vicino all'originale. Altrimenti, potresti semplicemente prendere qualsiasi codice funzionante e renderlo leggibile e ben organizzato semplicemente eseguendo un beautifier su di esso. È bene rendersi conto che tecnicamente è possibile decompilare qualsiasi eseguibile di nuovo al codice sorgente. Anche un programma binario scritto in C può essere trasformato in codice C. In quel caso, il codice "offuscato" prodotto sarebbe probabilmente ancora più oscuro, quindi c'è un qualche vantaggio in questo. Ma ancora, può essere decompilato e dovrebbe essere un codice C valido.
Una volta che il codice dannoso si trova su un sistema, è molto difficile proteggerlo. La cosa più importante è assicurarsi che tutti i server con cui l'app sta comunicando siano sicuri (di nuovo, in senso relativo) e che l'API per loro sia sicura. Dovrebbe essere abbastanza sicuro che se qualcuno guarda il codice sorgente della tua app e capisce come funziona l'API del tuo server, non è un problema per te. Qualsiasi comunicazione sensibile a un server dovrebbe essere crittografata. Non vuoi che il nome utente e la password dell'amministratore siano nel codice sorgente. Ma non lo vuoi con nessuna app scritta in nessuna lingua. Idealmente, tutte le password salvate sul computer dell'utente dovrebbero essere trasformate in qualche modo prima di essere salvate (possibilmente salate in più modi e hash, o qualsiasi altra cosa facciano i bambini fantastici in questi giorni) in modo che se qualcuno ottiene l'accesso a tali dati , vedono solo una versione modificata di esso. Quando questo viene fatto correttamente, non ci dovrebbe essere un modo per decrittografare le password, sebbene ci siano tecniche che le persone possono usare per provare a produrre una password che risulterà nello stesso hash. Dovresti solo confrontare la versione modificata di una password normalmente inserita con la versione modificata salvata della password attuale. I principi per archiviare le password in modo sicuro e avere API e comunicazioni sicure su un server non sono specifici di Electron, qualsiasi linguaggio o framework che si utilizzi richiederà la stessa attenta riflessione sulla sicurezza.
Nel caso in cui le mie parole fossero fuorvianti, non intendevo che sarebbe prassi normale archiviare localmente le password utilizzate per accedere al server. Idealmente, l'utente dovrebbe digitare password di quella natura per ciascuna sessione e non verrebbe mai memorizzato localmente. Ma per comodità molte app ti permettono di memorizzare localmente una password, in modo da non doverla digitare ogni volta. In realtà, dipende da quanto sono sensibili i dati cui si accede da tali password e da quanto sia importante la convenienza per gli utenti.
Tuttavia, se il software dannoso è in esecuzione sui computer degli utenti, è probabile che sia possibile registrare le sequenze di tasti in qualsiasi modo e distinguere nomi utente e password in questo modo. Persino le comunicazioni crittografate non sono infallibili, poiché alla fine vengono scoperti dei buchi di sicurezza e vengono sviluppati nuovi protocolli. A volte i governi o altre persone sanno di backdoor che sono stati progettati intenzionalmente in un tipo di crittografia. Spero solo che nessun altro abbia ancora trovato quelle backdoor, dato che sono essenzialmente dei difetti di sicurezza progettati intenzionalmente nei protocolli di crittografia. Poiché gli strumenti javascript diventano più avanzati, è possibile che il codice javascript offuscato possa essere quasi oscuro e confuso come codice C offuscato o forse ci sono già strumenti che lo fanno.
Oh giusto OSX non iOS.Grazie mille per tutte le informazioni che hai fornito. – Savaratkar
risposta è accettata :) – Savaratkar