Reimpostazione automatica della password - è una buona idea?

Probabilmente non è una buona idea, perché se volessi impedire a Bob di effettuare il login, potrei continuare a inviare richieste di accesso automatico per l'utente [email protected] al tuo servizio con qualsiasi PIN.

Inoltre, l'invio di password / PIN via e-mail non è raccomandato perché la posta in arrivo di un utente non è un percorso sicuro per la memorizzazione di queste informazioni sensibili.

È più sicuro nel senso che su ogni 20 indovina viene generato un nuovo PIN, il che significa che l'hacker ha sempre solo una possibilità di 20 / 1.000.000 (1 / 50.000) di indovinare correttamente.

Un'alternativa che evita il problema del DoS è che potresti introdurre la verifica della posta per gli accessi che hanno più di 10 login falliti nell'ultima settimana circa. per esempio. quando inseriscono la combinazione di nome utente e PIN corretta, viene inviata un'e-mail al proprio account registrato contenente un collegamento con una stringa casuale. L'utente deve fare clic sul link e-mail per completare l'accesso al sistema.

Anche se il dispositivo con la restrizione hardware non può visualizzare l'e-mail, un altro dispositivo che può anche inserire il PIN ma ricevere l'e-mail potrebbe "garantire" in questo modo.

Come note di ilkkachu , sarebbe saggio valutare i tentativi di accesso limitati con lo stesso nome utente. Tuttavia, poiché il numero di possibili PIN è 1.000.000, anche con un ritardo medio di 20 secondi, un utente malintenzionato potrebbe ottenere l'accesso dopo circa 17 settimane di tentativi di accesso costanti. Pertanto, aggiungerei 2FA per proteggere gli account o implementare la verifica della posta elettronica degli accessi sospetti in combinazione con la limitazione della velocità.

Non c'è alcun problema con questo, ma una soluzione migliore nel tuo caso è usare un "PIN hardware" casuale usato solo quando comunichi con lo "stupido hardware", che è memorizzato all'interno dell'account, possibilmente crittografato con un hash dell'utente parola d'ordine. (e per verificare la password all'accesso, utilizzare hash (hash ()) della password). In questo modo è possibile utilizzare una normale password per il front-end Web e quindi non è necessario imporre limiti di prova complessi. (invece puoi applicare un limite di prova temporizzato)

Direi che è una buona idea. Se riesci a crearlo in modo che se ci sia un certo numero consecutivo di tentativi PIN sbagliati, dato che la forza bruta avrà MOLTO sbagliato all'inizio, puoi codificarlo in modo che il tuo script lo noti e invierà solo uno email. Ciò consente ai server di gestire troppe e-mail non necessarie. Vorrei anche implementare l'IP che l'utente sta provando a forzare, se è possibile identificare avrà le connessioni in entrata bloccate, quindi non riesce a connettersi affatto. Se puoi farlo, direi che è un metodo davvero valido.

Un'altra cosa che dovresti cercare è se l'utente prova a usare la forza bruta, diciamo, sapeva che questa funzione era implementata nel tuo sistema PIN, quindi poteva, più o meno eseguire un attacco MITM e, si spera, afferrare l'e-mail prima che raggiunga il destinatario specificato. Quindi, copri tutti i tuoi obiettivi e assicurati che la tua rete stia comunicando con SSL crittografato, usando cose come TCPCrypt, ecc.

Oh, e le persone di solito non devono reinserire la propria password 20 volte, direi 10. Ma, dipende da te, puoi mettere qualsiasi cosa per quello.

Per uno, suppongo che il sistema che state pianificando sia per un caso d'uso limitato, poiché non penso che sia impossibile chiedere un po 'di più alle password in uso generale: anche Stackexchange richiede otto caratteri con numeri.

In un certo senso, un milione di possibili codici è molto piccolo e abbastanza grande. Se un utente malintenzionato ottiene il database delle password e può tentare di rompere gli hash off-line, verranno eliminati in un istante. Anche se l'hashing fosse abbastanza lento da consentire solo il test di dieci codici al secondo, l'intero spazio delle chiavi passerebbe tra un po 'più di un giorno. Non sarà così lento.

D'altra parte, dal momento che è possibile limitare i tentativi di accesso on-line, dovrebbe essere abbastanza controllabile. Per ottenere solo un 1% di indovinare un passcode, l'attacker avrebbe bisogno di 10000 tentativi. Questo non dovrebbe essere normale, specialmente da un IP di origine singola o da un singolo account, e dovresti bloccare l'origine in quel punto e prendere in considerazione la possibilità di bloccare l'account. (Se hai molti utenti e sei attaccato da una botnet, è più difficile da rilevare.)

Anche se con i codici numerici, devi renderli casuali, invece di lasciare che l'utente decida. Altrimenti sceglieranno semplicemente le date, rendendo lo spazio delle chiavi efficace più piccolo. Hai già toccato questo quando pianifichi un reset casuale, ma deve essere casuale per cominciare, altrimenti scoprire i compleanni delle persone sarà troppo redditizio.

Per quanto riguarda la modifica automatica del PIN, diamine no. Oltre allo spam che altri hanno menzionato, potrebbe anche bloccare l'utente legittimo se non è in grado di accedere alla loro e-mail solo al momento giusto. E se fai no limitando il tasso, non avranno il tempo di leggere la loro e-mail prima che l'hacker abbia sfornato altri 20 tentativi, e il codice cambia di nuovo ... Poi di nuovo, se do che limita il tasso, puoi semplicemente bloccare l'account di proposito per un po '.

Ovviamente, il blocco degli account è un vettore DoS, ma è un compromesso che devi scegliere. Vuoi dare la priorità ai furti con i cattivi o assicurarti che i bravi ragazzi entrino?

Il cambio automatico renderebbe il codice più difficile da indovinare? Bene, sì, marginalmente. Per un passcode invariato, avresti K in N possibilità di indovinarlo, quando fai K indovina contro N possibili codici. Per un codice che cambia, la possibilità di indovinarlo è una costante 1 / N per ogni ipotesi, o 1- (1-1 / N) ^ K per le ipotesi di K. Funziona a circa 500000 vs 700000 per una probabilità del 50% di farlo bene. È più, ma nella stessa scala. Vuoi consentire quei centomila tentativi di accesso in primo luogo?

Sarebbe un'idea molto simile inviare una e-mail di "reset PIN" all'utente quando preme "Ho dimenticato il mio PIN" sul sito web, ma invece di inviarne uno casuale, magari dare all'utente un'opzione per impostare proprio? Questo è il metodo standard. È possibile bloccare l'account lì dopo che X tenta di forzare l'utilizzo dell'opzione di ripristino del PIN.