Considerazioni di sicurezza per un'applicazione Web senza funzionalità di accesso

Quando utilizzi un token singolo come quello, di solito hai almeno quattro problemi:

1. Periodo di validità. Se il token è valido per troppo tempo, potrebbe essere compromesso, se troppo breve, il metodo di consegna potrebbe essere troppo lento per consentire una buona esperienza utente.
2. Metodo di consegna. Non vuoi inviare quei token su un canale non sicuro come la posta senza PGP o S / MIME. Se lo fai, il token (efficacemente il nome utente e la password durante il periodo di tempo indicato da 1) potrebbe essere compromesso e tutto si interrompe in modo orribile. Se usi PGP o S / MIME, questo mette un carico pesante sugli utenti, limitando efficacemente la base di utenti a circa l'1% di ciò che è possibile, come stima approssimativa, poiché altri non usano né la tecnologia né sanno come (e stai effettivamente mettendo "l'ostacolo della seccatura" per registrarti abbastanza in alto)
3. Metodo per richiedere un tale token One time. Se consenti a qualsiasi utente non autenticato di inserire un nome e hai usato un crypto (probabilmente computazionalmente difficile e pieno di risorse) e un canale di comunicazione, c'è una superficie di attacco più alta per gli attacchi DDoS.
4. Usabilità. Se questo non suona ancora come UX hell: che dire delle persone che non hanno PGP sui loro telefoni (non sono gratis sulla maggior parte delle piattaforme) ma vogliono usare il tuo servizio mentre sei in movimento? Che dire delle persone che usano una macchina in qualche altro posto, come gli internet cafè? Non vuoi controllare anche la posta o il modo in cui inviare il token che trovi lì.

Oh e mentre sono a: la tua domanda sembra che tu non stia mai invalidando i token. È orribile per molte ragioni, come la lunghezza del tuo token di esempio: dovrebbe avere molta più entropia e molti più caratteri.