Modo corretto per documentare e registrare gli attacchi di forza bruta durante la creazione di un account utente

0

Abbiamo il seguente caso d'uso:

Gli utenti possono registrarsi automaticamente per un account aziendale compilando un modulo di convalida con il proprio ID, nome, cognome e DOB. L'ID è qualcosa che solo l'utente conosce in anticipo. Gli utenti hanno 5 tentativi per abbinare tutte le loro informazioni.

Stiamo pianificando di mantenere un paio di tabelle in un database in cui archiviamo i tentativi di convalida:

Table 1 columns: id, attempts
Table 2 columns: id, fname, lname, dob

Le tabelle 1 e 2 hanno una relazione uno-molti. Ecco un esempio di cosa succede se l'utente prova a indovinare il nome, il cognome e il DOB 5 volte prima di essere bloccato. L'applicazione controlla la colonna dei tentativi della tabella 1 e se è 5 o più di 5 per un ID specifico, l'account utente (con quell'ID specifico) viene considerato bloccato.

table 1
id   attempts
1234  5

table 2
id    fname   lname  dob
1234  john     doe   19900101
1234  jane     doe   19900101
1234  jason    doe   19900101
1234  john     dae   20010102
1234  roger    smith 19960101

Il problema con l'approccio sopra è che stiamo monitorando solo i tentativi falliti per ID. Cosa succede se l'utente tenta di modificare l'ID e attaccare? Mantenendo il nome, il cognome e il DOB lo stesso e indovinando l'ID?

Forse ho bisogno di riconsiderare la progettazione della tabella di convalida e il mio approccio per risolvere il problema dell'utente che cerca di indovinare l'ID? O c'è un modo migliore per pensare a questo problema?

    
posta user6123723 12.07.2016 - 00:20
fonte

0 risposte

Leggi altre domande sui tag