Consideraciones de seguridad para una aplicación web sin función de inicio de sesión

Cuando usas un token de una sola vez así, generalmente tienes al menos cuatro problemas:

1. Marco de tiempo de validez. Si el token es válido por mucho tiempo, podría verse comprometido, si es demasiado corto, el método de entrega podría ser demasiado lento para permitir una buena experiencia de usuario.
2. Método de entrega. No desea enviar esos tokens a través de un canal inseguro como el correo sin PGP o S / MIME. Si lo hace, el token (de hecho, el nombre de usuario y la contraseña durante dicho período de tiempo de 1) puede verse comprometido y todo se rompe horriblemente. Si utiliza PGP o S / MIME, eso supone una gran carga para los usuarios, restringiendo efectivamente la base de usuarios a aproximadamente el 1% de lo que es posible, como una estimación aproximada, ya que otros no utilizan ninguna tecnología y no saben cómo (y efectivamente está poniendo el "obstáculo de problemas" para registrarse bastante alto)
3. Método de solicitud de tal token de una sola vez. Si permite que cualquier usuario no autenticado ingrese un nombre y use algún criptográfico (probablemente computacionalmente difícil y con recursos) y un canal de comunicación, hay una mayor superficie de ataque para los ataques DDoS.
4. Usabilidad. Si esto todavía no suena como UX hell: ¿qué pasa con las personas que no tienen PGP en sus teléfonos (no es gratis en la mayoría de las plataformas) pero quieren usar su servicio mientras están en movimiento? ¿Qué pasa con las personas que usan una máquina en algún otro lugar, como los cafés de Internet? No desea consultar también el correo o cualquier otra forma de enviar el token que encuentre allí.

Ah, y mientras estoy en: tu pregunta suena como si nunca estuvieras invalidando las fichas. Eso es horrible por muchas razones, al igual que la longitud de tu token de ejemplo: debería tener mucha más entropía y muchos más personajes.