Password dell'applicazione e sicurezza SQLite

Question

Ho cercato su Google informazioni per quanto riguarda password per le applicazioni e sicurezza SQLite per un po 'di tempo e nulla di ciò che ho trovato ha veramente risposto alle mie domande.

Qui è quello che sto cercando di capire:

1) La mia applicazione sta per avere un'attività password opzionale che verrà chiamato quando l'applicazione prima apertura. Le mie domande per questo sono a) Se memorizzo la password tramite preferenze Android o database SQLite, come posso garantire la sicurezza e la privacy per la password, e b) come deve essere gestito il recupero della password?

Per quanto riguarda b) da sopra, ho pensato di richiedere un indirizzo e-mail quando la funzione password è abilitata, e anche una domanda di suggerimento password da usare quando si richiede il recupero della password. Dopo aver risposto correttamente alla domanda di suggerimento, la password viene inviata via email all'indirizzo email che è stato inviato. Non sono completamente sicuro della sicurezza e della privacy del metodo di posta elettronica, soprattutto se l'e-mail viene inviata quando l'utente è connesso a una rete wireless pubblica aperta.

2) La mia applicazione utilizzerà un database SQLite, che verrà memorizzato sulla scheda SD se l'utente ne ha uno. Indipendentemente dal fatto che sia memorizzato sul telefono o sulla scheda SD, quali opzioni sono disponibili per la crittografia dei dati e in che modo ciò influisce sulle prestazioni dell'applicazione?

Grazie in anticipo per il tempo necessario per rispondere a queste domande. Penso che potrebbero esserci altri sviluppatori alle prese con le stesse preoccupazioni.

Answer 1

1) Il recupero della password è pericoloso. La forza della password è indebolita dalla risposta a una domanda, questo è il principio del collegamento più debole. Sara Palin's email hack è stato reso possibile grazie a questa funzione (molto) non sicura. Inoltre, se memorizzi la password in un "formato recuperabile" come in un codice a blocchi come AES o codice di flusso come RC4 o un codice asimmetrico come RSA, allora sei in chiara violazione di CWE-257. Se hai davvero bisogno di questa funzione, devi richiedere all'utente la password reimpostare la password, se non la conoscono, allora perché dovresti dirglielo?

Le password devono essere sempre sottoposte a hash con un digest messaggio sicuro. Attualmente molte funzioni di digest dei messaggi non sono sicure, md4, md5, sha0 e sha1 sono tutte molto danneggiate e non dovrebbero mai essere utilizzate per le password. Attualmente qualsiasi membro della famiglia sha2 è la migliore da usare, consiglio SHA-256. Il NIST sta attualmente organizzando un concorso per sha3 e non sarà finalizzato fino al 2012.

Le password devono anche essere "salate" con un grande valore casuale. Potrebbe trattarsi di un'altra colonna nel database che viene quindi aggiunta alla password di testo semplice prima di passarla alla funzione di digest del messaggio. Ciò rende impossibile l'attacco al dizionario a meno che l'aggressore non riesca a ottenere il sale, inoltre rende gli attacchi pre-calcolati molto più dispendiosi in termini di risorse da condurre con successo. Nonostante la conoscenza popolare, salatura non fermate tabelle arcobaleno, significa solo che è necessario un set di tavoli arcobaleno MUCH LARGER.

2) Dove mettere la chiave per il database crittografato? Sqlite è solo un file che è possibile crittografare e quindi decrittografarlo all'avvio dell'app, aggiungendo solo un po 'di tempo di caricamento ma in fase di esecuzione sarà altrettanto veloce. Il vero problema è che ci sono assolutamente nessun posto puoi mettere un segreto sul dispositivo che un attaccante non può ottenere. Un utente malintenzionato ha più controllo sul dispositivo rispetto a quello che fa, un utente malintenzionato può eseguire il jailbreak del dispositivo e fare tutto ciò che desidera.Anche se la chiave viene trasferita in fase di esecuzione, può comunque essere ottenuta guardando la memoria del dispositivo. Qualsiasi tentativo di crittografare il database può essere compromesso, può renderlo più difficile ma non fermerà un hacker esperto.