Android: ¿Almacenar nombre de usuario y contraseña?

178

Si quiero almacenar el nombre de usuario y la contraseña para usar dentro de una aplicación de Android, ¿cuál es la mejor manera de hacerlo? ¿Es a través de la pantalla de preferencias (pero, ¿qué sucede si el usuario se pierde esto?) O aparece un cuadro de diálogo y le pregunta al usuario las credenciales? Si es así, tengo que mantener el estado de la aplicación. ¿Cómo haría esto?

android  authentication  storage  credentials 
— Leyenda
fuente
44
stackoverflow.com/a/786588/1166727 Echa un vistazo a lo que @RetoMeier (Tech Lead for Android Development en Google) tiene para decir sobre esto.
— tony gil
1
Si está buscando la forma más segura de almacenar las credenciales
— Lea
3
@Leyenda, ¿cómo resolvió su problema?
— Erum
@Legend, ¿puedes arrojar algo de luz sobre cómo guardar pwd en prefs después del cifrado ... porque quiero que mi aplicación funcione sin internet, entonces cómo obtengo la clave ... (porque no puedo almacenar la clave en el dispositivo)
— eRaisedToX
Puede usar el almacén de claves para Api +18. developer.android.com/training/articles/keystore
— Golnar

Respuestas:

115

La mayoría de las aplicaciones de Android y iPhone que he visto usan una pantalla inicial o un cuadro de diálogo para solicitar credenciales. Creo que es engorroso para el usuario tener que volver a ingresar su nombre / contraseña a menudo, por lo que almacenar esa información tiene sentido desde una perspectiva de usabilidad.

El consejo de la ( guía de desarrollo de Android ) es:

En general, recomendamos minimizar la frecuencia de solicitud de credenciales de usuario, para que los ataques de phishing sean más visibles y menos propensos a tener éxito. En su lugar, use un token de autorización y actualícelo.

Siempre que sea posible, el nombre de usuario y la contraseña no deben almacenarse en el dispositivo. En su lugar, realice la autenticación inicial utilizando el nombre de usuario y la contraseña proporcionados por el usuario, y luego use un token de autorización específico de servicio de corta duración.

Usar el AccountManger es la mejor opción para almacenar credenciales. El SampleSyncAdapter proporciona un ejemplo de cómo usarlo.

Si esta no es una opción para usted por alguna razón, puede recurrir a las credenciales persistentes utilizando el mecanismo de Preferencias . Otras aplicaciones no podrán acceder a sus preferencias, por lo que la información del usuario no se expone fácilmente.

— Eric Levine
fuente
40
Diría que es arriesgado mantener la información de la contraseña como está en las preferencias. En teléfonos rooteados es posible acceder al archivo de preferencias de una aplicación. Lo menos que puede hacer es ofuscar la contraseña.
— Jayesh
51
Si alguien tiene su teléfono y puede rootearlo, no hay mucho que pueda hacer para mantener sus datos seguros. No es una mala idea ofuscar la contraseña, pero en realidad no agrega mucha más protección. Lo que es más importante es que ya hay muchas capas de seguridad integradas en el sistema operativo. Por supuesto, no quieres hacer nada estúpido para eludir esas medidas. Probablemente sea mejor usar un sistema como OAuth y almacenar un token en el dispositivo en lugar del nombre de usuario y contraseña.
— Eric Levine
44
Si usa el AccountManager(según mi respuesta, y @ Miguel's de forma indirecta) y alguien obtiene su teléfono GSM, deberá seguir usando su SIM para tener acceso a sus cuentas, ya que invalidará las credenciales almacenadas cuando cambia la SIM.
— Jon O
3
La eliminación de cuentas en el cambio SIP se eliminó hace bastante tiempo, porque tiene poco sentido, especialmente para las personas que tienen más de una SIM. Una mejor estrategia si le roban su teléfono es ir a la página de su cuenta de Google y revocar el acceso para el dispositivo en particular.
— Nikolay Elenkov
2
"Usar el AccountManger es la mejor opción para almacenar credenciales". ¿Por qué?
— Luc
9

Deberías usar el AccountManager de Android . Está especialmente diseñado para este escenario. Es un poco engorroso, pero una de las cosas que hace es invalidar las credenciales locales si la tarjeta SIM cambia, por lo que si alguien desliza su teléfono y arroja una nueva SIM, sus credenciales no se verán comprometidas.

Esto también le brinda al usuario una forma rápida y fácil de acceder (y potencialmente eliminar) las credenciales almacenadas para cualquier cuenta que tengan en el dispositivo, todo desde un solo lugar.

SampleSyncAdapter (como mencionó @Miguel) es un ejemplo que utiliza las credenciales de la cuenta almacenada.

— Jon O
fuente
3
¿Dónde está documentado que AccountManager "invalidará las credenciales locales si la tarjeta SIM cambia"?
— Eric Levine
No es que yo sepa. Sin embargo, es algo que he llegado a creer / aceptar / comprender después de que algunos usuarios de mi aplicación hayan tenido problemas de autenticación después de intercambios de SIM.
— Jon O
1
No lo veo en el código JavaDocs o AccountManager. Parece una buena característica, sería bueno verificarlo y comprender los detalles.
— Eric Levine
2
Según @NikolayElenkov, la función de invalidar el cambio de la tarjeta SIM se ha eliminado.
— ThomasW
2
@ThomasW ¿tienes una cita para eso? Sería genial obtener una respuesta definitiva de algún tipo.
— Jon O
8

Creo que la mejor manera de asegurar su credencial es pensar primero en almacenar la Contraseña con encriptación en el archivo account.db que no podría estar fácilmente disponible en dispositivos no rooteados y en el caso de un dispositivo rooteado, el hacker debe necesitar la clave para descifrar eso.

Otra opción es hacer toda su autenticación como lo está haciendo Gmail. después de la primera autenticación con el servidor de Gmail. obtuviste el token de autenticación que se usaría en caso de tu contraseña. ese token se almacenaría en texto sin formato. Este token podría ser falso en caso de que cambie la contraseña del servidor.

la última opción, le recomendaría que habilite la autenticación de 2 factores y cree una contraseña específica para su dispositivo. Después de perder el dispositivo, todo lo que necesita es desactivar ese dispositivo.

— Riz
fuente
2
¿Puedes publicar una fuente que diga que accounts.db está encriptada? ¿O dice que la contraseña específica debe estar encriptada?
— Michał K
1
@Riz, dónde almacenar la clave para el cifrado entonces ... porque mi aplicación funciona sin Internet, así que no puedo obtenerla de la red
— eRaisedToX
2

Con el nuevo hardware y API de huellas digitales (Android 6.0) puede hacerlo como en esta aplicación de muestra de github.

— Zlatko
fuente
8
El proyecto de muestra al que se hace referencia crea una clave en Android Key Store y la usa para crear un cifrado para cifrar la contraseña. La contraseña y el cifrado cifrados se almacenan como cadenas codificadas en base64 en las preferencias compartidas. Luego de una autenticación exitosa de la huella digital, la clave secreta se recupera de Android Key Store y se usa con el cifrado decodificado para descifrar la contraseña decodificada.
— mjwheat
@mjwheat esto es muy útil para entender lo que está sucediendo en el ejemplo. ¡Gracias! Un pequeño error tipográfico: "... para descifrar la contraseña codificada".
— muetzenflo
2

Estos se clasifican en orden de dificultad para romper su información oculta .

  1. Almacenar en texto sin cifrar

  2. Almacenar encriptado con una clave simétrica

  3. Usando el Android Keystore

  4. Almacenar encriptado usando claves asimétricas

fuente: ¿Dónde está el mejor lugar para almacenar una contraseña en su aplicación de Android?

El Keystore en sí está encriptado usando el pin / contraseña de la pantalla de bloqueo del usuario, por lo tanto, cuando la pantalla del dispositivo está bloqueada, el Keystore no está disponible. Tenga esto en cuenta si tiene un servicio en segundo plano que podría necesitar acceder a los secretos de su aplicación.

fuente: uso simple del almacén de claves de Android para almacenar contraseñas y otra información confidencial

— Dmytro Melnychuk
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.