Come stai generando la stringa di 25 caratteri che includi nell'URL? È completamente casuale o è basato sull'ora corrente o sull'email degli utenti? Dovrebbe essere casuale e non indovinabile.

Dovresti assicurarti che la pagina di verifica venga effettivamente visualizzata (non solo che si sia verificata una richiesta GET). Browser come Chrome (e programmi antivirus) spesso caricano gli URL senza che l'utente faccia clic esplicitamente su di essi come pre-fetch o per eseguire la scansione per motivi di sicurezza.

Ciò potrebbe portare a uno scenario in cui un malintenzionato (Eve) desidera creare un account utilizzando l'email di qualcun altro (Alice). Eve si iscrive e Alice ha ricevuto un'e-mail. Alice apre l'email perché è curiosa di un account che non ha richiesto. Il suo browser (o antivirus) richiede l'URL in background, attivando inavvertitamente l'account.

Vorrei utilizzare JavaScript sulla pagina per verificare la pagina effettivamente visualizzata e includere anche un collegamento nell'email in cui gli utenti possono segnalare di NON aver creato questo account.

In aggiunta alla risposta di Daisetsu (dato che non posso ancora scrivere commenti).

Non sarebbe male creare un modulo e chiedere all'utente di creare la password. in questo modo, l'utente dovrebbe inserire una nuova password e dopo averla inviata, l'account verrebbe attivato. Risolverà il controllo antivirus in background.

Per quanto riguarda l'URL, dovrebbe essere abbastanza lungo, poiché è una stringa casuale. C'è una minima possibilità che tu abbia 2 chiavi dello stesso contenuto contemporaneamente.

Controllare l'IP non sarebbe utile in quanto alcuni ISP potrebbero ruotare gli indirizzi IP in modo da bloccare qualcuno che vuole registrarsi ma non può.

La tua email deve includere un codice di attivazione, non un link. Non inviare alcun collegamento utilizzato per la gestione dell'account in un'e-mail. Se tu (la parte legittima) invii link di posta elettronica (specialmente con lunghe stringhe di caratteri casuali) agli utenti, rendi un po 'più difficile distinguere le email legittime dai tentativi di phishing.

Il codice di attivazione dovrebbe essere costituito da caratteri che possono essere facilmente copiati e incollati (senza spazi, "+", "-", ecc.) e che sono anche facili da inserire manualmente. Lettere e numeri funzionano. La sicurezza del codice di attivazione dipende dal fatto che sia imprevedibile. Si ricava il valore utilizzando il generatore di numeri casuali sicuro del sistema, proprio come si dovrebbe fare con gli ID di sessione per i cookie.

I codici di attivazione devono essere memorizzati in una tabella di database, ogni riga con un ID profilo, l'attivazione codice ^* e l'ora di scadenza. Non vuoi inserire l'ID profilo o l'ora di scadenza in un cookie, in un URL o nel codice di attivazione. ^** Un utente malintenzionato potrebbe manomettere l'ID per assumere il controllo di un altro account. Devi verificare queste cose lato server perché la tua politica di sicurezza non può fidarsi ciecamente dei dati del client.

Il codice di attivazione deve essere inviato tramite una richiesta POST. Reindirizza automaticamente gli utenti all'URL di attivazione dell'account (che può essere semplicemente https://example.com/security/activate ) quando hanno terminato il resto della registrazione. Rendi più facile accedere nuovamente alla pagina di attivazione dell'account nel caso in cui venga chiusa accidentalmente.

Non desideri che una richiesta GET esegua alcuna azione. Un collegamento potrebbe essere visitato senza l'interazione dell'utente (a causa del precaricamento del browser o dei servizi di sicurezza dell'email). Inoltre, l'inserimento di segreti in un URL potrebbe far trapelare dati sensibili. (Tramite intestazioni di riferimento o componenti aggiuntivi del browser.)

Non preoccuparti dell'IP, potrebbe comunque cambiare. (Lo stesso per l'agente utente.)

Non so se sia desiderabile una funzione di cancellazione. Non uso nemmeno i collegamenti di annullamento dell'iscrizione nelle e-mail non richieste perché potrebbe essere un modo per determinare se esiste o meno un essere umano associato a un indirizzo e-mail. Se il codice di attivazione è abbastanza lungo da resistere alla forza bruta o se limiti il ​​numero di tentativi del codice di attivazione, non vedo il problema nel lasciare semplicemente scadere il codice di attivazione.

D'altra parte Potrebbe essere utile ridurre il numero di email di attivazione dell'account indesiderate. Puoi limitare il numero di email che invii a un indirizzo, per essere gentile. Diciamo un massimo di 3 al giorno e un massimo di 5 al mese. (Non so se sia troppo alto o troppo basso.) In qualità di non utente, mi limiterò a fare in modo che le email dal tuo sito web vengano eliminate automaticamente o contrassegnate automaticamente come lette.

Ci sono molte variabili da considerare per le email di attivazione indesiderate. Molto probabilmente ha più a che fare con l'esperienza utente che con la sicurezza. Potresti arrivare a fornire una funzione "annulla la mia attivazione e non inviare mai e-mail a questo indirizzo perché non mi iscriverò mai", ma questo ha evidenti problemi. (Devi comunque verificare anche l'email della persona.)

_{* Non fa male eseguire l'hash del codice di attivazione. Inoltre, non è fondamentale l'hash, come con le password, perché ogni codice può essere utilizzato una sola volta, non contiene informazioni private, viene generato in modo casuale dal server e scade.}

_{** Potresti effettivamente impedire la manomissione utilizzando un MAC crittografico, ma sconsiglierei vivamente di tentarlo per la maggior parte degli sviluppatori. La crittografia è difficile da ottenere correttamente.}

Come per qualsiasi cosa in cui utilizzi pratiche di sicurezza, l'esposizione e la valutazione delle minacce sono qualcosa che dovrai valutare per il tuo ambiente e caso d'uso unici. Le risposte esistenti forniscono molti punti di contatto per quella valutazione, così come indicazioni su cose da evitare, come le azioni attivate GET . Invece, mi concentrerò maggiormente sulla parte "utente" della UX. Toccherò anche molti dei commenti sparsi nella pagina.

Anche esattamente ciò che stai "verificando" con l'azione attivata dall'email è un fattore da considerare. Se tutto ciò che stai facendo è confermare che si tratta di un indirizzo email valido, allora quasi tutte le azioni saranno sufficienti. Verificare l'email, l'intenzione di creare l'account e che l'utente che riceve l'email sia l'utente che ha avviato la creazione dell'account richiede un po 'più di impegno.

Uno "sforzo" che non dovresti deve prendere, tuttavia, l'invio di email di promemoria. Supponendo che l'utente abbia creato intenzionalmente l'account, utilizzato un indirizzo e-mail valido e desideri utilizzare l'account per qualsiasi scopo tu offra gli account, cercheranno l'e-mail e intraprenderanno il processo di attivazione non appena sarà in grado di farlo. Il collegamento, il codice o qualsiasi altra cosa, potrebbero scadere prima che vengano utilizzati se vengono deviati su altri argomenti mentre attendono l'email. Consentire loro di inviare nuovamente l'email di verifica in questi casi va bene. Un'e-mail di promemoria, tuttavia, è molto più probabile che sia un trigger di spam che un vantaggio per l'utente.

Come utente apprezzo avere opzioni disponibili per attivare / verificare il mio account. L'insieme di opzioni più comune che ho incontrato è dove l'email fornisce un collegamento su cui posso fare clic o tagliare & incolla, e un codice di conferma che posso inserire in un campo del modulo su una pagina all'interno del mio area delle impostazioni dell'account sul sito web. Raramente il codice di conferma è tutt'altro che un numero intero, da 5 a 9 cifre.

Le email di verifica che mi danno, come utente, maggiore sicurezza sono quelle che hanno un hash dall'aspetto crittografico nell'URL ( / verify? l = lgGS2SBjMTU4NjkwNjYxMjI5MDBhZDk2YjEyMzMzYjNhZmQxOb ), che mi porta a) pagina unica per me dove poi devo inserire la password che ho usato per creare l'account. L'utilizzo dell'hash conferma che il link è stato ricevuto in una mail, non indovinata o forzata, verificando così che l'email sia valida. La pubblicazione di quella pagina univoca, prima di qualsiasi altra azione, consente al server di contrassegnare l'email a cui è stata inviata come "valida" senza confermare la creazione dell'account. L'immissione della password conferma la presenza di un attore dall'altra parte, al contrario di alcune operazioni antivirus, di rilevamento di malware o di pre-fetch. La validità della password conferma, con un ragionevole grado di certezza, che il destinatario dell'email e il creatore dell'account sono la stessa persona.

Il limite di tempo proposto di 30 minuti sembra un po ' grave, mentre un periodo di 24 ore potrebbe essere troppo ampio se la valutazione della minaccia suggerisce che l'esposizione in 24 ore è inaccettabile. Credo che 2 ore dovrebbero essere sufficienti per quasi tutti gli ambienti degli utenti. Soprattutto se è disponibile la possibilità di inviare nuovamente la verifica. Anche l'utilizzo di un dispositivo mobile con una connessione a 14 kb / s a ​​un account POP remoto dovrebbe essere in grado di completare lo scambio entro 120 minuti.

L'uso di JS per verificare in qualche modo le azioni umane può essere problematico. JS può essere disattivato ed è molto più spesso di quanto molti sviluppatori web vorrebbero sapere. In secondo luogo, i blocchi degli annunci possono bloccare JS in base al sito o alla sorgente anche quando JS è abilitato nel browser. Blocco molte fonti JS, inclusi gli script di analisi di Google, su base globale e ne autorizzo alcune per i siti, come Stack Exchange, dove sono disposto a supportarle con l'uso dei miei dati.

Includere un link nell'email, o nella pagina di conferma, per "cancellare" l'account è uno spreco. Nell'e-mail è effettivamente controproducente in quanto suggerisce che fare clic su un collegamento su un account che non si desidera sia una buona idea. Invece, l'e-mail dovrebbe includere parole per indicare che non fare nulla causerà la non conferma dell'account e forse l'eliminazione. Un link per cancellare nella pagina di conferma è anche peggio, in quanto premia un cattivo comportamento. Ricevo spesso e-mail, come parte di un vecchio snafu di Google, dirette a un altro account Gmail e presumo che sia vero anche il contrario per l'altro account. [Ai vecchi tempi Google non univa i nomi utente punteggiati e non punteggiati, quindi il mio nome utente punteggiato e la versione non punteggiata di qualcun altro sono account diversi, tuttavia Google commette errori di tanto in tanto e ricevo comunque la loro email :(]

Il grado di accoppiamento tra l'indirizzo email "verificato" e il link di attivazione è una funzione del tuo caso d'uso e della valutazione delle minacce. Sono leggermente infastidito quando devo convalidare nuovamente il mio account dopo aver cambiato l'indirizzo email associato. Il modo in cui accetto il processo è proporzionale al mio "valore" del conto. Per il mio conto bancario, PayPal, ecc., Accetto al 100%. Su PcPartsPicker, tuttavia, accetto circa il 15% un processo.

Per quanto riguarda l'IP e / o lo user agent, ignorali. Come esempio, spesso visualizzerò i siti e sceglierò di creare un account, utilizzando il mio dispositivo mobile. non , tuttavia apro le email su di esso. Se creo un account e apprendo che devo verificarlo o confermarlo in qualche modo, e l'email è il metodo offerto, aspetto di tornare a casa per aprire l'email sul desktop, dove posso esaminarla. L'IP e l'agente utente saranno quindi molto diversi. La mia password, tuttavia, rimarrà la stessa e dovrebbe essere sufficiente per verificarmi come creatore dell'account originale.

Ricorda solo che le email sono sicure quanto il Jumbo-tron a Times Square e procedere di conseguenza.

Un'email di verifica ha bisogno di poche cose, sia per essere ragionevolmente sicura che per essere facile da usare:

1. Deve essere chiaro all'utente cosa sta succedendo. La spiegazione del motivo per cui viene ricevuta questa email (ad es. "... qualcuno ha registrato l'account BLAH sul nostro sito, questo è per confermare ..." ) esclude la maggior parte degli errori stupidi e ostacola ragionevolmente bene le email di pesca . Spero che sappia se hai appena registrato un account in qualche servizio (a meno che tu non sia completamente dementato). Quindi, ricevere un'e-mail che spiega questo non è una sorpresa. D'altra parte, un messaggio di questo tipo sapendo che non ti sei registrato da nessuna parte dovrebbe (beh, si spera) essere abbastanza sospetto. In caso contrario, e l'utente fa clic su un collegamento casuale inviato tramite e-mail, non c'è niente che potresti fare comunque, non sapere quali messaggi di posta le persone che non conosci possono o non possono ricevere.
2. Un token casuale (non sequenziale!) Che è ragionevolmente lungo (abbastanza lungo da garantire che sia indovinabile e non collida) passato al server. Anche quel token viene memorizzato nel database per il confronto. Non importa quanto sia esattamente lungo e quale formato particolare abbia. Non è necessario che sia leggibile dall'uomo. Qualunque cosa al di sopra di 20 o giù di lì caratteri (assumendo la codifica base64) dovrebbe funzionare, ma userei 40 caratteri per essere sicuro perché non ti costa davvero nulla. Una stringa pseudocasuale a 240 bit è praticamente garantita per essere unica e indovinabile. Per comodità, lo renderei effettivamente un collegamento, e il collegamento può effettivamente essere una richiesta GET . Sì, gli utenti non dovrebbero fare clic sui collegamenti, ma lo faranno comunque (non li istruirai!). D'altra parte, l ' esperienza utente è molto migliore rispetto a dover copiare e incollare qualche stringa oscura.
3. Un modulo HTML con una sorta di pulsante "fai clic per confermare" che ri- POST s i dati, questo garantisce che il caricamento speculativo degli URL non permetta che accadano cose (involontariamente o anche malevolo) di cui l'utente proprietario dell'indirizzo di posta non è a conoscenza. Il modulo dovrebbe visualizzare una quantità ragionevole di informazioni in modo che l'utente sappia cosa sta succedendo e come ultima possibilità per attivare "WTF?" nel caso in cui l'utente non abbia registrato quell'account.
   Se sei preoccupato per i robot, il modulo può includere un "Non sono un robot" se lo desideri (personalmente, io lo ritieni superfluo, ma il tuo chilometraggio può variare).
4. Una data di scadenza ragionevole (o tempo). Cosa è ragionevole? Nessuno può dare una risposta definitiva per tutti. Direi che qualsiasi cosa da 4 ore a due giorni è probabilmente buona. Di solito, quando ti registri per qualcosa, ricevi la tua mail di conferma entro 5-10 secondi e ti siedi davanti al computer in attesa. Potrebbe essere più lungo se si utilizza la tipica posta aziendale in modalità paranoia che impiega pochi minuti a scansionare ogni e-mail esterna. Tuttavia, potresti ricevere una telefonata o devi andare da qualche parte nel mezzo, quindi avere il token valido per un paio d'ore o un giorno non è certamente un errore. Inoltre, la posta può essere ritardata (raro, ma succede).
   D'altra parte, non ha senso sprecare spazio su disco mantenendo i token di conferma (e bloccando i nomi degli account!) Per settimane , mesi o anni. Non solo questo consuma risorse inutilmente, ma qualcuno che non conferma entro un giorno o due probabilmente non lo farà mai, comunque. Oppure potrebbero semplicemente registrarsi di nuovo un'altra volta. Il che, in realtà, non costa nulla.

Dalla tua domanda, sto assumendo i seguenti presupposti e se qualcuno di essi non è valido, lo è anche la mia risposta:

1. l'utente si registra sulla tua pagina web e imposta nome utente / email e password durante registrazione
2. la verifica e-mail ha lo scopo di garantire che l'utente si sia registrato con un indirizzo e-mail appropriato.
3. l'attivazione dell'account è l'unica cosa che l'e- il collegamento di posta fa. Non consente la reimpostazione della password o altre funzioni simili. Fondamentalmente fa "UPDATE user SET attivato = true WHERE token =% 1"

In questo caso, dal punto di vista della sicurezza, il tuo approccio va assolutamente bene. 25 caratteri ti danno abbastanza sicurezza contro collisioni casuali e tentativi di forza bruta, l'uso una tantum protegge dallo sniffing e da attacchi simili e comunque l'unica cosa che qualcuno potrebbe realizzare è attivare un account.

per includere l'ID utente se si hanno molti utenti per motivi di prestazioni (AGGIORNAMENTO: non proprio, vedere i commenti di seguito) La ricerca dell'utente tramite un token di stringa si tradurrà in una scansione della tabella, mentre ID e quindi solo il recupero e il confronto della stringa è una ricerca nell'indice. Tuttavia, questo espone l'ID utente, cosa che potresti o non potresti voler fare.