it-swarm-eu.dev

In che cosa dovrebbe consistere un'e-mail di verifica?

In questo momento sto generando una stringa di 25 caratteri memorizzata nel database che può essere utilizzata solo 1 volta e scade 30 minuti dopo la registrazione dell'utente.

http://example.com/security/activate/ZheGgUNUFAbui4QJ48Ubs9Epd

Faccio una rapida ricerca nel database e la logica è la seguente:

Se l'account non è attivato E se l'e-mail non è stata verificata E il codice di convalida è ancora valido, attivare l'account, contrassegnare l'indirizzo e-mail come verificato e contrassegnare il codice di convalida come utilizzato.

Ogni 72 ore, ad esempio, scarica i codici di convalida scaduti e utilizzati. Questo per dire all'utente che il collegamento di attivazione su cui è stato fatto clic è scaduto, ad esempio, se guarda la sua e-mail il giorno dopo e prova il collegamento.

Devo includere l'UUID utente nell'URL? Devo includere qualcos'altro?

Ho pensato di assicurarmi che l'indirizzo IP sul modulo di registrazione corrispondesse all'indirizzo IP della richiesta quando viene premuto il collegamento di attivazione, ma per me ho letto principalmente le mie e-mail sul mio cellulare per questo tipo di cose, quindi sarebbe un problema per UX .

65
HypeWolf

Come stai generando la stringa di 25 caratteri che includi nell'URL? È completamente casuale o si basa sull'ora corrente o sulla posta elettronica degli utenti? Dovrebbe essere casuale e non indovinabile.

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

Ciò potrebbe comportare uno scenario in cui un attore malintenzionato (Eva) vuole creare un account utilizzando l'e-mail di qualcun altro (Alice). Eva si iscrive e Alice riceve un'e-mail. Alice apre l'e-mail perché è curiosa di sapere di un account che non ha richiesto. Il suo browser (o antivirus) richiede l'URL in background, attivando inavvertitamente l'account.

Vorrei utilizzare JavaScript nella pagina per verificare la pagina effettivamente visualizzata e includere anche un collegamento nell'e-mail in cui gli utenti possono segnalare che NON hanno creato questo account.

105
Daisetsu

Aggiungendo alla risposta del Daisetsu (dato che non posso ancora scrivere commenti).

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

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

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

22
Maros D.

La tua email dovrebbe includere un codice di attivazione, non un link. Non è necessario inviare alcun collegamento utilizzato per la gestione dell'account in un'e-mail. Se l'utente (la parte legittima) si collega agli utenti (in particolare con lunghe stringhe di caratteri casuali), rende un po 'più difficile distinguere le e-mail legittime dai tentativi di phishing.

Il codice di attivazione dovrebbe essere composto 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 è imprevedibile. Ottieni il valore utilizzando il generatore di numeri casuali sicuro del sistema, proprio come dovresti fare con gli ID di sessione per i cookie.

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

Il codice di attivazione deve essere inviato tramite una POST. Reindirizzare automaticamente gli utenti all'URL di attivazione dell'account (che può essere solo https://example.com/security/activate) quando hanno finito con il resto della registrazione. Rendi più semplice l'accesso alla pagina di attivazione dell'account nel caso in cui la chiudessero accidentalmente.

Non si desidera che una richiesta GET esegua alcuna azione. Un collegamento potrebbe essere visitato senza l'interazione dell'utente (a causa del prefetching del browser o dei servizi di sicurezza della posta elettronica). 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 ancora cambiare. (Lo stesso per l'agente utente.)

Non so se sia desiderabile una funzione di cancellazione. Non utilizzo nemmeno i collegamenti non sottoscritti nelle e-mail indesiderate 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 si limita il numero di tentativi del codice di attivazione, non vedo il danno nel lasciare che il codice di attivazione scada alla fine.

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 educato. Pronuncia un massimo di 3 al giorno e un massimo di 5 al mese. (Non so se è troppo alto o troppo basso.) Come non utente vorrei semplicemente inviare e-mail dal tuo sito Web automaticamente cancellate o contrassegnate automaticamente.

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

* Non fa male hash il codice di attivazione. Inoltre, non è fondamentale per l'hash, come per le password, poiché ogni codice ha un utilizzo una tantum, non contiene informazioni private, viene generato casualmente dal server e scade.

** In realtà potresti impedire la manomissione usando un MAC crittografico, ma scoraggerei fortemente tentando questo per la maggior parte degli sviluppatori. La crittografia è difficile da ottenere.

16
Future Security

Come per qualsiasi cosa in cui si stanno usando pratiche di sicurezza, l'esposizione e la valutazione delle minacce sono qualcosa che dovrete valutare per il vostro ambiente unico e il caso d'uso. Le risposte esistenti forniscono molti punti di contatto per quella valutazione, nonché indicazioni per evitare cose come GET azioni innescate. Invece, mi concentrerò maggiormente sulla parte "utente" della UX. Toccherò anche molti dei commenti sparsi sulla pagina.

Anche ciò che stai "verificando" con l'azione attivata dalla posta elettronica è un fattore da considerare. Se tutto ciò che stai facendo è confermare che si tratta di un indirizzo email valido, quasi ogni azione sarà sufficiente. Verificare l'e-mail, l'intenzione di creare l'account e che l'utente che riceve l'e-mail è l'utente che ha avviato la creazione dell'account richiede un po 'più di impegno.

Uno "sforzo" che non dovresti non , tuttavia, è l'invio di e-mail di promemoria. Supponendo che l'utente abbia creato intenzionalmente l'account, utilizzato un indirizzo e-mail valido e desideri utilizzarlo per qualsiasi scopo offra account, cercherà l'e-mail e intraprenderà il processo di attivazione non appena sarà in grado di farlo. Il collegamento, il codice o qualsiasi altra cosa potrebbe scadere prima di utilizzarlo se vengono ignorati su altre questioni durante l'attesa dell'email. In questi casi, consentire loro di inviare nuovamente l'email di verifica. Un'e-mail di promemoria, tuttavia, è molto più probabile che sia un trigger di spam piuttosto che un vantaggio per l'utente.

Come utente, apprezzo le opzioni disponibili per attivare/verificare il mio account. L'insieme di opzioni più comune che ho riscontrato è dove l'e-mail fornisce un link che posso fare clic o tagliare e incollare, e un codice di conferma che posso inserire in un campo modulo in una pagina all'interno del mio area delle impostazioni dell'account sul sito Web. Di rado è il codice di conferma tutt'altro che un numero intero, composto da 5 a 9 cifre.

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

Il limite di tempo proposto di 30 minuti sembra un po 'severo, mentre un periodo di 24 ore potrebbe essere troppo grande se la valutazione della minaccia suggerisce che l'esposizione in 24 ore è inaccettabile. Credo che 2 ore dovrebbero essere sufficienti per quasi qualsiasi ambiente dell'utente. Soprattutto se è disponibile la possibilità di inviare nuovamente la verifica. Anche l'utilizzo di un dispositivo mobile con una connessione di 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 annunci possono bloccare JS su una base per sito o per fonte, anche quando JS è abilitato nel browser. Blocco molte fonti JS, inclusi gli script di analisi di Google, su base globale e inserisco nella whitelist alcuni siti, come Stack Exchange, dove sono disposto a supportarli con l'uso dei miei dati.

Includere un collegamento nell'e-mail 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 è una buona idea. Invece, l'e-mail dovrebbe includere la verbosità per indicare che non fare nulla causerà la mancata conferma e la cancellazione dell'account. Un collegamento da annullare nella pagina di conferma è anche peggio, poiché premia i cattivi comportamenti. Ricevo spesso e-mail, come parte di un vecchio snafu di Google, indirizzate 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 notati, quindi il mio nome utente punteggiato e la versione non notata di qualcun altro sono account diversi, tuttavia Google scivolerà di tanto in tanto e ricevo comunque la loro email :(]

Il modo in cui abbini l'indirizzo e-mail "verificato" al link di attivazione dipende dal tuo caso d'uso e dalla valutazione delle minacce. Sono leggermente infastidito quando devo riconvalidare il mio account dopo aver modificato l'indirizzo e-mail associato. L'accettazione del processo è proporzionale al mio "valore" dell'account. Per il mio conto bancario, Paypal, ecc., Accetto il 100%. Su PcPartsPicker, tuttavia, accetterei circa un 15% di tale processo.

Per quanto riguarda l'IP e/o l'agente utente, ignorali. Ad esempio, visualizzerò spesso siti e scelgo di creare un account utilizzando il mio dispositivo mobile. non, tuttavia, aprirò e-mail su di esso. Se creo un account e apprendo che devo verificarlo o confermarlo in qualche modo e l'e-mail è il metodo offerto, aspetterò fino a casa per aprire l'e-mail sul desktop, dove posso esaminarlo. 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 e-mail sono sicure quanto il Jumbo-tron di Times Square e procedi di conseguenza.

8
user135823

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

  1. Deve essere chiaro all'utente cosa sta succedendo. Viene spiegato perché questa e-mail viene ricevuta (ad es. "... qualcuno ha registrato l'account BLAH sul nostro sito, questo per confermare ...") esclude la maggior parte degli errori stupidi e ostacola ragionevolmente la pesca delle e-mail . Si spera sapere se hai appena registrato un account in qualche servizio (a meno che tu non sia completamente distratto). Quindi, ricevere un'e-mail che spiega questo non è una sorpresa. D'altra parte, una tale email sapendo che non ti sei registrato da nessuna parte dovrebbe (beh, si spera) essere abbastanza sospettosa. Se non lo è, e l'utente fa clic su qualsiasi collegamento casuale inviato via e-mail, non c'è nulla che tu possa fare comunque, non sapendo quali e-mail le persone che non conosci possono o non possono ricevere.
  2. Un token casuale (non sequenziale!) Che è ragionevolmente lungo (abbastanza lungo da garantire che non sia indovinabile e non si scontra) restituito al server. Tale token è anche memorizzato nel database per il confronto. Non importa quanto sia esattamente e quale particolare formato abbia. Non deve essere leggibile dall'uomo. Qualcosa di più di 20 caratteri (supponendo la codifica base64) dovrebbe funzionare, ma userei 40 caratteri per essere sicuro perché non ti costa nulla. Una stringa pseudocasuale a 240 bit è praticamente garantita per essere unica e irripetibile. Per comodità, lo renderei effettivamente un collegamento e il collegamento può effettivamente essere una richiesta GET. Sì, gli utenti non devono fare clic sui collegamenti, ma lo faranno comunque (non li educerai!). D'altra parte, esperienza utente è molto meglio rispetto al dover copiare e incollare qualche stringa oscura.
  3. Un modulo HTML con una sorta di pulsante "fai clic per confermare" che ri-POSTs i dati, questo garantisce che il caricamento speculativo di URL non consenta che cose accadano (involontariamente o persino maliziosamente) che l'utente sia proprietario della posta l'indirizzo non lo sa. Il modulo dovrebbe visualizzare una ragionevole quantità 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 registri tale account.
    Se sei preoccupato per i robot, il modulo può includere un "Io non sono un robot" se lo desideri (personalmente, lo ritengo superfluo, ma il tuo chilometraggio può variare).
  4. Una data (o ora) di scadenza ragionevole. Cosa è ragionevole? Nessuno può dare una risposta definitiva a tutti. Direi che qualcosa da 4 ore a due giorni è probabilmente buono. Di solito, quando ti registri per qualcosa, ricevi la tua mail di conferma entro 5-10 secondi e ti siedi davanti al computer ad aspettarla. 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 dover andare da qualche parte nel mezzo, quindi avere il token valido per un paio d'ore o un giorno sicuramente non è un errore. Inoltre, la posta può deve essere ritardata (rara, 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 ri-registrarsi un'altra volta. Il che, in realtà, non costa nulla.
2
Damon

Dalla tua domanda, sto prendendo i seguenti presupposti e se qualcuno di essi non è valido, così è la mia risposta:

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

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

Potresti voler includere l'ID utente se hai molti utenti per motivi di prestazioni (AGGIORNAMENTO: non proprio, vedi commenti sotto) La ricerca dell'utente tramite un token stringa comporterà una scansione della tabella, mentre trovarlo per ID e poi solo recuperare e confrontare la stringa è una ricerca di indice. Tuttavia, questo espone l'ID utente, cosa che potresti voler fare o meno.

0
Tom