Acceder al documento con un token de 6 letras

9

Estamos creando una aplicación web donde los usuarios pueden insertar 6 letras / dígitos (A_Z, 0-9) en un formulario para acceder a un documento. Cada documento tiene un código de acceso asignado aleatoriamente como este: 1ABH5F.

Cuando el usuario inserta un código válido, se muestra el documento. No hay inicio de sesión de usuario (no hay autenticación), está abierto al público.

El extremo frontal accederá al documento a través de una API sin estado; el código se enviará a la API, que devolverá el documento.

¿Cómo debemos implementar la seguridad de la información? Nadie aquí es un experto en seguridad, pero pensábamos así:

  1. Usando un captcha en la parte delantera
  2. Limitar las llamadas a la API desde una única IP más de 3 veces / hora

¿Qué otras cosas tenemos que implementar para evitar el acceso a los documentos?

Supongo que es muy importante especificar el caso de uso para este sistema:

Es un sistema para cualquier persona que tenga este documento para ver el documento original (digital). Se utilizará en un entorno donde los usuarios pueden imprimir los documentos (por ejemplo: concesionario de automóviles) y llevarlos a otras compañías (por ejemplo, la oficina de registro de automóviles).

El problema aquí es que los usuarios pueden (¡y lo hacen!) falsificar los documentos impresos y luego llevarlos a otras compañías (oficina de registro de automóviles). Estas otras compañías deben tener una forma de verificar si el original es el mismo que la versión impresa.

Como no sabemos cuáles son las otras compañías (cualquiera de las más de 10000 oficinas de registro de automóviles), cualquier persona que posea o vea el token de 6 letras puede acceder al documento original.

    
pregunta Peter 26.09.2016 - 10:13
fuente

3 respuestas

27

Fuerza bruta

Así que tienes un alfabeto de tamaño 36 y 6 caracteres. Eso te da alrededor de dos mil millones de fichas diferentes. Digamos que tienes mil documentos diferentes. Eso le da un cambio de uno en dos millones de adivinar un token asociado con un documento. Probar desde mil IP diferentes: s cada hora durante un año le daría casi diez millones de conjeturas, eso debería darle un par de documentos.

Claro, el CAPTCHA hace esto más difícil. Pero no son perfectos, y siempre pueden ser descifrados por humanos .

El problema aquí es que, dado que solo ingresa un token y no tiene ID de documento, solo puede calificar el límite de IP y no de documento. Eso hace que sea muy difícil protegerse contra la fuerza bruta, a menos que tenga un espacio muy grande para recoger tokens.

Compartir

Una contraseña es personal y le recomendamos que no la comparta. Eso significa que se puede cambiar fácilmente si está comprometido, y tienes cierto control sobre quién lo controla.

Se supone que un documento como este debe compartirse por diseño. Tienes muy poco control sobre quién lo consigue. Acabará en servidores de correo y copias de seguridad y publicará sus escritorios en todo el mundo.

No tiene idea de quién tiene acceso al token, y si necesita cambiarlo, tendrá que redistribuirlo a todas las personas que se supone que lo tienen. Eso tampoco es seguro ni práctico.

Conclusión: debe haber una mejor manera

Esto no te dará muy buena seguridad. Si el recurso que está protegiendo no es muy importante, podría ser suficiente, pero no lo usaría para nada de valor.

No sé su caso de uso exacto, pero sea lo que sea, debe haber una mejor manera de resolver este problema que rodar su propia API. El uso de una solución existente también le ahorraría el problema de tener que escribir su propio código.

Use un servicio de almacenamiento en la nube existente, una conexión VPN en la intranet de la empresa o alguna otra cosa. Simplemente no encienda su IDE y comience a codificar.

Actualización: su caso de uso

Este es uno de los casos en los que un token de acceso es probablemente una buena idea. Pero para solucionar los problemas mencionados anteriormente, haría esto:

  • Mantenga tanto el CAPTCHA como el límite de velocidad por IP. (Es posible que desee reconsiderar cómo se realiza la limitación de la velocidad para evitar el DOS accidental o deliberado).
  • Para lidiar con la fuerza bruta, aumentaría el tamaño del token. Google Drive utiliza 49 caracteres con mayúsculas, minúsculas y números. Eso debería ser suficiente para ti también.
  • Para solucionar el problema del uso compartido, imprima la URL con el token en un código QR en el propio documento. Esto trae el problema del agujero a los dominios de los papeles físicos con los que la gente suele lidiar. Las personas que vean el papel tendrán acceso al original digital. Eso es fácil de entender.
  • Considere establecer un límite en la cantidad de veces que se puede acceder al documento, o al menos un tiempo máximo durante el tiempo que se puede usar el token. Si el automóvil debe registrarse dentro de una semana, no hay ninguna razón para que el token funcione después de las dos.
  • No almacene los tokens en texto plano en su base de datos. Hash ellos (Algo rápido como SHA256 debería ser suficiente aquí, no es necesario desplegar bcrypt cuando tengas tokens aleatorios grandes).
  • Use un CSPRNG para generar los tokens, de lo contrario, un atacante podría adivinarlos teniendo acceso a unos tokens.
respondido por el Anders 26.09.2016 - 10:54
fuente
7

Ya que dice "cualquier persona que tenga acceso al token de 6 letras puede acceder al documento original", asumo que no hay nada realmente secreto en esto (es decir, no pude cometer fraude simplemente al encontrar un token en la basura de mi vecino). De lo contrario, elija un esquema de autenticación regular con el registro de correo electrónico y las contraseñas.

Muchos sistemas basados en token se utilizan de la forma que describe, aunque en su caso, la longitud del token es sorprendentemente pequeña. Le sugiero que use tokens al menos el doble de tiempo: esto haría que los ataques de fuerza bruta no sean prácticos sin hacer que el sistema sea mucho más difícil de usar.

PS. Ah, y excluya las letras O y I de su alfabeto si aún no lo ha hecho.

    
respondido por el Dmitry Grigoryev 26.09.2016 - 12:27
fuente
3
  

Limitar las llamadas a la API desde una única IP más de 3 veces / hora

Lo primero es lo primero, este es un gran riesgo de denegación de servicio. Quedarse encerrado por una hora solo porque alguien confundió "l" y "1" es inaceptable.

Tenga en cuenta que casi todas las computadoras de la oficina están detrás de NAT44. Hay varios usuarios detrás de cada IP. Con CGNAT (NAT444) y NAT464, también verá muchos usuarios domésticos en diferentes edificios utilizando la misma IP.

    
respondido por el Navin 27.09.2016 - 03:38
fuente

Lea otras preguntas en las etiquetas