¿Cómo se almacena la contraseña de Gmail en Android y dónde?

@J.F.Sebastian Estoy de acuerdo, pero a nadie le gustaría introducir una contraseña cada vez que el cliente de correo electrónico necesita autenticarse. Y, AFAIK, no hay ninguna aplicación de correo electrónico que soporte esto. Además, el usuario pregunta cómo se almacena la contraseña localmente, por lo que podría suponer que está hablando de la forma más común, es decir, dar la contraseña a la aplicación de correo electrónico para almacenarla.

@J.F.Sebastian: es fácil equivocarse fatalmente con la seguridad, y tú acabas de mostrar una forma de hacerla mal. Añadir dongles no hace que tu dispositivo sea más seguro por arte de magia; piénsalo bien, una vez que desbloqueas tu dispositivo con tu dongle, la clave de descifrado debe permanecer disponible hasta que la sesión expire para que pueda reautenticarse sin el dongle cada vez. La posesión de su dispositivo durante unos diez minutos es suficiente para que un atacante capaz y bien preparado copie la clave de descifrado y el almacén de contraseñas para obtener su contraseña como texto plano sin tocar nunca su dongle.

@SachinShekhar: No quiero decir que se use lastpass literalmente . Es sólo un ejemplo que muestra que la contraseña puede ser encriptado en el lado del cliente si se utiliza una solución basada en la nube (es decir, no es necesario confiar en el tercero con la contraseña de texto plano). 2. La forma más común de almacenar las contraseñas localmente es utilizar servicios de llavero con kSecAttrAccessibleWhenUnlocked o kSecAttrAccessibleAfterFirstUnlock (es para iOS pero debe haber algo similar en las versiones recientes de Android).

@J.F.Sebastian: en conclusión, la única forma de autenticación realmente segura es hacer lo que Google hizo con la aplicación de Gmail, es decir, utilizar un esquema de autenticación no estándar con un token de autenticación. Incluso si alguien se las arregló para robar tu token de autenticidad, puedes invalidar remotamente el token, y no necesitas cambiar tu contraseña porque el texto plano de la contraseña nunca se vio comprometido. La otra forma segura es usar el dongle sin sesiones; bueno, ya sabes lo que pasa cuando haces eso, tus usuarios simplemente dejarán el dongle conectado permanentemente.

@LieRyan: no hay ninguna defensa que pueda proteger de todos los ataques, por ejemplo, Llave de $5 . Pero hay son muchas soluciones que mucho mejor que el almacenamiento de contraseñas en texto plano, preservando la usabilidad.

@J.F.Sebastian: Creo que no has entendido nada. Cifrar la contraseña no es más seguro que almacenarla en texto plano, ni siquiera por un bit. Cualquier atacante que consiga copiar el accounts.db puede también copiar la clave de descifrado junto con él; lo único que te da el cifrado es una falsa sensación de seguridad que es peor que no tener seguridad. Sí, hay soluciones que son mucho mejores que almacenar la contraseña en texto plano, pero todas ellas requieren cambios en el protocolo de correo electrónico, así que tenemos que vivir con lo que tenemos actualmente. O hacerlo correctamente de una manera no estándar como hizo Gmail.

@LieRyan: lee atentamente mis comentarios. No es la seguridad a través de la oscuridad. No es una teoría. Y definitivamente no son mis inventos. Hay soluciones ya implementadas en dispositivos populares que no requieren cambiar los protocolos de correo electrónico (la aplicación de correo electrónico tiene acceso a la contraseña de texto plano) mientras que hacen imposible (muy difícil) acceder a las contraseñas si el dispositivo está apagado/bloqueado dependiendo de una solución particular, por ejemplo, ver docs para kSecAttrAccessible* He puesto un enlace más arriba.

@J.F.Sebastian Los servicios de llavero de iOS no son nada seguros. Ver sit.sit.fraunhofer.de/studies/en/sc-iphone-passwords-faq.pdf y, no soy capaz de encontrar ninguna implementación similar para Android.

@LieRyan Sí, Falsa sensación de seguridad no es bueno. En la situación actual, al menos cambiaríamos rápidamente nuestras contraseñas después de perder el dispositivo.

@SachinShekhar: ¿Has leído la sección "Qué dispositivos están en peligro"? Se requiere que los dispositivos recientes estén desbloqueados para que sean vulnerables (no es "no son seguros en absoluto". Si el precio de los exploits dice algo, entonces iOS tiene buena pinta ). Por lo demás, estoy de acuerdo en que todo el software no trivial tiene fallos, algunos de los cuales son explotables. Las contraseñas son útiles incluso si todos los sistemas pueden ser comprometidos en teoría. La practicidad debería vencer al miedo a la "falsa sensación de seguridad".

@J.F.Sebastian El servicio de llavero de Apple o el que proporciona el kernel de Linux no es una opción más segura. La contraseña sigue rondando por la memoria y si el llavero está desbloqueado incluso sin cifrar. Así que es probable que sólo sea un poco más difícil de obtener como el archivo .db legible por el usuario. Google implementó la mejor solución posible utilizando un token de autentificación que puede ser invalidado en caso de que el dispositivo se vea comprometido. La siguiente opción más segura sería introducir la contraseña cada vez o simplemente evitar el uso del correo electrónico en absoluto.

Creo que la discusión está divagando un poco. Así que para resumir, puedo decir ahora que, Android no almacena las contraseñas en accounts.db, pero en su lugar utiliza una clave de autenticación que ayuda en el acceso a mi cuenta. Esta clave de autenticación, en los teléfonos de stock no rooteados son inaccesibles debido al hecho de que la DB es de sólo lectura por root, lo que hace que sea seguro. ¿Es correcto este resumen?

@J.F.Sebastian: Creo que has juzgado muy mal la gravedad del artículo de Fraunhofer, no se trata de un error que se solucionará con el tiempo, el artículo demuestra el fallo fundamental del enfoque. De hecho, el artículo no demuestra nada nuevo, y estoy seguro de que Apple era plenamente consciente de los problemas de su llavero incluso antes de implementarlo. Creo que el artículo está más dirigido a los desprevenidos ingenieros de software y a los usuarios finales que tienen una falsa sensación de seguridad debido a la existencia de un llavero en todo el sistema.

@asudhak Este resumen es correcto sólo para la aplicación oficial de Gmail (o digamos, los servicios generales de Google). Otras aplicaciones de correo electrónico almacenan las contraseñas (no los tokens de autentificación) en texto plano.

@asudhak: casi, pero no del todo. No es que Android almacene la contraseña como clave de autentificación, es que la aplicación de Gmail (y otras Gapps) almacena la clave de autentificación para autentificarse en los servidores de Google. Otras aplicaciones de Android varían en la forma en que almacenan los detalles de autenticación, por ejemplo, la aplicación de correo electrónico stock almacena la contraseña como texto plano, otras aplicaciones pueden tal vez añadir un poco de ofuscación, mientras que otras aplicaciones utilizarían auth token similar a Gapps. En un dispositivo no rooteado, la base de datos de la cuenta que almacena todo esto sólo es legible por el sistema, por lo que es seguro en el sentido de que una aplicación no puede robar la contraseña de otra aplicación, incluso si se almacenan en texto plano.

@asudhak: sin embargo, el esquema no protege contra atacantes con acceso físico al dispositivo, y añadir cifrado tampoco ayudaría debido a los problemas mencionados anteriormente. Para protegerse de estas amenazas, sería necesario un cifrado completo del disco y la posibilidad de realizar un borrado remoto.

@LieRyan A partir de ICS, la aplicación de correo electrónico de serie utiliza la api de KeyStore, no de texto plano. Android-developers.blogspot.com/2012/03/

@SachinShekhar: ¿Puedes aclarar dónde se almacena el Auth Token en el dispositivo? ¿Está dentro de accounts.db?

@asudhak Los tokens de autentificación se almacenan en authtoken campo de authtokens mesa interior accounts.db base de datos.

Has escrito: "KeyChain no es seguro si el dispositivo está rooteado". ¿Por qué, por favor?

@Sopalajo Con el acceso Root, puedes jugar a ser Dios. Con acceso al almacenamiento interno, puedes extraer la contraseña simple como lo hace KeyChain (recuerda que KeyChain también necesita poner la contraseña simple a disposición de la aplicación) a menos que el dispositivo cuente con un cifrado especial por hardware. Incluso con la encriptación por hardware, el proceso de KeyChain en ejecución puede ser hackeado desde la RAM (la clave de encriptación siempre viene dentro de la RAM; comprueba también el ataque Cold Boot para hacerte una idea).

@SS-3.1415926535897932384626433 Pregunta rápida: ¿El token de autenticidad sigue siendo válido en un dispositivo diferente? Si no es así, ¿por qué?

¿es seguro eliminar accounts.db? ¿o se va a bloquear el dispositivo?

Los comentarios no son para ampliar la discusión; esta conversación ha sido trasladado al chat .