Prima regola della sicurezza delle app: qualsiasi macchina a cui un utente malintenzionato ottiene l'accesso fisico o elettronico senza restrizioni ora appartiene al tuo aggressore, indipendentemente da dove si trovi effettivamente o da cosa l'hai pagato.
Seconda regola della sicurezza delle app: qualsiasi software che lasci i confini fisici all'interno dei quali un attaccante non può penetrare ora appartiene al tuo attaccante, indipendentemente da quanto tempo hai impiegato per codificarlo.
Terza regola: qualsiasi informazione che lasci quegli stessi confini fisici che un attaccante non può penetrare ora appartiene al tuo attaccante, non importa quanto sia prezioso per te.
Le basi della sicurezza informatica si basano su questi tre principi fondamentali; l'unico computer veramente sicuro è quello chiuso in una cassaforte, dentro una gabbia di Farraday, dentro una gabbia d'acciaio. Ci sono computer che trascorrono la maggior parte delle loro vite di servizio proprio in questo stato; una volta all'anno (o meno), generano le chiavi private per le autorità di certificazione radice attendibili (di fronte a una miriade di testimoni con telecamere che registrano ogni centimetro della stanza in cui si trovano).
Ora, la maggior parte dei computer non viene utilizzata in questi tipi di ambienti; sono fisicamente all'aperto, collegati a Internet tramite un canale radio wireless. In breve, sono vulnerabili, così come il loro software. Pertanto non ci si deve fidare di loro. Ci sono alcune cose che i computer e i loro software devono sapere o fare per essere utili, ma bisogna fare attenzione a garantire che non possano mai sapere o fare abbastanza per causare danni (almeno non danni permanenti al di fuori dei limiti di quella singola macchina ).
Sapevi già tutto questo; ecco perché stai cercando di proteggere il codice della tua applicazione. Ma qui sta il primo problema; gli strumenti di offuscamento possono rendere il codice un casino per un essere umano che cerca di scavare, ma il programma deve ancora essere eseguito; ciò significa che il flusso logico effettivo dell'app e i dati che utilizza non sono interessati dall'offuscamento. Data una certa tenacia, un utente malintenzionato può semplicemente annullare l'offuscamento del codice, e ciò non è nemmeno necessario in alcuni casi in cui ciò che sta guardando non può essere nient'altro che ciò che sta cercando.
Invece, dovresti cercare di assicurarti che un utente malintenzionato non possa fare nulla con il tuo codice, non importa quanto sia facile per lui ottenerne una copia chiara. Ciò significa che non esistono segreti codificati, poiché tali segreti non sono segreti non appena il codice lascia l'edificio in cui è stato sviluppato.
Questi valori-chiave che hai hardcoded dovrebbero essere completamente rimossi dal codice sorgente dell'applicazione. Invece, dovrebbero trovarsi in uno dei tre posti; memoria volatile sul dispositivo, che è più difficile (ma non impossibile) per un utente malintenzionato ottenere una copia offline di; permanentemente sul cluster di server, a cui controlli l'accesso con un pugno di ferro; o in un secondo archivio di dati non correlato al dispositivo o ai server, ad esempio una scheda fisica o le memorie dell'utente (il che significa che alla fine sarà nella memoria volatile, ma non deve durare a lungo).
Considera il seguente schema. L'utente inserisce le proprie credenziali per l'app dalla memoria nel dispositivo. Sfortunatamente, devi fidarti che il dispositivo dell'utente non è già stato compromesso da un keylogger o da un Trojan; il meglio che puoi fare al riguardo è implementare la sicurezza a più fattori, ricordando le informazioni identificative difficili da falsificare sui dispositivi utilizzati dall'utente (MAC / IP, IMEI, ecc.) e fornendo almeno un canale aggiuntivo tramite che può essere verificato un tentativo di accesso su un dispositivo sconosciuto.
Le credenziali, una volta inserite, vengono offuscate dal software client (usando un hash sicuro) e le credenziali in testo normale vengono scartate; hanno servito al loro scopo. Le credenziali offuscate vengono inviate su un canale protetto al server autenticato con certificato, che le esegue nuovamente l' hashing per produrre i dati utilizzati per verificare la validità dell'accesso. In questo modo, il client non sa mai cosa viene effettivamente confrontato con il valore del database, il server delle app non conosce mai le credenziali in chiaro dietro ciò che riceve per la validazione, il data server non sa mai come vengono prodotti i dati che archivia per la validazione, e un uomo in la parte centrale vede solo incomprensibili anche se il canale sicuro fosse compromesso.
Una volta verificato, il server trasmette un token sul canale. Il token è utile solo all'interno della sessione sicura, è composto da rumore casuale o da una copia crittografata (e quindi verificabile) degli identificativi di sessione e l'applicazione client deve inviare questo token sullo stesso canale al server come parte di qualsiasi richiesta fare qualcosa. L'applicazione client lo farà molte volte, perché non può fare nulla che coinvolga denaro, dati sensibili o qualsiasi altra cosa che possa essere dannosa da sola; deve invece chiedere al server di eseguire questa attività. L'applicazione client non scriverà mai alcuna informazione sensibile nella memoria persistente sul dispositivo stesso, almeno non in testo normale; il client può chiedere al server sul canale sicuro una chiave simmetrica per crittografare tutti i dati locali, che il server ricorderà; in una sessione successiva il client può richiedere al server la stessa chiave per decrittografare i dati da utilizzare nella memoria volatile. Quei dati non saranno neanche l'unica copia; tutto ciò che il client memorizza dovrebbe anche essere trasmesso in qualche forma al server.
Ovviamente, ciò rende l'applicazione fortemente dipendente dall'accesso a Internet; il dispositivo client non può eseguire nessuna delle sue funzioni di base senza una corretta connessione e autenticazione da parte del server. Non diverso da Facebook, davvero.
Ora, il computer che l'aggressore vuole è il tuo server, perché esso e non l'app / dispositivo client è la cosa che può fargli guadagnare denaro o causare dolore ad altre persone per il suo divertimento. Va bene; ottieni molto più denaro per i tuoi soldi spendendo denaro e sforzi per proteggere il server che nel tentativo di proteggere tutti i client. Il server può essere protetto da tutti i tipi di firewall e altri sistemi di sicurezza elettronica e inoltre può essere fisicamente protetto da acciaio, cemento, accesso con chiave magnetica / pin e videosorveglianza 24 ore su 24. Il tuo aggressore dovrebbe essere davvero molto sofisticato per ottenere direttamente qualsiasi tipo di accesso al server e dovresti (dovresti) saperlo immediatamente.
Il meglio che un utente malintenzionato può fare è rubare il telefono e le credenziali di un utente e accedere al server con i diritti limitati del client. Se ciò dovesse accadere, proprio come la perdita di una carta di credito, l'utente legittimo dovrebbe essere istruito a chiamare un numero 800 (preferibilmente facile da ricordare, e non sul retro di una carta che porterebbe nella borsa, nel portafoglio o nella valigetta che potrebbe essere rubato insieme al dispositivo mobile) da qualsiasi telefono a cui possano accedere che li colleghi direttamente al servizio clienti. Dichiarano che il loro telefono è stato rubato, forniscono alcuni identificativi univoci di base e l'account è bloccato, tutte le transazioni che l'attaccante potrebbe essere stato in grado di elaborare vengono ripristinate e l'attaccante torna al punto di partenza.