Risposta generica: se l'autenticazione basata su password può essere eseguita offline, l'app necessariamente contiene tutto ciò che è necessario per decidere se una determinata password è corretta o meno. Ciò implica inevitabilmente che scaricando l'intero codice e il contenuto dell'app, l'utente malintenzionato può "emulare" il server offline sul proprio computer e provare le password a suo piacimento, limitate solo dalla potenza di calcolo che può raccogliere (quanti PC comprerà o affitto) e il costo computazionale inerente alla verifica di ogni singola password. Questa è chiamata attacco dizionario offline situazione.
Nella migliore delle ipotesi , in tal caso, puoi aumentare il costo utilizzando l'hashing lento (molte iterazioni di una funzione hash sottostante o qualcosa di simile) e i sali (per prevenire attacchi paralleli, condivisione dei costi , tabelle precalcolate ...). Vedi questa risposta per un trattamento completo.
Gli attacchi al dizionario offline sono una preoccupazione. Essere in una situazione del genere non è comodo. Se gli utenti accettano un'attesa di 1 secondo per l'autenticazione sul proprio smartphone, la CPU dello smartphone deve essere necessariamente in grado di verificare una password entro un secondo. Un aggressore con un buon PC sarà quindi in grado di "provare" almeno una dozzina di password al secondo; fare in modo che alcune centinaia se l'algoritmo di hash si adatta bene a quello che può fare la GPU off-the-shelf, alcune migliaia di volte l'attaccante è industrioso e va dritto a qualche FPGA . Inoltre, l'aggressore è spesso paziente e può permettersi di aspettare una o due settimane prima di ottenere una password utente. Ciò equivale, molto approssimativamente, a un miliardo di tentativi di password per l'autore dell'attacco.
Allenare gli utenti medi a scegliere password che resisteranno a un attacco di forza bruta di un miliardo di potenziali password, è difficile. Vedi questa domanda per qualche discussione sul soggetto. D'altra parte, se tu devi scegliere la password (non l'utente), seleziona una sequenza di 15 lettere casuali: sono 70 bit di entropia, e questo resisterà abbastanza a lungo per scoraggiare gli attaccanti ( uno spazio per le password di dimensioni 2 70 è enorme ).
Nota che i sali non sono intesi per essere segreti, e sono efficaci anche se conosciuti dall'attaccante. Un sale segreto non è un sale, ma un tasto . Non puoi averlo nella tua situazione: si deve presumere che l'attaccante abbia scaricato e decodificato il codice completo dell'app. In larga misura, il tuo contesto è simile a quello della crittografia basata su password: proteggere la riservatezza di un dato, per quanto riguarda una password segreta, senza hardware specifico.