Per quanto tempo dovrebbe essere un codice di conferma dell'email per evitare la forzatura bruta

Naviga le tue risposte
2

Diciamo che vogliamo che i nuovi utenti confermino il loro indirizzo e-mail su un sito web sicuro (uno che non vogliamo che gli utenti facciano falsi account impersonando altri utenti). Per ragioni UX, possiamo volere:

  • Corto come possibili codici nel caso in cui l'utente lo digiti
  • codici alfanumerici per una facile digitazione
  • Non richiede che l'utente inserisca nuovamente il suo indirizzo email al momento della conferma del codice

Un codice troppo corto è vulnerabile ai tentativi di forza bruta per confermarlo. Ad esempio il codice 1234 potrebbe essere facilmente indovinato. L'utente malintenzionato registra appena [email protected] e poi invia i codici di verifica fino al raggiungimento del target (e potrebbe verificare molte altre email casuali).

C'è una serie di strategie per combattere questo, tra cui:

  • Utilizza un codice lungo che non può essere indovinato, forse costringendo l'utente a fare clic su un link di verifica anziché digitarlo manualmente
  • Scade il codice in tempi relativamente brevi - concedendo meno tempo all'attaccante
  • Forza l'utente a identificare chi dichiara di essere effettuando l'accesso o digitando la sua e-mail prima del codice di conferma. Quindi scade il codice dopo X tentativi. Ciò costringe l'attaccante a dover riavviare costantemente le proprie ipotesi - rimuovendo la possibilità di una ricerca esaustiva. Tuttavia è potenzialmente un papercut UX. Forse un utente fa clic sull'email di conferma su un telefono dopo aver effettuato l'accesso con il proprio desktop. Il telefono richiede l'accesso e costituisce una leggera barriera per registrarsi.
  • Utilizza capcha, limitazione della velocità o altre strategie per scoraggiare l'automazione. Questo probabilmente non è garantito per risolvere il problema da solo.

Ogni strategia può potenzialmente danneggiare la UX. Qual è un ragionevole equilibrio di UX senza compromettere la sicurezza?

    
posta Bufke 16.09.2017 - 16:23
fonte

3 risposte

1

Fornire un URL con un identificatore lungo, l'utente che non deve effettuare il login e un breve codice a 4 cifre, in cui l'utente deve accedere e limitare a 5 tentativi per 24 ore.

E non è che oggi sia difficile ottenere un account e-mail, quindi ha un valore complessivo limitato.

    
risposta data 17.09.2017 - 19:21
fonte
0

Inserisci i parametri necessari come (email dell'utente, tempo di richiesta, ip utente, ...) in un array e aggiungi alcuni dati casuali come seme nell'array. Quindi crittografare l'array con AES-256 e aggiungere l'output all'URL. Ora basta inviare l'URL univoco all'email dell'utente.
Se i dati ricevuti vengono decrittografati correttamente, puoi convalidare l'indirizzo email.

Quindi il tuo codice di identificazione non è vulnerabile a bruteforce. Inoltre puoi aggiungere altri parametri di sicurezza in url e implementare ulteriori controlli di sicurezza.

    
risposta data 16.09.2017 - 20:47
fonte
0

Non penso che avere l'utente che acceda ai propri messaggi di posta elettronica sia sbagliato da una prospettiva UX. Molti siti richiedono all'utente di inserire ENTRAMBI il codice & e-mail, ma resta utilizzabile.

Durante la registrazione, genera un hash sicuro e lo memorizza lungo l'ID univoco dell'utente in un database.

Invia loro un link: "site.example / verify / $ hash". In questa pagina inseriranno semplicemente la loro e-mail, in quanto l'hash non corrisponderà mai a un'altra e-mail. Scade i codici dopo un breve intervallo o se l'account è stato verificato (che viene sempre prima).

In alternativa, potresti non richiedere quasi nessuna interazione da parte dell'utente, se lo desideri, questo potrebbe essere ottenuto inviandoli: "site.example / verify / $ hash / $ mail" che potrebbe riempire automaticamente il campo dell'e-mail.

Per aggiungere questo, probabilmente stai meglio usando anche un captcha / rate limit. Anche se un bot non può mai indovinare l'hash (si spera che tu scelga un algo sicuro), potrebbe causare l'applicazione DOS sovraccaricando il database con le richieste.

    
risposta data 21.09.2017 - 20:17
fonte

Leggi altre domande sui tag

Questo sito Web afferma che password + cookie conta come 2FA Flusso di lavoro di protezione JWT e CSRF