[ CONSULTA ] Contraseña de usuario

[volldammBilbo]

Hola a tod@s,

estoy realizando mi primera aplicación en Android y tengo un problema con el tema 'Usuario y contraseña'.

La aplicación tiene parte de servidor, que es el que se encarga de persistir en una bd MySQL. Mi pregunta es, ¿como gestiono el tema contraseña? traducido a varias preguntas:

1. Es correcto guardar una contraseña (encriptada de alguna forma obviamente) en la BD?
2. Como guardo la contraseña en el teléfono para que no tenga que logearse cada vez el usuario?

Gracias a tod@s!

[kriogeN]

Lo habitual es usar un sistema de Access token, es decir, haces un sistema que al logearte te de una cadena de caracteres que identifique al usuario, y que sea válida durante un tiempo (por ejemplo 1 semana o 1 mes), esto se llama Token de Sesión.

Además del Token de Sesión también le envías al usuario un Refresh Token (o Token de Renovación), que se usa para renovar el Token de Sesión cuando este ha caducado.

Por ejemplo, te logeas, y al usuario le envías:

AccessToken = "aaaa"
RefreshToken = "bbbb"

A partir de ese momento para todo el tráfico con el servidor usas el AccessToken en vez del usuario y contraseña, ya que ese AccessToken identifica un login válido.

Cuando el AccessToken caduca vuelves a relogearte, pero en vez de usando el usuario y contraseña usando el AccessToken y el RefreshToken y al usuario le envías:

AccessToken = "cccc"
RefreshToken = "dddd"

Haciendo esto lo único que tienes que tener almacenado en tu app en todo momento es el AccessToken y el RefreshToken.

[mocelet]

Respecto al 2, busca y encontrarás: http://www.htcmania.com/showthread.php?t=952584 (EDITO: es lo que comentaba kriogeN )

Respecto a almacenar la contraseña en el servidor, no es la práctica habitual, y de hecho es pecado guardarla en claro aunque muchos lo hagan. Tampoco se almacena cifrada, lo que se almacena es un "hash" de la contraseña. Un hash es una función que a la misma entrada devuelve siempre la misma salida, pero conociendo la salida es imposible averiguar la entrada salvo probando distintas entradas (fuerza bruta, diccionarios, etc.) a ver si coincide la salida. Ejemplos, MD5 o SHA-1

Así, envías las credenciales al servidor (sea la contraseña, o el token, o lo que sea que pruebe que es el usuario), el servidor hace el hash y comprueba si en la base de datos es lo mismo. Si te atacan la base de datos, las credenciales no quedan expuestas como si estuvieran guardadas en texto plano o cifradas -si consiguieran a clave de cifrado podrían acceder a todas las contraseñas-

P.D: Poniéndose en modo paranoico (esto ya por si le interesa a alguien ), si quieres minimizar un posible ataque de robo de credenciales supuesto que accedan a la base de datos, lo ideal es hacer más difícil el uso de métodos de fuerza bruta. En ese caso, se hace un hash pero no solo de la contraseña sino de una clave secreta (del servidor), la contraseña del usuario y una ristra aleatoria de bytes (que se llama "salt" y que está asociada a ese usuario para evitar que los ataques sobre un usuario puedan valer para los demás). Y a todo eso le vuelves a aplicar la función de hash varias veces (iteraciones). Los frameworks de aplicaciones que incluyen componentes de seguridad hacen eso.

[volldammBilbo]

Gracias por vuestras respuestas.

Algo había leído sobre lo que comentáis, tanto sobre los tokens como sobre lo de MD5 o SHA1 (a esto me refería con lo de cifrada).

A ver si me ha quedado claro. Guardar el hash en MySQL también es pecado o no tanto?

Entiendo que lo ideal es lo de los tokens pero lo veo más complicado para una primera aproximación (también es un poco de pereza, vamos a reconocerlo), lo pongo como futura mejora

Un saludo

[mocelet]

Guardar el hash en la base de datos es lo correcto. Guardarla en claro o cifrada no.

Edit: La pereza en temas de seguridad hay que guardarla. No por tu app, que al fin y al cabo puedes no tener nada comprometedor, pero ya sabemos que mucha gente usa la misma contraseña para todo. Si le pides email y contraseña y luego la mandas en claro o la almacenas... igual le haces la pascua al usuario si alguien intercepta el tráfico de tu app o accede a la base de datos.