Tengo una aplicación cliente que se conecta a un servidor a través de un socket seguro/SSL. El usuario debe iniciar sesión cuando se inicia la aplicación. En este momento, tengo el requisito de que debo enviar la contraseña real al servidor (encriptada a través de SSL), en lugar del método preferido para enviar un hash de la contraseña. Dicho esto, ¿cómo hago para almacenar de forma segura la contraseña en la memoria del cliente de modo que pueda volver a utilizar esta contraseña si el cliente necesita volver a conectarse al servidor detrás de las escenas debido a una conexión perdida?¿Cómo almacenar la contraseña del servidor en el cliente de Java para reconectarse más tarde?
Puedo cifrar fácilmente la contraseña, o incluso ponerla en KeyStore y recuperarla más tarde para la reconexión, sin embargo, incluso si hago esto, me parece que un hacker podría recuperar la contraseña si tuviera acceso al aplicación en un depurador. ¿Es esto solo un hecho de la vida cuando uno necesita almacenar la contraseña en el cliente por un tiempo temporal?
¿Hay una manera mejor/preferida de lograr lo mismo (es decir, permitir que el cliente se vuelva a conectar al servidor sin que el usuario tenga que ingresar su contraseña nuevamente después del inicio de sesión inicial)? ¿Sería mejor enviar un token de inicio de sesión que expira desde el servidor (donde puedo pasar este token de expiración al servidor en lugar de una contraseña al reconectarlo)?
Finalmente, en general, ¿qué tan fácil es para alguien conectar un depurador a una aplicación en ejecución en el escritorio de Java o Android, cuando la Aplicación está "despojada" correctamente de los símbolos de depuración? ¿Debo preocuparme por este caso, o Java protegerá mi aplicación de envío de tener un depurador u otro analizador de memoria conectado a él?
No entiendo por qué un token sería más vulnerable a un ataque de fuerza bruta que el hacker que intenta atacar con fuerza bruta la contraseña? –
Porque, en general, los tokens están más estructurados que las contraseñas. También; los tokens se envían tal como están (como debe asignarse a la sesión en el lado del servidor), mientras que las contraseñas se pueden codificar (las mismas contraseñas se correlacionan con los mismos datos "desconocidos", menos predecibles). Otro riesgo está en el esfuerzo de desarrollo; uno debe crear una sesión y una capa de autenticación de token, mientras que usar la técnica de contraseña relativamente "simple" requiere menos esfuerzo. Digamos que un programador presenta un error cada 5 minutos. Menos tiempo para implementar significa menos errores. – Pindatjuh