Leyendo datos encriptados antes de enviarlos al servidor remoto

Question

Leyendo datos encriptados antes de enviarlos al servidor remoto

#1 de sebastian nielsen (1 votos)
#2 de user73202 (0 votos)
#3 de Robert Mennell (0 votos)

3

Estoy desarrollando una aplicación móvil (Android solo por ahora) para proporcionar un servicio de correo electrónico desechable a los usuarios. Los usuarios recibirán direcciones de correo electrónico temporales para que puedan recibir y leer correos electrónicos durante un cierto período de tiempo, luego las cuentas se destruyen por completo.

En esta arquitectura, no estoy interesado en que los usuarios conozcan las contraseñas de sus cuentas de correo electrónico, ya que podrían iniciar sesión a través de un cliente común y enviar correos electrónicos o incluso correo no deseado (actualmente quiero permitir solo correos electrónicos entrantes). correos, no salientes).

Mi idea es generar una contraseña pseudoaleatoria dentro de la aplicación cada vez que el usuario desee crear un correo electrónico desechable, enviarlo a través de una solicitud HTTPS POST al servidor remoto para que se pueda crear la cuenta y luego permitir al usuario iniciar sesión en la cuenta utilizando un pequeño cliente a través de IMAPS .

Sé que tanto HTTPS como IMAPS deberían proporcionar suficiente seguridad en cuanto al cliente < - > los datos del servidor van, pero me preocupa la posibilidad de que los usuarios puedan romper el código (o introducir un dispositivo antes de su enrutador para que la solicitud de creación de buzón HTTPS pueda leerse antes de ser enviada, o similar) y de alguna manera obtener la contraseña para el correo cuenta mientras la cuenta aún existe.

¿Qué tan real es esta situación? Si los usuarios pueden obtener las contraseñas con el esquema anterior, ¿hay alguna manera de lograr mi propósito de manera segura?

Gracias.

encryption tls email mobile

pregunta nKn 11.04.2015 - 18:55

fuente

3 respuestas

Lea otras preguntas en las etiquetas encryption tls email mobile

¿Por qué los sitios web solicitan los últimos cuatro dígitos de su número de seguro social? ¿Cómo puede mi banco emitir una nueva tarjeta de crédito con el mismo número pin? [duplicar]

score 1 · Answer 1

Creo que estás haciendo las cosas mal desde el principio. Dice que desea evitar que los usuarios aprendan la contraseña para evitar que envíen correo no deseado.

Por supuesto, el servidor SMTP debe configurarse para no permitir la transmisión, ni siquiera para usuarios locales, solo debe aceptar correos electrónicos para su servicio desechable. Luego, puede dar fácilmente contraseñas aleatorias a su aplicación, completamente sin cifrar y también puede dejar que lean los correos sin SSL. No importa si sus usuarios finales los tienen en espera, todo lo que pueden hacer es leer el correo electrónico de su propia cuenta de correo electrónico desechable en el cuadro IMAP. No obtendrán ninguna ventaja al conocer la contraseña.

Para evitar que los usuarios utilicen otro cliente de correo electrónico y otro servidor SMTP (como un servidor ISP) para enviar correo no deseado utilizando las direcciones de correo electrónico del servicio desechable como remitente falsificado (no necesitarán saber la contraseña para este tipo de abuso), configure el servicio desechable tendrá un registro SPF de "v = spf1 -all". Esto garantizará que todos los correos salientes del servicio desechable se descarten como fraudulentos / falsificados de los receptores que cumplen con el estándar SPF.

score 0 · Answer 2

Puedes usar un algoritmo de cifrado como RC4 o AES. Puede cifrar la contraseña generada automáticamente en su aplicación con una clave y descifrarla en el servidor antes de la creación de la cuenta. Si algún usuario captura la transferencia, solo verá una secuencia aleatoria de letras. Si sus usuarios tienen una cuenta en su servidor, también puede generar una clave de cifrado única para cada usuario.

score 0 · Answer 3

NUNCA debe usar autenticación basada en estado (nombre de usuario y contraseñas) para una aplicación sin estado. Siempre use autenticación sin estado.

autenticación sin estado es una excelente manera de hacerlo ya que puedes haga cada solicitud una nueva solicitud con un nuevo estado que eventualmente muera. También compruebe que, si llega otra solicitud con el token anterior, elimine la casilla inmediatamente (genere un modo de pánico). Esto permitiría que, para obtener esta información y abusar de su servicio, un usuario tuviera que aplicar ingeniería inversa a su aplicación.