Come viene memorizzata la password di Gmail in Android - e dove?


37

Mi sono guardato intorno e non ho trovato informazioni su come Android riesca a memorizzare le password sul dispositivo. Soprattutto le password di Gmail. Sto cercando di scoprire come Android crittografa e memorizza le password? Quale chiave utilizza e dove è memorizzata questa chiave e quale algoritmo di crittografia utilizza.


1
Perché la password memorizzata deve essere crittografata con una chiave? Ciò significherebbe solo che si deve inserire la chiave ogni volta che è richiesta la password, quindi semplicemente non è possibile memorizzare la password e inserirla ogni volta.
Flusso

Ehm, la chiave potrebbe essere specifica del dispositivo, ottenuta dal telefono IMEI o qualcosa del genere. Ciò significa che il software può ottenere la chiave senza che l'utente debba digitarla ogni volta.
Asudhak,

1
Cosa impedisce a qualsiasi altro software in esecuzione sul telefono di ottenere la chiave? Questo approccio non aggiunge ulteriore livello di sicurezza
Flow

Risposte:


36

L'app ufficiale di Gmail non memorizza la password nel tuo dispositivo. La tua password è sicura al 100% se usi questa app.

Funziona così: la password viene utilizzata SOLO per la prima volta dai server di autenticazione di Google. Dopo la prima autenticazione corretta, Auth Tokenviene scaricato sul dispositivo che viene archiviato nel accounts.dbfile come testo normale. Per tutti gli accessi successivi, Auth Tokenviene utilizzato, NON la password originale.
Quindi, se il tuo dispositivo viene rubato, tutto ciò che chiunque può ottenere è Auth Tokenche diventa non valido una volta cambiata la password. Quindi, sarai al comando assoluto.
Per la massima sicurezza, ti consiglio di abilitare 2-Factor Authenticatione creare Device Specific Passwordper il tuo dispositivo. Dopo aver perso il dispositivo, tutto ciò che serve è disabilitare quel dispositivo. Non è nemmeno necessario modificare la password principale.

Nota: questi non sono tutti veri se usi app di posta elettronica di terze parti per Gmail Viz. App di posta elettronica, posta K-9 ecc. Il protocollo IMAP o POP richiede una password originale per autenticare gli utenti ogni volta. Pertanto, la password semplice deve essere disponibile per l'app di posta elettronica prima di inviarla al server. Pertanto, la maggior parte delle app di posta elettronica memorizza le password in testo semplice (l'hashing / la crittografia è inutile perché la chiave di hashing / crittografia deve essere archiviata localmente). In questo caso, ti consiglio di abilitare 2-Factor Authenticatione creare Device Specific Passwordper il tuo dispositivo. Dopo aver perso il dispositivo, tutto ciò che serve è disabilitare quel dispositivo.

Aggiornamento:
tecnicamente, è possibile archiviare le password localmente in forma crittografata / con hash senza mantenere la chiave di crittografia / chiave di hashing in testo semplice localmente. Grazie a @JFSebastian per averlo segnalato. Sfortunatamente, tale implementazione per Android non è ancora disponibile. A partire da ICS, Android fornisce l' API KeyChain tramite la quale un'app può archiviare una password localmente in forma sicura. Le app che utilizzano l'API KeyChain sono rare, ma l'app di posta elettronica di riserva lo utilizza (grazie a @wawa per queste informazioni). Quindi, la tua password sarà al sicuro con l'app di posta elettronica di riserva finché lo schermo è bloccato. Ricorda, KeyChain non è sicuro se il dispositivo è rootato e non è disponibile su dispositivi pre-ICS.


6
@JF Sebastian: anche supponendo che ti fidi completamente della terza parte che memorizza le tue password, quelle erano solo leggermente più sicure della semplice memorizzazione della password nel dispositivo stesso. Il dispositivo deve ancora essere in grado di recuperare il testo in chiaro della password dall'archiviazione cloud e il dispositivo deve ancora memorizzare la password localmente perché non si desidera ricollegare il dongle ogni volta che si entra in un tunnel o aree con ricezione debole. La cosa peggiore da fare in termini di sicurezza è fornire un falso senso di sicurezza.
Lie Ryan,

4
@JFSebastian: in conclusione, l'unico modo veramente sicuro per l'autenticazione è fare ciò che Google ha fatto con l'app Gmail, ovvero utilizzare uno schema di autenticazione non standard con token di autenticazione. Anche se qualcuno è riuscito a rubare il token di autenticazione, è possibile invalidare il token in remoto e non è necessario modificare la password perché il testo in chiaro della password non è mai stato compromesso. L'altro modo sicuro è usare il dongle senza sessioni; bene, sai cosa succede quando lo fai, i tuoi utenti lasceranno il dongle permanentemente collegato.
Lie Ryan,

5
@JFSebastian: penso che ti stia perdendo il punto. La crittografia della password non è più sicura della semplice memorizzazione in testo semplice, nemmeno di un bit. Qualsiasi utente malintenzionato che riesce a copiare gli account.db può anche copiare la chiave di decrittazione insieme ad essa; l'unica cosa che ti dà la crittografia è un falso senso di sicurezza , che è peggio di nessuna sicurezza. Sì, ci sono soluzioni che sono molto meglio della memorizzazione di password in testo normale, ma tutte richiedono modifiche al protocollo e-mail, quindi dobbiamo vivere con ciò che abbiamo attualmente. O farlo correttamente in modo non standard come ha fatto Gmail.
Lie Ryan,

3
Il servizio portachiavi di @JFSebastian Apples o quello fornito dal kernel Linux non è un'opzione più sicura. La password rimane ancora in memoria e se il portachiavi è sbloccato anche non crittografato. Quindi è probabilmente solo leggermente più difficile ottenere come file .db solo leggibile come root. Google ha implementato la migliore soluzione possibile utilizzando un token di autenticazione che può essere invalidato in caso di compromissione del dispositivo. La prossima opzione più sicura sarebbe quella di inserire la password ogni volta o semplicemente evitare di usare la posta elettronica.
Flusso

4
@LieRyan A partire da ICS, l'app e-mail di serie utilizza l'API KeyStore non in chiaro. android-developers.blogspot.com/2012/03/…
Wesley Wiser,

12

Le password Android utilizzate con l'applicazione di posta elettronica integrata sono archiviate in testo normale all'interno di un database SQLite. Ciò è in contrasto con l' applicazione Gmail , che utilizza i token di autenticazione come descritto nella risposta di Sachin Sekhar .

Per Jelly Bean, l'ubicazione del database è:

/data/system/users/0/accounts.db

La posizione sopra varia in base alla versione di Android

Questa posizione su un dispositivo non rootato è protetta e protetta dal sistema operativo.
Sui dispositivi con root, gli utenti hanno già tecnicamente violato la propria sicurezza, e anche se non fosse in testo semplice sarebbe comunque banale decifrare poiché la chiave deve esistere da qualche parte sul dispositivo per farlo.

Un membro del team di sviluppo Android ha pubblicato una spiegazione che fino ad oggi si applica ancora:

Ora, rispetto a questa particolare preoccupazione. La prima cosa da chiarire è che l'app Email supporta quattro protocolli - POP3, IMAP, SMTP e Exchange ActiveSync - e con pochissime eccezioni molto limitate, tutti questi sono protocolli precedenti che richiedono che il client presenti la password al server su ogni connessione. Questi protocolli ci richiedono di conservare la password per tutto il tempo in cui desideri utilizzare l'account sul dispositivo. I protocolli più recenti non lo fanno - ecco perché alcuni articoli sono stati in contrasto con Gmail, ad esempio. I protocolli più recenti consentono al client di utilizzare una volta la password per generare un token, salvarlo e scartare la password.

Vi esorto a rivedere l'articolo collegato al commento # 38 , che è ben scritto e piuttosto informativo. Fornisce un ottimo background sulla differenza tra le password "oscuranti" e le rende veramente "sicure". Semplicemente oscurare la tua password (es. Base64) o crittografarla con una chiave memorizzata altrove non renderà la tua password o i tuoi dati più sicuri. Un attaccante sarà comunque in grado di recuperarlo.

(In particolare, sono state fatte alcune affermazioni su alcuni degli altri client di posta elettronica che non memorizzano la password in chiaro. Anche se ciò è vero, ciò non indica che la password sia più sicura. Un semplice test: se è possibile avviare il dispositivo e inizierà a ricevere e-mail sugli account configurati, quindi le password non sono veramente sicure. Sono offuscate o crittografate con un'altra chiave memorizzata altrove.)

Inoltre, poiché questo problema sembra disturbare molti utenti Android, puoi anche seguire questa discussione su Slashdot - Dati password Android memorizzati in testo semplice .


Wow. Questo mi stupisce. Non ero a conoscenza del fatto che è memorizzato in testo semplice. Dimentica il root o il non root. Se il tuo dispositivo viene rubato, una persona senza scrupoli potrebbe facilmente ottenere le tue credenziali anche se dovessi bloccare il telefono con una chiave di sicurezza. Dato questo fatto, sei anche a conoscenza di eventuali meccanismi di crittografia a livello di disco.
Asudhak,

1
Qualunque cosa siano, sono qualcosa che può essere utilizzato per ottenere l'accesso all'account. Ma, @SachinShekhar, il accounts.dbfile è protetto dalla lettura di account diversi da system.
Wyzard

1
Zuul, apprezzo il tuo impegno nei confronti delle risposte ma penso che questa risposta sia altamente fuorviante. Se ripeti il ​​preventivo che hai citato di nuovo, l'app Gmail non memorizza la password. --edit controlla anche @SachinShekhar rispondi.
Roxan,

2
@asudhak Se un'app utilizza una password originale, NON c'è modo di proteggerla. Un hacker può decodificare la stringa codificata da accounts.db dopo aver trovato la chiave di crittografia / hashing che deve essere memorizzata localmente perché l'app di posta elettronica avrebbe bisogno di questa chiave per compilare la password originale prima di inviarla al server.
Android Quesito,

2
@roxan Non sono riuscito a trovare nulla che punti alla password non memorizzata dall'app Gmail. Potete fornire un preventivo o un link?
Flusso
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.