Ho visto app Web con limitazioni per i tentativi di accesso utente.Limitazione dei tentativi di accesso utente in PHP
È una necessità di sicurezza e, in tal caso, perché?
Ad esempio: si sono verificati tre tentativi di accesso non riusciti, riproviamo tra 10 minuti !!
ChiarimentoQuesto è un completamento alle altre risposte. Ad esempio, un captcha ben implementato insieme a un meccanismo anti-bruteforce che usa le sessioni.
L'interrogante ha contrassegnato questo come accettato assumendo che i captcha siano illeggibili dalle macchine (lei è quasi a destra) e quindi riceve punti negativi, perché la gente pensa che non sia una risposta completa & hanno ragione.
anche utilizzando un buon CAPTCHA implementato potrebbe essere un modo alternativo per ENPOWER vostra sicurezza delle applicazioni contro gli attacchi di forza bruta. c'è un wide variety of captcha providers disponibile gratuitamente, proviamo nel modo più semplice se sei di fretta. Si prega inoltre di considerare che c'è people fuori da qui dicendo che "oh, no! Questa cosa del captcha non è abbastanza sicura e hanno ragione a volte!".
"Per quelli di voi che non conoscono, un CAPTCHA è programma che può dire se il suo utente è un essere umano o un altro computer. Sono quelle piccole immagini di testo distorto che si traducono quando ti iscrivi per Gmail o lasciare un commento sul blog di qualcuno. Il loro scopo è quello di assicurarsi che qualcuno non usi un computer per registrarsi automaticamente per milioni di account online, o .. "ref.
La limitazione del numero di tentativi da effettuare su un sito Web è di impedire attacchi di forza bruta (automatici) al sito. Se non si limitano questi tentativi, un hacker può impostare uno script per continuare a indovinare le password finché non ne trova una, e questo potrebbe influire sulla disponibilità del proprio server web.
In genere, è possibile sospendere l'utente (10 minuti come indicato) dopo 3 tentativi e bloccarli dopo 6 o 9 tentativi ripetuti consecutivi, costringendo l'utente a contattarsi per sbloccare il proprio account. Questo viene messo in atto perché qualcuno può modificare i propri script per regolare il timeout.
quindi devo implementare il codice quando le credenziali dell'utente non sono riuscite e non è necessario quando un indirizzo email (per esempio) ha un formato non valido. vero? ed è giusto implementarlo con i cookie o devo farlo usando dbs? grazie per la tua risposta :) –
a seconda di quanto sicuro vuoi il tuo sito. Il modo migliore per determinare che cosa è necessario fare è registrare ogni tentativo ... ogni volta che un utente effettua l'accesso, tiene traccia di e-mail, nome utente, indirizzo IP e se la loro password è corretta o meno. –
(continua ..) Fare attenzione a non registrare la password effettiva digitata. quindi se vedi una tendenza, cambia il tuo codice per renderlo conto. Non considererei un errore di battitura contro l'utente, a meno che le persone non inizino ad abusarne. –
Sì, è necessario proteggere gli account da sofisticati attacchi di forza bruta - come in, utilizzando bot e dizionari - a qualcuno che sta solo cercando di indovinare la password dell'account.
Se gli utenti possono impostare le proprie password, alcuni bot/kid tenteranno di accedere con un elenco di password comuni e avranno esito positivo. E se non conoscono nessun utente, proveranno nomi comuni come admin, simon, rico, ecc.
Non aiuta a segnalare semplicemente l'utente in sessione, in quanto possono semplicemente rimuovere il cookie o la query param sulla loro fine. È necessario disporre di un conteggio dei tentativi di accesso non riusciti per il nome di accesso e IP. Forse essere più indulgente per l'IP in quanto può essere condiviso tra molti utenti.
Per i miei progetti ho scritto una libreria generalizzata "floodcontrol" che gestisce questo tipo di cose.
Mi consente di specificare quanti tentativi possono essere effettuati in X quantità di tempo.Permette un certo numero di tentativi di "grazia" in un breve periodo, in modo da catturare solo comportamenti davvero insoliti.
I record nel database un paio di cose:
Per ogni tentativo fatto interrogo contro l'IP parziale aggiungere ress e l'azione, e se è stato effettuato un tentativo precedente entro una certa finestra di tempo, incrementare il contatore dei tentativi per quel tentativo. Se il contatore dei tentativi supera il numero di tentativi di grazia consentiti, controllo se l'ultimo tentativo è avvenuto entro X secondi e, in questo caso, restituisce false, pertanto l'azione verrà bloccata (e all'utente verrà detto di attendere X secondi prima di provare ancora). Se il contatore dei tentativi è inferiore al numero di tentativi di grazia, restituisco true e lo faccio scorrere.
Se una persona con lo stesso IP arriva più tardi, il conteggio del tentativo precedente non verrà recuperato, perché sarà troppo tempo fa.
Fare attenzione alle persone che utilizzano lo stesso indirizzo IP su una rete. Se 10 persone si trovavano in un appartamento con un IP esterno e avessero tentato di effettuare ricerche sul tuo sito, tutte sarebbero state bloccate immediatamente. –
Buon punto. Il numero di accessi alla grazia dovrebbe essere sufficientemente elevato da consentire alle persone di essere interessate dalla normale attività di registrazione dovrebbe essere molto bassa. Ad esempio, se 20 persone provenienti da indirizzi IP simili si collegano tutti entro un periodo di pochi minuti, potrebbero attivarsi se gli accessi alla grazia sono <20. – thomasrutter
In altre parole, l'aumento della tolleranza sarebbe l'unica opzione; L'indirizzo IP non è affidabile nell'identificazione di persone uniche, ma su Internet è quasi l'unico identificativo che hai - puoi anche prendere in considerazione la stringa user-agent. – thomasrutter
ho visto un approccio creativo a questa volta ...
Per ogni tentativo di accesso, che non riesce, il tempo di blocco aumenta in modo esponenziale ....
attempt | lockout time
======================
1 | 2s
2 | 4s
3 | 8s
4 | 16s
5 | 32s
6 | 64s
7 | 128s
8 | 256s
9 | 512s
10 | 1024s
In teoria, consente all'utente commette un errore o due, ma non appena sembra diventare un tentativo di "hacking", l'hacker viene bloccato per periodi di tempo sempre più lunghi.
Non l'ho ancora usato (ancora), ma concettualmente mi piace molto l'idea. Naturalmente al login riuscito, il contatore viene resettato.
Ho implementato qualcosa di simile prima, ma ho scoperto che non era abbastanza indulgente; a volte le persone dimenticano sinceramente la loro password e devono provare diverse combinazioni - magari provare qualcosa del genere ma assicurati che i primi 6 siano tutti 0, quindi inizi a salire, superficialmente. – thomasrutter
sì, funzionerebbe anche bene. L'idea è solo quella di limitare qualsiasi tentativo "casuale" di accesso all'hacking. I sistemi seri dovrebbero prendere in considerazione i segni di un attacco di dizionario, botnet, multipli IP ecc. – scunliffe
@ Marco Accetto e capisco ... quindi i tempi di blocco devono iniziare in piccolo, e diventare più grandi in seguito ... armeggiare 3 o 4 i tempi dovrebbero essere ok ... ma 6 o più di solito indicano un tentativo di hacking. Le volte che ho postato erano solo casuali ... mi adeguerei in base alle tue esigenze (se dovessi usare questa logica) ad es. Abiliterei anche un collegamento o mostrerò un numero di telefono dove un utente può chiamare e ottenere il reset del contatore se necessario. – scunliffe
Suppongo che mettere un contatore "tentativi falliti" nel DB sia la via più sicura e facile da percorrere. In questo modo l'utente non può aggirarlo (disabilitando i cookie). Reset su login di successo, ovviamente.
In che modo un utente non è in grado di aggirarlo e in che modo distinguerebbe due utenti? – thomasrutter
indirizzo IP, naturalmente. Sì, questo potrebbe causare problemi a più utenti con lo stesso IP ... ma se mostri semplicemente un CAPTCHA o qualcosa del genere quando hanno esaurito i loro tentativi, non penso che sia una grande perdita. Questo ha davvero giustificato un voto negativo? – mpen
Si può sempre contare anche con il nome utente. In modo che sia il nome utente + Indirizzo IP segregato, piuttosto che solo l'indirizzo IP. Ciò significherebbe che un IP condiviso non causerebbe problemi a meno che le persone cercassero lo stesso account. Ovviamente, ciò consentirebbe alle reti di bot distribuite di regnare liberamente, quindi perché non uccidere completamente l'indirizzo IP? – RonLugge
Reimpostare i tentativi falliti dopo un login corretto rende quasi inutile l'intero sistema.
Qualsiasi utente registrato può quindi fare tre tentativi sull'account e sulla password di qualcun altro, quindi accedere con il proprio per reimpostare il contatore e ripetere - anche questo può essere automatizzato. Ad esempio, un utente normale registrato può utilizzare password di amministrazione brute force.
Il ripristino deve essere eseguito dall'amministratore, non semplicemente effettuando il login correttamente.
Non se i tentativi di accesso non riusciti vengono conteggiati rispetto all'account utente specifico a cui qualcuno sta tentando di accedere. – Ren
Avere un unico contatore centrale per accessi non riusciti, come suggerisce la tua risposta, implicherebbe anche che se ti perdi tre ipotesi allora dovrei aspettare un po 'per tentare il mio primo accesso: / – Flygenring
@artarad: Sarei molto seccato se avessi un captcha ogni volta che ho provato ad accedere. Non penso che dovrebbe essere visualizzato fino a quando falliscono come 3 volte, e quindi forse dare loro altri 3 circa tentativi prima di bloccarli per un periodo di volte. I captcha non sono infrangibili dalle macchine ... solo più difficili. Penso che il mio professore abbia incrinato oltre il 90% di em con la sua sceneggiatura. – mpen