Accesso istantaneo all'applicazione utilizzando il token nell'URL

Probabilmente non è una buona idea mandare a un utente un'e-mail con un token longevo che consente l'accesso all'account di un utente per sempre. Perché vuoi farlo? Che problema stai cercando di risolvere?

Invia invece all'utente un link di reset con un token a vita breve di breve durata che consente all'utente di reimpostare la propria password. Consulta i consigli di questo sito sui token di reimpostazione password per i dettagli su come farlo nel modo più sicuro possibile.

Questo potrebbe essere fatto (relativamente) in sicurezza, ma devi fare attenzione a qualche cosa.

Per prima cosa, assicurati che nessuno possa accedere facilmente al token da un'altra persona (doh!). Questo è più difficile da fare nella pratica di quanto sembri. Ad esempio, se invii il token via e-mail in testo normale (che tu farai), in pratica passi il token dal server smtp al server smtp su cui non hai alcun controllo. EDIT: ma lo stesso vale anche per i token una tantum. Anche l'utilizzo di SSL sul tuo server è una buona idea, poiché codificherà le intestazioni delle richieste che includono la stringa segreta.

In secondo luogo, dovresti assicurarti che la chiave sia abbastanza lunga da richiedere troppo tempo per gli attacchi di forza bruta. Se si combina questo con il rilevamento brute-force sul proprio server (il server web hiawatha può farlo immediatamente), si dovrebbe essere abbastanza sicuri contro questi.

In terzo luogo, assicurati che la chiave sia casuale ! Se si utilizza il microtime, ciò significa che un utente malintenzionato può formulare un'ipotesi sul tempo di registrazione della vittima (la maggior parte dei siti Web ha una sorta di funzione "registrata") e semplicemente testare tutti gli hash dei timestamp in quel momento. Ciò riduce il numero di hash da testare (per un singolo utente target!) Da poco ampio a solo un milione. Potrebbe sembrare molto, ma con un PC e un tempo di risposta di 100 ms questo richiede solo un giorno. Ricorda, questo è un attacco mirato, il che rende molto pericoloso.

Un'altra opzione che potresti implementare è utilizzare sia l'hash del nome utente sia l'hash di accesso nell'URL. In questo modo non è possibile scegliere come target ogni utente.

IMO, quando vengono prese in considerazione queste cose, ottenere un accesso basato su token può essere più sicuro di un accesso "regolare", in cui le persone scelgono password errate e le scrivono su pezzi di carta sulla scrivania.

Usando token di lunga durata, stai semplificando le cose per gli attacchi bruteforce, non so come crei i tuoi token, ma con quasi infinito tempo per testare, ed essere qualcosa di così semplice come provando diversi URL, sembra facile, ad un certo punto, entrare in un account. Inoltre, l'url potrebbe essere sniffato.

I token inviati all'e-mail per reimpostare la password funzionano solo una volta (se l'applicazione è protetta ). Se non rendi inutili questi token dopo il suo primo utilizzo, rischi di rischiare nuovamente i conti degli utenti ai problemi che ho descritto prima.

Quindi, per riassumere, penso che sia una cattiva idea avere token che durano più di un singolo uso.