Android: memorizzazione di nome utente e password?


178

Se voglio memorizzare il nome utente e la password da utilizzare all'interno di un'applicazione Android, qual è il modo migliore per farlo? È attraverso la schermata delle preferenze (ma cosa succede se l'utente manca questo?), O pop-up una finestra di dialogo e chiedere all'utente le credenziali? In tal caso, devo mantenere lo stato per l'applicazione. Come lo farei?


4
stackoverflow.com/a/786588/1166727 Scopri cosa @RetoMeier (Tech piombo per lo sviluppo Android di Google) ha da dire su questo.
tony gil,

1
Se siete alla ricerca di modo più sicuro per memorizzare il credentials.Read questa risposta stackoverflow.com/a/20560574/730807
Durai Amuthan.H

3
@Legend come hai risolto il tuo problema?
Erum,

@Legend, puoi fare un po 'di luce sul salvataggio di pwd in prefs dopo la crittografia .. perché voglio che la mia app funzioni senza Internet quindi come ottengo la chiave .. (perché non riesco a memorizzare la chiave sul dispositivo)
eRaisedToX

È possibile utilizzare il keystore per Api +18. developer.android.com/training/articles/keystore
Golnar

Risposte:


115

La maggior parte delle app per Android e iPhone che ho visto utilizzano una schermata iniziale o una finestra di dialogo per richiedere le credenziali. Penso che sia ingombrante per l'utente dover reinserire spesso il proprio nome / password, quindi la memorizzazione di tali informazioni ha senso dal punto di vista dell'usabilità.

Il consiglio della ( guida per gli sviluppatori Android ) è:

In generale, raccomandiamo di ridurre al minimo la frequenza di richiesta delle credenziali dell'utente - per rendere gli attacchi di phishing più evidenti e meno probabili avere successo. Utilizzare invece un token di autorizzazione e aggiornarlo.

Laddove possibile, nome utente e password non devono essere memorizzati sul dispositivo. Invece, eseguire l'autenticazione iniziale utilizzando il nome utente e la password forniti dall'utente, quindi utilizzare un token di autorizzazione di breve durata specifico per il servizio.

L'uso di AccountManger è l'opzione migliore per l'archiviazione delle credenziali. Il SampleSyncAdapter fornisce un esempio di come usarlo.

Se questa non è un'opzione per te per qualche motivo, puoi ricorrere alle credenziali persistenti utilizzando il meccanismo Preferenze . Altre applicazioni non saranno in grado di accedere alle tue preferenze, quindi le informazioni dell'utente non sono facilmente esposte.


40
Direi che è rischioso conservare le informazioni sulla password come nelle preferenze. Sui telefoni con root è possibile accedere al file delle preferenze di un'app. Il minimo che puoi fare è offuscare la password.
Jayesh,

51
Se qualcuno ha il tuo telefono ed è in grado di eseguirne il root, non c'è molto che tu possa fare per proteggere i tuoi dati. Non è una cattiva idea offuscare la password, ma non sta aggiungendo molta più protezione. Ciò che è più importante è che ci sono molti livelli di sicurezza già integrati nel sistema operativo. Certo, non vuoi fare nulla di stupido per aggirare quelle misure. Probabilmente è meglio usare un sistema come OAuth e archiviare un token sul dispositivo anziché nome utente e password.
Eric Levine,

4
Se usi il AccountManager(come da mia risposta, e @ Miguel's in modo circolare) e qualcuno ottiene una sospensione del tuo telefono GSM, dovranno continuare a utilizzare la tua SIM per avere accesso ai tuoi account, poiché invalideranno le credenziali archiviate quando la SIM cambia.
Jon O

3
La cancellazione dell'account sulla modifica SIP è stata rimossa un po 'di tempo fa, perché ha poco senso, soprattutto per le persone che hanno più di una SIM. Una strategia migliore se il tuo telefono viene rubato è quella di andare alla pagina del tuo account Google e revocare l'accesso per quel particolare dispositivo.
Nikolay Elenkov

2
"L'uso di AccountManger è l'opzione migliore per la memorizzazione delle credenziali." Perché?
Luc

9

È necessario utilizzare AccountManager Android . È appositamente progettato per questo scenario. È un po 'ingombrante ma una delle cose che fa è invalidare le credenziali locali se la scheda SIM cambia, quindi se qualcuno fa scorrere il telefono e lancia una nuova SIM al suo interno, le tue credenziali non saranno compromesse.

Ciò offre inoltre all'utente un modo rapido e semplice per accedere (e potenzialmente eliminare) le credenziali archiviate per qualsiasi account che hanno sul dispositivo, il tutto da un'unica posizione.

SampleSyncAdapter (come menzionato @Miguel) è un esempio che utilizza le credenziali dell'account memorizzato.


3
Dove è documentato che AccountManager "invaliderà le credenziali locali se la carta SIM cambia"?
Eric Levine,

Non è che ne sia consapevole. Tuttavia, è qualcosa che ho imparato a credere / accettare / comprendere dopo che alcuni utenti della mia app hanno avuto problemi di autenticazione a seguito di scambi di SIM.
Jon O

1
Non lo vedo nel codice JavaDocs o AccountManager. Sembra una buona funzionalità, sarebbe bello verificarlo e comprenderne i dettagli.
Eric Levine,

2
Secondo @NikolayElenkov la funzione di modifica della scheda SIM non valida è stata rimossa.
ThomasW,

2
@ThomasW hai una citazione per questo? Sarebbe bello avere una risposta definitiva di qualche tipo.
Jon O

8

Penso che il modo migliore per proteggere le tue credenziali sia innanzitutto pensare di memorizzare la password con la crittografia nel file account.db che non potrebbe essere facilmente disponibile in dispositivi non rootati e in caso di dispositivo rootato l'hacker deve aver bisogno della chiave per decrittografare esso.

Un'altra opzione è fare tutta la tua autenticazione come il modo in cui Gmail sta facendo. dopo la prima autenticazione con il server Gmail. hai il token di autenticazione che verrebbe utilizzato in caso di password. quel token verrebbe archiviato in testo normale. questo token potrebbe essere falso nel caso in cui si cambi la password dal server.

l'ultima opzione che ti consiglio di abilitare l'autenticazione a due fattori e creare una password specifica per il dispositivo. Dopo aver perso il dispositivo, tutto ciò che serve è disabilitare quel dispositivo.


2
Puoi pubblicare una fonte che dice che account.db è crittografato? O dici che la password specifica dovrebbe essere crittografata?
Michał K,

1
@Riz, dove archiviare la chiave per la crittografia, quindi ... perché la mia app funziona senza Internet, quindi non posso ottenerla dalla rete
eRaisedToX




2

Con il nuovo hardware e API (Android 6.0) per le impronte digitali puoi farlo come in questa applicazione di esempio github.


8
Il progetto di esempio di riferimento crea una chiave nel Key Store Android e lo utilizza per creare un codice per crittografare la password. La password e la crittografia crittografate vengono archiviate come stringhe codificate base64 nelle preferenze condivise. Dopo aver eseguito correttamente l'autenticazione tramite impronta digitale, la chiave segreta viene recuperata da Android Key Store e utilizzata con il codice decodificato per decrittografare la password decodificata.
mjwheat,

@mjwheat questo è così utile per capire cosa sta succedendo nell'esempio. Grazie! Un piccolo errore di battitura: "... per decrittografare la password codificata."
muetzenflo,

2

Questi sono classificati in ordine di difficoltà a violare le informazioni nascoste .

  1. Conservare in chiaro

  2. Conservare crittografato utilizzando una chiave simmetrica

  3. Utilizzo del keystore Android

  4. Conservare crittografato utilizzando chiavi asimmetriche

fonte: dov'è il posto migliore per archiviare una password nella tua app Android

Il Keystore stesso viene crittografato utilizzando il pin / password del lockscreen dell'utente, quindi, quando lo schermo del dispositivo è bloccato, il Keystore non è disponibile. Tienilo a mente se hai un servizio in background che potrebbe aver bisogno di accedere ai tuoi segreti dell'applicazione.

fonte: utilizzare semplicemente il Keystore Android per archiviare password e altre informazioni sensibili


Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.