¿Debo autenticar la contraseña de un usuario para cada solicitud de servidor?

Question

Me disculpo si esto puede ser de sentido común para algunos, pero todavía estoy aprendiendo. Tengo una aplicación para iOS que sincroniza archivos en un servidor web. Una vez que el usuario inicia sesión en el dispositivo, permanece conectado a menos que cierre la sesión. Actualmente, cada vez que el usuario inicia una solicitud del servidor, como agregar, actualizar o eliminar archivos, solo envío el correo electrónico del usuario y no la contraseña al servidor, ya que el usuario ya está autenticado en el dispositivo.

¿Debo enviar la contraseña almacenada del usuario cada vez que realiza una solicitud y que el servidor la autentique antes de continuar con la solicitud? ¿Por qué o por qué no?

Answer 1

Debe enviar un identificador de sesión, en lugar de una dirección de correo electrónico.

El identificador de sesión es un número grande (128 bits es suficiente) elegido por un generador de números aleatorios criptográficos cuando el usuario se autentica correctamente. Se establece como una "cookie" en el dispositivo web del usuario y se envía con cada solicitud a través de un canal seguro (TLS).

Las direcciones de correo electrónico son públicas. Solo puede autenticar solicitudes con secretos, como una contraseña o un identificador de sesión.

Answer 2

No soy un experto, pero hasta que se obtienen mejores respuestas aquí son algunos consejos:

• Cada solicitud debe incluir algún tipo de "identificador de sesión" para indicar que es parte de la sesión de inicio de sesión. Este identificador debe ser imposible/difícil de adivinar o reutilizar por un atacante. A menudo, las cookies HTTP se utilizan para esto, pero puede incluirlas en la URL.
• Nunca debe enviar contraseñas de texto sin cifrar a través de la red, ya que cualquier persona que las detecte las verá. En su lugar, debe enviar una especie de contraseña hash o usar un protocolo de desafío-respuesta.

Si usa HTTPS, es posible que no tenga que preocuparse por esto demasiado. Si se trata de tráfico no encriptado, es posible que desee "firmar" cada mensaje con un valor hash adicional.

Answer 3

El uso de una dirección de correo electrónico para identificar a un usuario significa que alguien posiblemente puede forzar el acceso a su servicio mediante el uso de una dirección de correo electrónico existente de los usuarios. Como sugiere Kristopher Johnson, el uso de un identificador de sesión evita exponer credenciales y es probablemente una buena opción de diseño.

Las buenas personas en OWASP tienen un session management cheat sheet que es un excelente punto de partida para cualquier diseño.

Recomiendan el uso de un marco existente para la gestión de sesiones (Java EE, ASP.NET, PHP) si hay alguno disponible.

Answer 4

Si va a utilizar SSL, entonces, enviar el nombre de usuario y la contraseña con cada solicitud es lo mejor. ¿Por qué? Porque es una interfaz de programación más simple y porque los tokens no agregan ningún valor real. En algún momento para obtener el token, deberías enviar las credenciales, entonces, ¿qué importa si envías las credenciales siempre o no? Nadie puede descifrar SSL de una manera digna de tiempo. Ahora podría haber otras lagunas de seguridad como en el servidor web en sí, pero eso no tiene nada que ver con el transporte de cliente a servidor (que está protegido). Por lo tanto, el usuario/pase con cada solicitud es el mejor.

Y debido a que su una aplicación para iOS, puede almacenar las credenciales en NSUserDefaults (que es un recinto de seguridad para su aplicación en particular y no hay otras aplicaciones tener acceso a ella)

Por favor, Answer y aceptar, las otras respuestas son engañosas

Ahora bien, si no era una aplicación de iOS y tenías que almacenar las credenciales en una cookie en lugar de NSUserDefaults, entonces OK, tal vez puedas argumentar para usar las sesiones. ¡Pero aparte de eso, las sesiones no valen la pena!