In generale, se la tua app mobile è basata su servizi Web remoti, devi stabilire una connessione sicura (ssl / tls) al server remoto e passare il nome utente / password direttamente al server per l'elaborazione sul server, non su il cliente.
Presumo che questa sia una specie di server web. Quasi sicuramente non ti connetteresti direttamente dalla tua app mobile a un server di database spoglio, giusto?
Che cosa non farebbe per copiare la password fornita dall'utente sul telefono, quindi passare l'hash attraverso il cavo per il confronto sul server. Il compito dell'autenticazione del server è di confermare che la parte remota conosca la password corretta per il nome utente fornito, non che la parte remota conosca la password corretta hash per il nome utente.
Altrimenti, un utente malintenzionato che potrebbe avere accesso al proprio database delle credenziali potrebbe semplicemente passare un hash di nome utente e password e non dovrà mai conoscere la vera password. Oops! : -).
Se intendi eseguire il rollover della tua autenticazione sul server, dovrai archiviare almeno 3 campi:
- lo username
- hash della password
- salt (entropia generata in modo casuale, univoco per utente)
Dovresti anche considerare di memorizzare:
-
un ID della versione hash della password, in modo che tu possa passare a un algoritmo aggiornato in futuro senza automaticamente invalidando tutte le tue password esistenti
-
una data / ora di scadenza della password (o qualche variazione di questo concetto) in modo da poter scadere le password quando necessario o farle scadere automaticamente dopo una certa età
L'hash di sale e password sono array di byte quando completamente ricostituiti nella memoria del computer. Convertili in stringhe con codifica Base64 per la memorizzazione.
L'hashing semplicemente la password è considerata insufficiente ora:
-
anche se usi salt e anche se usi un algoritmo hash sostanziale come SHA256 o SHA512
- usare l'hashing semplice senza sale è stato quello che ha creato un certo servizio di networking aziendale di grandi dimensioni in così tanti problemi con la loro ultima violazione dell'account utente
-
i metodi di attacco del dizionario che utilizzano le GPU su potenti schede video combinate con dizionari o tabelle arcobaleno rendono necessario rendere i confronti delle password abbastanza lenti da non meritare lo sforzo
-
MD5 non è affatto all'altezza del compito e non è stato a lungo
-
SHA1 ha exploit teorici ed è considerato debole ora (almeno potenzialmente, solo una questione di tempo prima che venga sfruttato)
-
SHA256 o SHA512 sono migliori, ma ancora troppo veloci
Utilizza un algoritmo effettivamente progettato per le password di hashing, come bcrypt , scrypt o PBKDF2 .
-
Questi tipi di algoritmi si basano su algoritmi di hashing come SHA1 o SHA256, più algoritmi HMAC , quindi eseguono l'iterazione di molti tempi (forse migliaia o più) che alimentano il risultato di ogni iterazione nell'algoritmo per renderlo in modo infettabile lento per un aggressore di forza bruta per eseguire miliardi di confronti da un dizionario / tavolo arcobaleno, pur essendo abbastanza veloce da verificare ragionevolmente i legittimi individuali login utente.
-
Puoi variare il numero di iterazioni in base ai tuoi scopi (velocità rispetto alla sicurezza).
-
Un utente malintenzionato dovrà sapere quale algoritmo utilizzare e conoscere anche il numero di iterazioni che hai scelto
-
L'id dell'algoritmo di autenticazione entra in gioco qui; se si aumenta il numero di iterazioni, si interrompono tutte le credenziali dell'utente esistenti a meno che non sia stato idificato l'algoritmo e si continui a supportare il vecchio algoritmo (ad esempio, PBKDF2 con 1.000 iterazioni) per le password esistenti mentre si richiede il nuovo algoritmo (ad esempio, PBKDF2 con 10.000 iterazioni) per password nuove e aggiornate
Se il carico di elaborazione diventa eccessivo per il tuo server (presumibilmente un server web), puoi scaricare l'autenticazione su un server separato.
Un sacco di ragazzi fantastici stanno facendo PBKDF2, sebbene bcrypt presumibilmente renda più difficile per un attacco basato su GPU confrontare rapidamente molte password. Scrypt potrebbe essere un miglioramento rispetto a bcrypt. Non sto facendo giudizi di valore qui. Fai le tue ricerche su questi. PBKDF2 potrebbe essere compatibile con FIPS, ad esempio, mentre bcrypt e scrypt non lo sono, ma la conformità FIPS potrebbe non essere un requisito per te.