24

Estoy desarrollando una aplicación donde el usuario necesita iniciar sesión para realizar operaciones ... pero principalmente en teléfonos celulares Android use "mantenerme conectado" ... y en este caso Tendré que mantener el valor del nombre de usuario y la contraseña dentro de mi aplicación. ¿Debo usar las preferencias o SQLite Db o hay algo más y cómo puedo hacerlo seguro? Plz Ayuda ... Gracias de antemano ..La mejor opción para almacenar nombre de usuario y contraseña en la aplicación de Android

+0

esto funciona correctamente: http://stackoverflow.com/a/19629701/5733853 – HPbyP

Respuesta

4

Por lo menos, almacenarlo en SharedPreferences (modo privado) y no se olvide de hash de la contraseña. Aunque esto no marcará realmente la diferencia con un usuario malintencionado (o dispositivo rooteado), es algo.

+0

Cualquier tutorial de cómo favor de hash de una contraseña? Estoy interesado en esa idea. ¿Y nadie puede recuperar la contraseña almacenada con esa técnica? – androniennn

+1

@androniennn Hay un _ton_ de tutoriales sobre cómo hash contraseñas, así que te dejaré Google. Una cosa a tener en cuenta es que el hashing solo tiene la intención de frustrar al _casual_ snooper. Esta técnica ** no tiene ningún efecto ** cuando el dispositivo está rooteado (por ejemplo) y el usuario malintencionado también tiene acceso a su binario. Piénselo, si alguien puede aplicar ingeniería inversa a su programa, entonces podrá averiguar fácilmente cómo ha procesado la contraseña. Solo necesita conocer las posibilidades :) –

+0

Un buen método/técnica pero no 100% seguro y seguro: \ – androniennn

25

Sí, esto es complicado en Android. No desea almacenar la contraseña de texto claro en las preferencias, ya que cualquier persona con un dispositivo rooteado básicamente mostrará su contraseña al mundo. Por otro lado, no puede usar una contraseña encriptada, ya que tendría que almacenar su clave de cifrado/descifrado en algún lugar del dispositivo, nuevamente susceptible al ataque raíz.

Una solución que utilicé hace un tiempo es hacer que el servidor genere un "ticket" que devuelve al dispositivo, lo que es bueno para un cierto período de tiempo. Este boleto es usado por el dispositivo para todas las comunicaciones, usando SSL por supuesto para que la gente no pueda robar su boleto. De esta forma, el usuario autentica su contraseña en el servidor una vez, el servidor devuelve un ticket vencido y la contraseña nunca se almacena en ningún lugar del dispositivo.

Varios mecanismos de autenticación de tres patas, como OpenID, Facebook, incluso Google API, utilizan este mecanismo. Las desventajas son que de vez en cuando, cuando el ticket caduca, el usuario necesita volver a iniciar sesión.

En última instancia, depende de cuán segura quiere que sea su aplicación. Si esto es simplemente para distinguir a los usuarios, y no se almacena información supersecreta como cuentas bancarias o tipos de sangre, entonces guardar el pwd en texto sin formato en el dispositivo está bien :)

Buena suerte, cualquiera que sea el método que decida ¡es lo mejor para su situación particular!

Editar: Debo señalar que esta técnica transfiere la responsabilidad de la seguridad al servidor; querrá utilizar hashes salados para la comparación de contraseñas en el servidor, una idea que verá en algunos de los otros comentarios para este pregunta. Esto evita que la contraseña de texto claro aparezca en cualquier lugar, excepto la vista Editar texto en el dispositivo, la comunicación SSL al servidor y la memoria RAM del servidor a la vez que elimina y contrae la contraseña. Nunca se almacena en el disco, que es una buena cosa (tm).

+3

Estoy de acuerdo en todo lo que dijo técnicamente hablando. Pero creo que cuanto más público es su tipo de sangre, más probabilidades hay de que se guarde en caso de emergencia;) –

+2

No importa si los datos no son supersecretos, los usuarios pueden usar el mismo usuario/contraseña en muchos lugares. y un atacante puede obtenerlos e intentar con diferentes servicios. –

22

Como han dicho otros, no existe una forma segura de almacenar una contraseña en Android que proteja los datos completamente. Hashing/encriptación de la contraseña es una gran idea, pero lo único que hará es ralentizar la "cracker".

Dicho esto, esto es lo que hice:

1) He utilizado este simplecryto.java class que tiene una semilla y un texto y lo cifra. 2) Usé SharedPreferences en modo privado que protege el archivo guardado en dispositivos no rooteados. 3) La semilla que utilicé para simplecryto es una matriz de bytes que es un poco más difícil de encontrar por descompiladores que una cadena.

Mi aplicación fue revisada recientemente por un grupo de seguridad "sombrero blanco" contratado por mi empresa. Marcaron este problema e indicaron que debería usar OAUTH, pero también lo mencionaron como un riesgo bajo, lo que significa que no es bueno, pero no lo suficientemente grave como para evitar su lanzamiento.

Recuerda que el "cracker" necesitaría tener acceso físico al dispositivo Y ARRIBA Y CUIDE lo suficiente para encontrar la semilla.

Si realmente le importa la seguridad, no tiene una opción "mantenerme conectado".

+0

El enlace del tutorial está roto, así que no estoy seguro de si es el mismo, pero un Google inmediatamente me mostró un artículo que parecía bastante similar: http://www.androidsnippets.com/encryptdecrypt-strings, pero ocurre para mí que podría usar una semilla generada al azar que se almacena fuera del dispositivo para mayor seguridad. Este secreto/semilla compartida se generaría aleatoriamente por usuario y el almacenamiento fuera del dispositivo contendría la asignación. Siempre que intercambie información de forma segura con esa ubicación de forma segura, y que el almacenamiento sea seguro, ¿no funcionaría mejor? – batbrat

+1

@batbrat Si va a tener un estado de usuario persistente del lado del servidor, recomiende oauth2 en lugar de algo de cosecha propia. En mi ejemplo, no hay estado de usuario y, por lo tanto, no tenía nada disponible para llamar en contra. – knaak

+0

Gracias por aclarar. Ahora entiendo mejor, y estoy de acuerdo. – batbrat

1

La forma más segura de hacer esto sin poner en peligro la seguridad es el uso de las preferencias compartidas para almacenar sólo el nombre de usuario de la última persona que iniciar sesión en.

Asimismo, en la tabla de usuarios, la introducción de una columna que sostiene numérica boolean (1 o 0) para representar si la persona que marcó la persona marcó la casilla "recordarme" o no.

Al iniciar su aplicación, obtenga el nombre de usuario usando la función getSharedPreferences() y utilícela para consultar su base de datos alojada para ver si la columna signedin es 1 o 0, donde 1 indica que la persona marcó la casilla "recordarme".

1
//encode password 
pass_word_et = (EditText) v.findViewById(R.id.password_et); 
String pwd = pass_word_et.getText().toString(); 
       byte[] data = new byte[0]; 
       try { 
        data = pwd.getBytes("UTF-8"); 
       } catch (UnsupportedEncodingException e) { 
        e.printStackTrace(); 
       } 
       String base64 = Base64.encodeToString(data, Base64.DEFAULT); 
       hbha_pref_helper.saveStringValue("pass_word", base64); 

//decode password 
String base64=hbha_pref_helper.getStringValue("pass_word"); 
      byte[] data = Base64.decode(base64, Base64.DEFAULT); 
      String decrypt_pwd=""; 
      try { 
       decrypt_pwd = new String(data, "UTF-8"); 
      } catch (UnsupportedEncodingException e) { 
       e.printStackTrace(); 
      } 
+1

¡Bienvenido a StackOverflow! ¿También puede proporcionar una explicación para ayudar al PO a entender su respuesta? – FrankS101

+6

Base64 no es encriptación, es un algoritmo de codificación, que es muy fácil de reconocer y decodificar. –

0

Usando NDK para el cifrado y el descifrado junto con la definición de la variable Cadena de clave no en lugar de guardarlo en las preferencias compartidas o definirla ins la cadena XML ayudaría a prevenir el robo de clave secreta contra la mayoría de los niños de la escritura. El texto de cifrado resultante se almacenaría en las preferencias compartidas. This link may help about the sample code

Cuestiones relacionadas