¿Existe una mejor manera de tener descargas seguras sin el requisito de una cuenta?

Navega tus respuestas
3

El trabajo

Tiene la tarea de proporcionar archivos de gran tamaño con datos confidenciales a personas ajenas a su empresa.

Limitaciones y mandatos

  1. Los destinatarios de los datos deben ser notificados por correo electrónico
  2. El tamaño de los archivos prohíbe el envío de datos por correo electrónico
  3. Podría haber decenas o cientos de miles de usuarios, por lo que crear cuentas para ellos no es una opción.
  4. Un destinatario podría ser cualquier persona que tenga una dirección de correo electrónico.
  5. Necesita la capacidad para que un destinatario pueda consumir programáticamente el enlace y descargar el archivo para que pueda importar en su software sin interacción humana.
  6. Necesitas mantener esto lo más seguro posible.

Solución propuesta

Les proporcionaría a los destinatarios un enlace a través de un correo electrónico (TLS protegido) y simplemente harían clic en el enlace para descargar el archivo. El enlace contendría un código de 25 caracteres que les permitiría acceder a su archivo. Si una IP (¿o una dirección MAC?) Proporcionó un código erróneo 10 veces, se incluiría en la lista negra durante 14 días para evitar un ataque de fuerza bruta para obtener acceso a más archivos. El archivo sería un archivo zip que está protegido por contraseña con la dirección de correo electrónico del destinatario como la contraseña. Los archivos en sí solo estarían disponibles por un período de tiempo fijo; la expiración de ese tiempo causaría que los archivos se eliminen mediante un proceso de back-end y que el código esté disponible para otra descarga (aunque es posible que nunca se vuelva a utilizar).

Entonces, con mi solución, un posible escenario sería: Me dan una dirección de correo electrónico y debo proporcionarles un archivo personalizado para ellos. Creo un archivo, lo comprimí con la dirección de correo electrónico del destinatario como contraseña, lo guardo en mi aplicación, mi aplicación dice que la URL del archivo será www.test.com/GetFile.aspx?UID=12....99 y luego les envío un enlace.

Obviamente, si el correo electrónico que les enviamos con el enlace está comprometido, los archivos vinculados en el correo electrónico también podrían verse comprometidos.

¿Hay un mejor enfoque?

    
pregunta UnhandledExcepSean 18.05.2015 - 22:17
fuente

3 respuestas

4

La seguridad debe estar equilibrada con la usabilidad. Encriptar el archivo con los anuncios de dirección de correo electrónico solo una pequeña cantidad de seguridad adicional, y agrega complejidad para los usuarios finales.

Bloquear al usuario durante 2 semanas después de solo 10 intentos fallidos también es una exageración. Pude ver fácilmente a alguien en una empresa que lo intenta 10 veces y no tiene éxito y que le causa a usted y a ellos enormes dolores de cabeza. Un código generado de forma aleatoria de 25 caracteres ya es suficiente protección, entonces, ¿por qué preocuparse por los ataques de fuerza bruta que solo causarán problemas?

La caducidad del enlace después de un cierto período de tiempo está bien y es relativamente estándar. Eso significa que comprometer la casilla de correo electrónico no compromete el archivo.

    
respondido por el Steve Sether 19.05.2015 - 00:07
fuente
2

Suponiendo que tiene el correo electrónico para el usuario y algún secreto del servidor, puede hacer lo siguiente:

  • Cree un token que contenga el archivo para descargar y que esté cifrado con el secreto del lado del servidor, es decir, solo el servidor mismo puede descodificar el token. Mire tokens JWT para ver un ejemplo. Para asegurarse de que el mismo archivo no tenga el mismo token, también puede agregar algunos datos aleatorios antes del cifrado (en caso de que el cifrado en sí no proporcione algún tipo de vector de inicialización aleatoria). También podría ser útil agregar un tiempo de caducidad para el token. Y en caso de que el token no sea lo suficientemente largo y tengas miedo de ataques de fuerza bruta, simplemente agrega un poco más de relleno al token (antes del cifrado).
  • Envíe un enlace con el token al usuario por correo electrónico.
  • Si el usuario accede al sitio, verifique la validez del token (es decir, se puede descifrar, el HMAC se ajusta, no está vencido) y extraiga el archivo que el usuario desea obtener.
  • Proporcione el archivo al usuario. Para la protección contra MITM, puede usar aquí https, pero tenga en cuenta que un atacante potencial podría haber interceptado el correo.

Para obtener protección adicional contra un atacante que podría haber interceptado el correo con el token, puede solicitar algún secreto al usuario en el lugar donde el usuario solicita la descarga del archivo o puede generar un secreto usted mismo y mostrárselo al usuario. El secreto debe agregarse al token y debe ser proporcionado por el usuario al descargar el archivo.

    
respondido por el Steffen Ullrich 19.05.2015 - 07:57
fuente
1

Lo ideal sería cifrar el archivo que desea compartir con una clave simétrica, firmar el archivo cifrado con su clave privada y luego publicar el archivo cifrado en un lugar público (un servidor web de acceso público funcionaría). Luego, cuando desee enviar el archivo a alguien, cifrará la clave simétrica del archivo cifrado con la clave pública del usuario al que desea enviar el archivo y enviará esa clave al usuario junto con un enlace al archivo.

El usuario podría descargar el archivo cifrado, verificar el archivo con su clave pública, usar su clave privada para descifrar la clave simétrica que les envió y luego usar esa clave para descifrar el archivo.

Este enfoque es mucho más seguro que el que sugirió en su pregunta, ya que no confía en que la cuenta de correo electrónico del usuario sea segura para mantener el archivo privado, y le asegura al usuario que el archivo que descargó realmente vino de ti.

    
respondido por el Ajedi32 18.05.2015 - 23:21
fuente

Lea otras preguntas en las etiquetas

¿Qué tan seguro es MD5 para la autenticación de mensajes TLS? John the Ripper faltan formatos [cerrado]