Domanda:
In cosa dovrebbe consistere un'e-mail di verifica?
HypeWolf
2018-11-05 05:39:08 UTC
view on stackexchange narkive permalink

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

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

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

Se l'account non è attivato E se l'email non è stato verificato E il codice di convalida è ancora valido, attiva l'account, contrassegna l'indirizzo email come verificato e contrassegna il codice di convalida come utilizzato.

Ogni 72 ore, ad esempio, sarebbe scaduto e codici di convalida utilizzati. Questo per dire all'utente che il link di attivazione cliccato è scaduto, ad esempio se guarda la sua email il giorno dopo e prova il collegamento.

Devo includere l'UUID dell'utente nel 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 link di attivazione, ma per me ho letto principalmente le mie e-mail su il mio cellulare per questo genere di cose, quindi sarebbe una seccatura per UX.

Non preoccuparti di tenere / controllare l'indirizzo IP.Ci sono così tanti motivi per cui gli indirizzi IP possono cambiare in breve tempo: basta spostarsi da un bar a quello accanto.
Oltre alle altre risposte, fornire sempre un modo per indicare che la registrazione con l'indirizzo e-mail fornito è stata un errore / non dovrebbe esistere.Le e-mail di verifica in cui l'unica azione possibile è confermare non sono molto utili. * Per esperienza personale: ho un nome abbastanza comune (in Ungheria) e ricevo costantemente e-mail di richiesta di conferma dell'account per altre persone che hanno erroneamente fornito il mio indirizzo invece del loro, e la maggior parte di loro non può essere rifiutata.La parte migliore è quando continuano a "ricordarmelo" ogni settimana per confermare il mio account che non ho mai creato. *
30 minuti sono un po 'difficili: probabilmente riuscirei ad arrivare da qui alla mia e-mail in quel lasso di tempo, ma è la stessa distanza di nuovo dal Web, e sono abbastanza sicuro di non poter gestire legalmente il roundviaggio in meno di 50 minuti.
@MártonMolnár È meglio insegnare agli utenti che il modo corretto per gestire la ricezione di un'e-mail di conferma inaspettata è eliminare (o archiviare) l'email.Fare clic sui collegamenti nelle e-mail che non ti aspettavi di ricevere è un rischio che non dovresti correre.Il reinvio automatico dell'e-mail di conferma è una cattiva pratica e li contrassegnerei come spam.
30 minuti?Perché?Non vedo come stai realizzando qualcosa.Mi aspetto di avere * almeno * 24 ore per attivare un account ...
Aggiungerei anche una funzione in cui prima che l'URL venga aggiunto al sito Web in cui viene controllato nel database per assicurarmi di non utilizzare la stessa stringa due volte
In effetti, 30 minuti sono troppo brevi.La tua posta potrebbe non essere nemmeno recapitata alla casella di posta dell'utente in così poco tempo.24 ore sono normali e quasi tutte le persone avranno ricevuto l'e-mail da allora.
Per inciso, per la generazione di codice questo è uno di quei casi in cui di solito è più semplice generare un UUID casuale e chiamarlo fatto.
questa non è una considerazione di sicurezza, ma assicurati che ci sia un modo per inviare nuovamente l'email se si è persa lungo il percorso.inoltre, se gli accessi sono basati su nomi utente anziché e-mail, consenti agli utenti di accedere e modificare la loro e-mail anche se l'account non è ancora verificato - a volte fai un errore di battitura :)
Sei risposte:
#1
+107
Daisetsu
2018-11-05 05:48:25 UTC
view on stackexchange narkive permalink

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.

Fantastico, grazie mille per la tua intuizione.La stringa è effettivamente generata dalla funzione crypto.randomBytes di NodeJS e l'applicazione chiama già una funzione javascript ma non per il motivo che hai indicato.Questa è una risposta esauriente che evidenzia cose a cui non avevo pensato.
Vorrei anche aggiungere a questo: se hai una funzione di modifica dell'email, assicurati di cancellare tutti i token esistenti quando l'utente cambia il proprio indirizzo email.Ciò impedisce a un utente di registrarsi con un'e-mail valida, cambiare la propria e-mail in un account non valido e quindi fare clic sul collegamento di registrazione.
`Vorrei utilizzare JavaScript sulla pagina per verificare la pagina effettivamente renderizzata` degno di nota che il JS * può essere bloccato * dall'utente.Se lo è, allora forse registrano sul link * pensando * che ha verificato l'account ma quando provano ad accedere, ad esempio, la settimana prossima scoprono che è stato cancellato.
@vlaz è vero, ma gli utenti che bloccano JavaScript per impostazione predefinita sono spesso consapevoli che questo interrompe funzionalità potenzialmente critiche.Questo potrebbe essere mitigato assicurandosi che la "conferma" dell'attivazione dell'account sia resa visibile da JavaScript.Qualsiasi utente con JS disabilitato vedrebbe un messaggio che indica il problema e la soluzione.
A volte la pagina ha un grande pulsante "Attiva account".Ciò rende chiaro che l'account non è ancora attivo, risolve il problema JS off e consente di avere accanto una "richiesta di annullamento", tutto in una volta.
La restituzione di un reindirizzamento (302) al controller di attivazione reale risolve il problema del prefetch dell'antivirus?Voglio dire ... seguono tutti i reindirizzamenti fino a quando non arrivano su una pagina?
Puoi spiegare perché i vantaggi di "* un collegamento nell'e-mail in cui gli utenti possono segnalare di NON aver creato questo account *" superano i vantaggi della formazione degli utenti ** mai ** a fare clic sui collegamenti nelle e-mail che non eranoaspettando di ricevere?
Se vuoi una garanzia che l'indirizzo e-mail non venga attivato accidentalmente, utilizza una richiesta POST.È buona norma non consentire mai alle richieste GET di modificare lo stato del server.Vedi anche [The Spider of Doom] (https://thedailywtf.com/articles/The_Spider_of_Doom).
@usr-local-ΕΨΗΕΛΩΝ Se gli scanner di collegamenti AV potessero essere fermati da un reindirizzamento, i collegamenti di phishing / malware potrebbero facilmente utilizzare la stessa tattica.
Suona bene.La mia conclusione è che le attivazioni dell'account non dovrebbero essere eseguite tramite HTTP GET.In realtà, questo viola la semantica del verbo HTTP ora che penso
@usr-local-ΕΨΗΕΛΩΝ [Sono d'accordo che HTTP GET sia una cattiva scelta per i comandi operativi] (https://security.stackexchange.com/questions/135513/what-could-an-img-src-xss-do/135548#135548)
I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (https://chat.stackexchange.com/rooms/85421/discussion-on-answer-by-daisetsu-what-should-a-verification-email-consist-of).
#2
+22
Maros D.
2018-11-05 14:06:46 UTC
view on stackexchange narkive permalink

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ò.

Ho effettivamente utilizzato questo metodo sull'ultimo sito Web che ho sviluppato.Per aggiungere a questo, puoi creare un database con tutte le "stringhe casuali" (ovvero: token) che hai generato.In questo modo, puoi garantire che non venga riutilizzato la chiave.MySQL restituisce l'errore 1062, se usi il token come chiave primaria, rendendo semplicissimo verificare se la chiave esiste.
@DavyM Grazie.All'inizio stavo cercando di creare un'aggiunta, ma ci sono entrato e ho creato una risposta utile.Sembra così.
@IsmaelMiguel Sì.Puoi farlo anche se vuoi essere sicuro che la chiave non verrà utilizzata in futuro.Inoltre puoi aggiungere un timestamp in modo che il token possa essere riutilizzato dopo un po 'di tempo (rimuovendo i vecchi token su base mensile).
Sebbene possa sembrare una buona idea, c'è ancora il problema che qualcuno ha il token e può riutilizzarlo.Immagina che un utente stia cercando di trovare l'email con il token, utilizzando l'oggetto.L'utente lo ricorda da un'altra email.E trova un'e-mail di reimpostazione della password casuale con un token.L'utente fa clic su di esso.Dato che hai cancellato i token e ne hai ricreati di nuovi, * potrebbe * accadere, se sei sfortunato, che quel token fosse effettivamente per qualcun altro.E cambiano la password per quel qualcun altro.Ora hanno accesso con un altro account.
@IsmaelMiguel Hai ragione.Non ci ho pensato.
#3
+16
Future Security
2018-11-06 02:07:46 UTC
view on stackexchange narkive permalink

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.

Wow <3 Grazie!Usereste una chiave CD come un token?`2ZRIF-07SWU-ZQVA7-SVSIN-OCFDC` Questo tipo di codice, grande nel mezzo dell'email, ne renderebbe facile capire lo scopo con il link di attivazione sottostante.Questa stringa potrebbe essere generata con crypto.randomBytes () ma la mia preoccupazione è l'alfabeto breve, ma poi di nuovo la stringa se è lunga 25 caratteri in modo da forzare il bruto, dovrebbe richiedere un po 'di tempo con il divieto temporaneo se viene rilevata una forza bruta.Qualche ottimo articolo sul MAC crittografico?: D
@HypeWolf 36 non è così breve;36 ^ 25 è abbastanza grande per me.
@wizzwizz4 True.Forse sono solo paranoico.
@HypeWolf La paranoia e una buona sicurezza non sono necessariamente correlate;stai utilizzando una richiesta GET per attivare un'azione (quando invece dovrebbe portarti a una pagina con un pulsante che invia una richiesta POST per attivare l'azione).
Dici: "I codici di attivazione devono essere memorizzati in una tabella di database".Potrebbe avere senso fare un ulteriore passo avanti e hash?Poiché è una stringa casuale, potresti optare per un salt fisso (altrimenti dovrai ottenerlo dal lato client).
Non sono d'accordo con questa risposta.Stiamo parlando di un codice monouso qui.Tutte le varie minacce di sniffing, lettura di file di registro proxy, ecc. Sono inutili contro di esso.Per un attacco MitM non fa differenza.Non vedo un guadagno in termini di sicurezza rendendo il processo più complicato e non consentendo un semplice GET.
@Tom Altre risposte e commenti hanno sottolineato che un GET potrebbe essere attivato per errore, ad es.da uno scanner di sicurezza.Sono anche d'accordo sul fatto che, in generale, dovremmo scoraggiare gli utenti dal fare clic sui collegamenti nelle e-mail, anche se fino a quando Paypal non farà sembrare i loro annunci autentici meno tentativi di phishing, questa è probabilmente una battaglia persa.
@Thierry Assolutamente.O forse H (fixed-salt, email-address, activation-code).Tuttavia, è probabilmente un rischio basso saltare l'hash del codice.(Lo credo perché ha un utilizzo una tantum, non contiene informazioni private, viene generato dal server e scade.) Le password ovviamente dovrebbero * sicuramente * essere sottoposte ad hashing.
@HypeWolf La dimensione dell'alfabeto non è importante.Solo il numero di codici possibili.Se aggiungi un contatore al tuo profilo / codice di verifica e lo invalidi dopo troppe risposte sbagliate, puoi utilizzare un codice molto, molto più breve.Vorrei persino eliminare le vocali per evitare di scrivere a caso parole vere.Tratta O e 0 come identici, anche I, L e 1.Rimuovi spazi / separatori.ecc. Il numero di possibili codici distinti è l'unico fattore che influisce sulla sicurezza.Tutte le altre decisioni sono domande sull'esperienza dell'utente.
@Tom Hai corretto, nessuna di queste cose fa la differenza.Tuttavia, inserire il codice in un parametro GET invece di inserirlo in un parametro POST.Un GET può essere un falso positivo se non controlli lo stesso cookie di sessione.Tuttavia, qualcuno potrebbe registrarsi sul proprio laptop ma leggere la posta elettronica sul proprio telefono.Oppure il cookie può essere cancellato se chiude il browser dopo la registrazione ma prima della verifica.Oltre a ciò, l'unica differenza di sicurezza è se gli utenti privilegiano o meno il phishing.(Non stiamo parlando di sistemi di reimpostazione della password. È molto diverso.)
@IMSoP potrebbe essere, ma poi qualunque cosa lo abbia attivato è reso sciatto.Dovrebbe usare HEAD o OPTIONS a seconda di ciò che vuole controllare.Ci sono cose da considerare e la principale è che GET dovrebbe essere idempotente ma non lo è in questo caso d'uso.
@HypeWolf Non userei un codice di sicurezza come quello con trattini "-", perché quando provo a fare doppio clic su di esso, viene selezionata solo una parte di esso, piuttosto che il numero intero.
@CharlieHarding In effetti, buona cattura!
Raccomandi i codici di verifica (invece dei link di verifica) anche per le email più importanti di gestione dell'account come la conferma dell'email, la reimpostazione della password, la modifica dell'email, ecc.?
@lonix Sì.Per entrambi i metodi si genera un token casuale.Un link di verifica inserisce quel token nell'URL.Un codice di verifica è un token che l'utente immette in un modulo HTML.L'unico rischio specifico per i codici di verifica a cui riesco a pensare deriva dall'accorciamento del token per comodità dell'utente.Se utilizzi la stessa lunghezza del codice di verifica della lunghezza che avresti utilizzato per i token URL, il metodo del codice di verifica è almeno altrettanto sicuro.
@FutureSecurity Vero, ma in realtà il codice sarà un token molto breve (diciamo 6-9 cifre o giù di lì) mentre il token del link sarà una mostruosa stringa esadecimale.Quindi, in quelle circostanze, saresti sicuramente contrario ai codici (e a favore dei link)?
@lonix Non è necessario che sia così breve per essere utilizzabile.E il codice non deve essere troppo lungo per essere sicuro.Le chiavi brevi e le password brevi sono cattive, ma il token di verifica non è nessuna di queste.Una password breve può essere forzata brutalmente da un lento attacco online.Ma a differenza delle password, i token possono essere invalidati se un client inserisce troppe volte il codice sbagliato.A differenza delle chiavi, un hacker non può in alcun modo determinare se ha ottenuto il codice corretto se non inviandolo al server.
@lonix È possibile codificare in base 32 un numero casuale a 60 bit, ottenendo 12 caratteri.Puoi limitare il gettone a 10 risposte errate.Dovresti inviare milioni di tentativi al secondo se desideri reimpostare la password di qualcun altro entro mille anni.Questo senza alcun limite di velocità o monitoraggio.A seconda del valore della cosa che stai cercando di proteggere, puoi aggiungere o rimuovere personaggi in modo soddisfacente.
@lonix Tecnicamente è possibile eseguire il cracking offline di un token con hash se qualcuno ottiene l'accesso in lettura a un database mentre il server di autenticazione è attivo.(Non fa male eseguire l'hash dei token anche se sono brevi.) Per mitigare parzialmente il problema, il token dovrebbe scadere dopo un po 'di tempo.In assenza di hack, fughe di notizie e attacchi interni non esiste alcun cracking offline di cui un hacker possa trarre vantaggio a meno che il server non faccia qualcosa di strano come inviare l'hash del token ai client, tuttavia.
@FutureSecurity Grazie per i tuoi approfondimenti!Mi hai convinto a usare i codici invece dei link.Darò all'utente 3 possibilità per ottenere il codice corretto, entro 10 minuti, quindi invalidarlo.
#4
+8
user135823
2018-11-06 14:15:12 UTC
view on stackexchange narkive permalink

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.

"Raramente il codice di conferma è diverso da un numero intero, da 5 a 9 cifre."questo porta l'enfasi. Con un codice una tantum che scade tra 30 minuti, 25 caratteri sono eccessivi.Anche 6 caratteri alfanumerici richiedono 600k POST / sec per coprire il 50% in 30 minuti.Limita il servizio di verifica per ritardare di un centesimo di secondo e un avversario può scansionare al massimo lo 0,008% dello spazio delle chiavi, ha una probabilità di 1 su 12.000 supponendo che consuma l'intero servizio di verifica per 30 minuti completi ...
@TemporalWolf hai incluso il fatto che l'avversario può scansionare in parallelo?
@PaŭloEbermann Se riduci il tuo servizio di verifica, questo pone un limite massimo al numero di chiavi che possono scansionare.Si tratta di bilanciare il rischio.Per una banca?Probabilmente no.Per una piccola impresa?Probabilmente.Il punto in cui inizierei a considerare il bumping è quando il numero di nuovi account durante qualsiasi finestra scorrevole supera i 100 circa.Ciò fornisce ancora <1% di possibilità che qualcuno indovini il codice di qualcuno e una probabilità del 100% di rilevare il tentativo (assumendo un monitoraggio).6 caratteri corrispondono a ~ 32 bit di entropia.10 è ~ 52.25 è ~ 130.Puoi controllare la velocità della forza bruta tramite il tuo servizio di verifica.
#5
+2
Damon
2018-11-07 16:40:34 UTC
view on stackexchange narkive permalink

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.
#6
  0
Tom
2018-11-06 20:27:57 UTC
view on stackexchange narkive permalink

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.

"Trovare l'utente tramite un token di stringa risulterà in una scansione della tabella", non se si inserisce un indice nella colonna del token.Un indice di testo può essere leggermente più lento di uno numerico, ma non c'è motivo di fare una scansione della tabella.
Gli indici non sono gratuiti.Metteresti un indice sulla tabella che verrà utilizzato ** una volta ** nella durata di ogni riga?(inoltre, sarà nullo per la maggior parte delle righe. Hm, in realtà potrebbe avere delle buone prestazioni per questo motivo)
Puoi semplicemente avere una tabella separata (con indice) per i token di attivazione invece di metterla nella tabella utente.
Usa una tabella separata per i token di attivazione: `token`,` uid`, `expiry`.Su richiesta HTTP utilizzando un token eseguire `DELETE FROM TokenTable WHERE expiry
D'accordo, @GypsySpellweaver sarebbe una buona soluzione.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...