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.