Qual è la migliore contromisura di Forza Bruta Distribuita?

StackOverflow https://stackoverflow.com/questions/479233

Domanda

Innanzitutto, un po’ di background:Non è un segreto che sto implementando un sistema di autenticazione+autenticazione per CodeIgniter e finora sto vincendo (per così dire).Ma mi sono imbattuto in una sfida piuttosto non banale (una che la maggior parte delle librerie di autenticazione manca del tutto, ma insisto per gestirla correttamente):come affrontarlo in modo intelligente attacchi di forza bruta su larga scala, distribuiti e con nome utente variabile.

Conosco tutti i soliti trucchi:

  1. Limitazione del numero di tentativi falliti per IP/host e negare l'accesso ai trasgressori (ad es.Fail2Ban) - che non funziona più da quando le botnet sono diventate più intelligenti
  2. Combinando quanto sopra con a lista nera di IP/host noti "cattivi". (per esempio.DenyHosts) - che si basa sulle botnet che rientrano al primo posto, cosa che sempre più spesso non fanno
  3. Whitelist IP/host combinato con l'autenticazione tradizionale (purtroppo inutile con gli utenti IP dinamici e l'alto tasso di abbandono sulla maggior parte dei siti web)
  4. Impostazione a limite a livello di sito sul numero di tentativi falliti entro un periodo di N minuti/ore e limitando (sospendendo) tutti i tentativi di accesso successivi per un numero di minuti/ore (con il problema che un attacco DoS diventa un gioco da ragazzi per la botnet)
  5. Obbligatorio firme digitali (certificati a chiave pubblica) o token hardware RSA per tutti gli utenti senza opzione login/password (senza dubbio una soluzione solida, ma pratica solo per servizi chiusi e dedicati)
  6. Forzata schemi di password ultra-resistenti (per esempio.>25 caratteri senza senso con simboli - ancora una volta, troppo poco pratici per gli utenti occasionali)
  7. E infine, CAPTCHA (che potrebbero funzionare nella maggior parte dei casi, ma sono fastidiosi per gli utenti e praticamente inutile contro a attaccante determinato e intraprendente)

Ora, queste sono solo le idee teoricamente realizzabili.Ci sono abbondanza di idee spazzatura che fanno impazzire il sito (ad es.a banali attacchi DoS).Quello che voglio è qualcosa di meglio.E per meglio intendo:

  • Deve essere sicuro (+) contro DoS e attacchi di forza bruta e non introdurre nuove vulnerabilità che potrebbero consentire a un bot leggermente più subdolo di continuare a operare sotto il radar

  • Deve essere automatizzato.Se richiede un operatore umano per verificare ogni accesso o monitorare attività sospette, non funzionerà in uno scenario reale

  • Deve essere fattibile per l'uso tradizionale del web (es.tasso di abbandono elevato, volume elevato e registrazione aperta che può essere eseguita da non programmatori)

  • Non può ostacolare l'esperienza dell'utente al punto in cui gli utenti occasionali si annoieranno o si sentiranno frustrati (e potenzialmente abbandoneranno il sito)

  • Non può coinvolgere i gattini, a meno che non lo siano davvero davvero sicuro gattini

(+) Per "sicuro" intendo sicuro almeno quanto la capacità di un utente paranoico di mantenere segreta la propria password

Quindi, sentiamolo! Come lo faresti?Conosci una best practice che non ho menzionato (oh, per favore, dimmi di sì)?Ammetto che ho un'idea tutta mia (combinando le idee 3 e 4), ma lascio parlare i veri esperti prima di mettermi in imbarazzo ;-)

È stato utile?

Soluzione

Va bene, abbastanza stallo; ecco cosa ho escogitato finora

(scusa, post lungo avanti. Sii coraggioso, amico, ne varrà la pena)

Combinando i metodi 3 e 4 dal post originale in una specie di whitelist dinamica o sfocata, e quindi - ed ecco il trucco - non bloccare IP non autorizzati, limitandoli a inferno e ritorno .

  

Nota che questa misura è solo intesa a contrastare questo specifico tipo di attacco. In pratica, ovviamente, funzionerebbe in combinazione con altri approcci di best practice per l'authoring: limitazione del nome utente fisso, limitazione per-IP, politica di password complessa con codice, accesso con cookie non limitato, hashing di tutti gli equivalenti di password prima di salvarli, mai utilizzando domande di sicurezza, ecc.

Ipotesi sullo scenario di attacco

Se un utente malintenzionato prende di mira nomi utente variabili, il nostro nome utente con limitazione non si attiva. Se l'attaccante sta utilizzando una botnet o ha accesso a un ampio intervallo IP, la nostra limitazione IP è impotente. Se l'attaccante ha pre-cancellato il nostro elenco di utenti (di solito possibile sui servizi Web a registrazione aperta), non possiamo rilevare un attacco in corso in base al numero di errori "utente non trovato". E se imponiamo una limitazione restrittiva a livello di sistema (tutti i nomi utente, tutti gli IP), qualsiasi attacco di questo tipo farà il nostro intero sito per la durata dell'attacco più il periodo di limitazione.

Quindi dobbiamo fare qualcos'altro.

La prima parte della contromisura: whitelisting

Ciò di cui possiamo essere abbastanza sicuri è che l'attaccante non è in grado di rilevare e falsificare dinamicamente gli indirizzi IP di diverse migliaia di nostri utenti (+). Ciò rende fattibile la whitelisting . In altre parole: per ogni utente, memorizziamo un elenco degli IP (con hash) da cui l'utente ha precedentemente (recentemente) effettuato l'accesso.

Pertanto, il nostro schema di whitelisting funzionerà come una "porta d'ingresso" bloccata, in cui un utente deve essere collegato da uno dei suoi "buoni" IP riconosciuti per effettuare l'accesso. Un attacco di forza bruta a questa "porta d'ingresso" sarebbe praticamente impossibile (+).

(+) a meno che l'attaccante "possieda" il server, tutte le caselle dei nostri utenti o la connessione stessa - e in quei casi, non abbiamo più un problema di "autenticazione", abbiamo un vero franchising situazione FUBAR staccabile

La seconda parte della contromisura: limitazione del sistema di IP non riconosciuti

Al fine di far funzionare una whitelist per un servizio Web a registrazione aperta, in cui gli utenti cambiano computer frequentemente e / o si connettono da indirizzi IP dinamici, dobbiamo tenere aperta una 'porta di gatto' per gli utenti che si connettono da IP non riconosciuti. Il trucco è progettare quella porta in modo che le botnet rimangano bloccate e che gli utenti legittimi vengano infastiditi il meno possibile .

Nel mio schema, ciò si ottiene impostando un molto numero massimo restrittivo di tentativi di accesso non riusciti da parte di IP non approvati su, per esempio, un periodo di 3 ore (potrebbe essere più saggio usare un più breve o periodo più lungo a seconda del tipo di servizio) e rendendo tale limitazione globale , vale a dire. per tutti gli account utente.

Anche una forza bruta lenta (1-2 minuti tra i tentativi) verrebbe rilevata e contrastata rapidamente ed efficacemente usando questo metodo. Ovviamente, una forza bruta davvero lenta potrebbe rimanere inosservata, ma velocità troppo lente vanificano lo scopo dell'attacco della forza bruta.

Quello che spero di ottenere con questo meccanismo di limitazione è che se viene raggiunto il limite massimo, la nostra "porta per gatti" sbatte per un po ', ma la nostra porta d'ingresso rimane aperta agli utenti legittimi che si collegano con i soliti mezzi:

  • O connettendosi da uno dei loro IP riconosciuti
  • O utilizzando un cookie di accesso persistente (da qualsiasi luogo)

Gli unici utenti legittimi che sarebbero interessati durante un attacco, ad es. while la limitazione è stata attivata - sarebbero utenti senza cookie di accesso persistenti che accedevano da una posizione sconosciuta o con un IP dinamico. Tali utenti non sarebbero in grado di accedere fino a quando il throttling non si esaurisce (il che potrebbe richiedere del tempo, se l'attaccante ha mantenuto la sua botnet in esecuzione nonostante il throttling).

Per consentire a questo piccolo sottoinsieme di utenti di spremere attraverso la porta per gatti altrimenti sigillata, anche se i robot lo stavano ancora martellando, avrei impiegato un modulo di login di 'backup' con un CAPTCHA. In modo che, quando visualizzi il & Quot; Siamo spiacenti, ma non puoi accedere da questo indirizzo IP al momento & Quot; messaggio, includi un link che dice " login di backup sicuro - SOLO UMANI ( robot: nessuna menzogna ) " ;. Scherzo a parte, quando fanno clic su quel link, danno loro un modulo di accesso autenticato da reCAPTCHA che elude la limitazione a livello di sito. In questo modo, SE sono umani E conoscono il login + password corretti (e sono in grado di leggere i CAPTCHA), non verranno mai negati al servizio, anche se si stanno connettendo da un host sconosciuto e non stanno usando cookie di accesso automatico.

Oh, e solo per chiarire: poiché considero i CAPTCHA generalmente malvagi, l'opzione di accesso "backup" apparirebbe solo mentre la limitazione era attiva .

Non si può negare che un attacco prolungato del genere costituirebbe comunque una forma di attacco DoS, ma con il sistema descritto in atto, ciò influirebbe solo su quello che sospetto sia un piccolo sottoinsieme di utenti, vale a dire le persone che non " t usa " ricordami " i cookie AND accedono mentre si sta verificando un attacco E non accedono da nessuno dei loro normali IP E che non sono in grado di leggere i CAPTCHA. Solo coloro che possono dire di no a TUTTI quei criteri - in particolare i robot e le persone disabili davvero sfortunate - saranno respinti durante un attacco bot.

  

EDIT: In realtà, ho pensato a un modo per far passare anche gli utenti sfidati a CAPTCHA durante un 'blocco': invece di, o come un supplemento al login CAPTCHA di backup, fornisce all'utente la possibilità di avere un codice di blocco monouso specifico dell'utente inviato alla sua e-mail, che può quindi utilizzare per bypassare la limitazione. Questo supera definitivamente la mia soglia del "fastidio", ma poiché è usato solo come ultima risorsa per un piccolo sottoinsieme di utenti e poiché batte ancora essere bloccato fuori dal tuo account, sarebbe accettabile.

(Inoltre, tieni presente che nessuno di questo accade se l'attacco è meno sofisticato della cattiva versione distribuita che ho descritto qui. Se l'attacco proviene da pochi IP o colpisce solo alcuni nomi utente, sarà contrastato molto prima e con no conseguenze a livello di sito)

Quindi, questa è la contromisura che implementerò nella mia libreria di autenticazione, una volta che sono convinto che sia corretto e che non ci sia una soluzione molto più semplice che mi è sfuggita. Il fatto è che ci sono così tanti modi sottili di fare cose sbagliate in termini di sicurezza, e non sto esagerando nel fare false assunzioni o logiche irrimediabilmente imperfette. Quindi, per favore, qualsiasi feedback, critica e miglioramento, sottigliezze ecc. Sono molto apprezzati.

Altri suggerimenti

Alcuni semplici passaggi:

Aggiungi alla lista nera alcuni nomi utente comuni e usali come honeypot. Amministratore, ospite, ecc ... Non permettere a nessuno di creare account con questi nomi, quindi se qualcuno prova ad accedere, sai che è qualcuno che fa qualcosa che non dovrebbe.

Assicurati che chiunque abbia un vero potere sul sito abbia una password sicura. Richiedi agli amministratori / moderatori di disporre di password più lunghe con un mix di lettere, numeri e simboli. Rifiuta password banalmente semplici da utenti regolari con una spiegazione.

Una delle cose più semplici che puoi fare è dire alle persone quando qualcuno ha provato ad accedere al proprio account e dare loro un link per segnalare l'incidente se non fosse loro. Un semplice messaggio quando accedono come & Quot; Qualcuno ha provato ad accedere al tuo account alle 4:20 di mercoledì blah blah. Clicca qui se non eri tu. & Quot; Ti consente di mantenere alcune statistiche sugli attacchi. Puoi intensificare il monitoraggio e le misure di sicurezza se noti che c'è un improvviso aumento degli accessi fraudolenti.

Se capisco correttamente il MO degli attacchi di forza bruta, uno o più nomi utente vengono provati continuamente.

Ci sono due suggerimenti che non credo di aver ancora visto qui:

  • Ho sempre pensato che la pratica standard prevedesse un breve ritardo (circa un secondo) dopo ogni accesso errato per ogni utente. Questo dissuade la forza bruta, ma non so per quanto tempo un ritardo di un secondo manterrebbe a bada un attacco da dizionario. (dizionario di 10.000 parole == 10.000 secondi == circa 3 ore. Hmm. Non abbastanza buono.)
  • invece di un rallentamento a livello di sito, perché non una limitazione del nome utente. L'acceleratore diventa sempre più duro con ogni tentativo sbagliato (fino a un limite, immagino che il vero utente possa ancora accedere)

Modifica : In risposta ai commenti su una limitazione del nome utente: si tratta di una limitazione specifica per il nome utente, indipendentemente dalla fonte dell'attacco.

Se il nome utente è limitato, verrà catturato anche un attacco coordinato del nome utente (multi IP, singola ipotesi per IP, stesso nome utente). I singoli nomi utente sono protetti dall'acceleratore, anche se gli attaccanti sono liberi di provare un altro utente / passaggio durante il timeout.

Dal punto di vista degli aggressori, durante il timeout potresti essere in grado di provare a indovinare per la prima volta 100 password e scoprire rapidamente una password errata per account. Potresti essere in grado di fare solo ipotesi di 50 secondi per lo stesso periodo di tempo.

Dal punto di vista dell'account utente, ci vuole ancora lo stesso numero medio di ipotesi per violare la password, anche se le ipotesi provengono da più fonti.

Per gli attaccanti, nella migliore delle ipotesi, sarà lo stesso sforzo di spezzare 100 account come farebbe con 1 account, ma poiché non stai strozzando su una base ampia del sito, puoi accelerare abbastanza rapidamente.

Ulteriori perfezionamenti:

  • rileva IP che stanno indovinando più account - 408 Timeout richiesta
  • rileva IP che stanno indovinando lo stesso account - 408 Timeout richiesta dopo un numero elevato (diciamo 100) di ipotesi.

Idee per l'interfaccia utente (potrebbe non essere adatto in questo contesto), che può anche perfezionare quanto sopra:

  • se hai il controllo dell'impostazione della password, mostra all'utente quanto è forte la loro password li incoraggia a sceglierne una migliore.
  • se hai il controllo della pagina di accesso, dopo un piccolo (diciamo 10) numero di ipotesi di un singolo nome utente, offri un CAPTCHA.

Ci sono tre fattori di autenticazione:

  1. Un utente conosce qualcosa (ad esempio, una password)
  2. Un utente ha qualcosa (ad esempio, un portachiavi)
  3. Un utente È qualcosa (ad esempio, scansione della retina)

Di solito, i siti web applicano solo la politica n. 1.Anche la maggior parte delle banche applica solo la politica 1.Si affidano invece a un approccio "conosce qualcos'altro" per l'autenticazione a due fattori.(CIOÈ:Un utente conosce la propria password e il nome da nubile della madre.) Se sei in grado, un modo per aggiungere un secondo fattore di autenticazione non è troppo difficile.

Se riesci a generare circa 256 caratteri di casualità, potresti strutturarli in una tabella 16×16 e quindi chiedere all'utente di fornirti il ​​valore nella tabella della cella A-14, ad esempio.Quando un utente si registra o modifica la propria password, dagli la tabella e digli di stamparla e salvarla.

La difficoltà con questo approccio è che quando un utente dimentica la propria password, come succederà, non puoi semplicemente offrire lo standard "rispondi a questa domanda e inserisci una nuova password", poiché anche questo è vulnerabile alla forza bruta.Inoltre, non puoi reimpostarlo e inviarne uno nuovo via email, poiché anche la loro email potrebbe essere compromessa.(Vedere:Makeuseof.com e il loro dominio rubato.)

Un'altra idea (che coinvolge i gattini) è quella che BOA chiama SiteKey (credo che abbiano registrato il nome).In breve, chiedi all'utente di caricare un'immagine quando si registra e, quando tenta di accedere, chiedigli di scegliere la sua immagine tra 8 o 15 (o più) casuali.Quindi, se un utente carica una foto del proprio gattino, in teoria solo lui sa esattamente quale foto è la sua tra tutti gli altri gattini (o fiori o altro).L’unica vera vulnerabilità di questo approccio è l’attacco man-in-the-middle.

Un'altra idea (niente gattini però), è quella di tenere traccia degli IP con cui gli utenti accedono al sistema e richiedere loro di eseguire un'autenticazione aggiuntiva (captcha, scegli un gattino, scegli una chiave da questa tabella) quando accedono da un indirizzo che non hanno non prima.Inoltre, in modo simile a GMail, consente all'utente di visualizzare da dove ha effettuato l'accesso di recente.

Modifica, nuova idea:

Un altro modo per convalidare i tentativi di accesso è verificare se l'utente proviene o meno dalla tua pagina di accesso.Non puoi controllare i referrer, poiché possono essere facilmente falsificati.Ciò di cui hai bisogno è impostare una chiave nella _SESSION var quando l'utente visualizza la pagina di accesso, quindi verificare che la chiave esista quando invia le informazioni di accesso.Se il bot non invia dalla pagina di accesso, non sarà in grado di accedere.Puoi anche facilitare questo coinvolgimento coinvolgendo JavaScript nel processo, utilizzandolo per impostare un cookie o aggiungendo alcune informazioni al modulo dopo che è stato caricato.Oppure puoi dividere il modulo in due diversi invii (ovvero, l'utente inserisce il proprio nome utente, invia, quindi in una nuova pagina inserisce la propria password e invia nuovamente).

La chiave, in questo caso, è l’aspetto più importante.Un metodo comune per generarli è una combinazione dei dati dell'utente, del suo IP e dell'ora in cui è stato inviato.

Devo chiederti se hai fatto un'analisi costi-benefici di questo problema; sembra che tu stia cercando di proteggerti da un utente malintenzionato che ha una presenza Web sufficiente per indovinare un numero di password, inviando forse 3-5 richieste per IP (dal momento che hai eliminato la limitazione dell'IP). Quanto (approssimativamente) costerebbe quel tipo di attacco? È più costoso del valore degli account che stai cercando di proteggere? Quante gigantesche botnet vogliono ciò che hai?

La risposta potrebbe essere no - ma se lo è, spero che tu stia ricevendo aiuto da un professionista della sicurezza di qualche tipo; le capacità di programmazione (e il punteggio StackOverflow) non sono strettamente correlati al know-how sulla sicurezza.

In precedenza avevo risposto a una domanda molto simile all'indirizzo How posso limitare i tentativi di accesso dell'utente in PHP . Ribadirò qui la soluzione proposta in quanto credo che molti di voi troveranno utile e informativo vedere un codice reale. Tieni presente che l'utilizzo di un CAPTCHA potrebbe non essere la soluzione migliore a causa degli algoritmi sempre più precisi utilizzati oggi nei buster CAPTCHA:

Non puoi semplicemente prevenire gli attacchi DoS concatenando la limitazione su un singolo IP o nome utente. Cavolo, non puoi nemmeno davvero prevenire tentativi di accesso rapido usando questo metodo.

Perché? Perché l'attacco può estendersi su più IP e account utente allo scopo di aggirare i tuoi tentativi di limitazione.

Ho visto postato altrove che idealmente dovresti tenere traccia di tutti i tentativi di accesso falliti sul sito e associarli a un timestamp, forse: 

CREATE TABLE failed_logins(
    id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(16) NOT NULL,
    ip_address INT(11) UNSIGNED NOT NULL,
    attempted DATETIME NOT NULL
) engine=InnoDB charset=UTF8;

Decidi determinati ritardi in base al numero complessivo di accessi non riusciti in un determinato periodo di tempo. Dovresti basarlo su dati statistici estratti dalla tua failed_logins tabella in quanto cambierà nel tempo in base al numero di utenti e a quanti di loro possono ricordare (e digitare) la loro password. 

10 failed attempts = 1 second
20 failed attempts = 2 seconds
30 failed attempts = reCaptcha

Interroga la tabella ad ogni tentativo di accesso non riuscito per trovare il numero di accessi non riusciti per un determinato periodo di tempo, diciamo 15 minuti: 

SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute);

Se il numero di tentativi nel corso di un determinato periodo di tempo supera il limite, imporre la limitazione o forzare tutti gli utenti a utilizzare un captcha (ovvero reCaptcha) fino a quando il numero di tentativi non riusciti in un determinato periodo di tempo è inferiore alla soglia . 

// array of throttling
$throttle = array(10 => 1, 20 => 2, 30 => 'recaptcha');

// assume query result of $sql is stored in $row
$sql = 'SELECT MAX(attempted) AS attempted FROM failed_logins';
$latest_attempt = (int) date('U', strtotime($row['attempted']));
// get the number of failed attempts
$sql = 'SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute)';
// assume the number of failed attempts was stored in $failed_attempts
krsort($throttle);
foreach ($throttle as $attempts => $delay) {
    if ($failed_attempts > $attempts) {
        // we need to throttle based on delay
        if (is_numeric($delay)) {
            $remaining_delay = time() - $latest_attempt - $delay;
            // output remaining delay
            echo 'You must wait ' . $remaining_delay . ' seconds before your next login attempt';
        } else {
            // code to display recaptcha on login form goes here
        }
        break;
    }
}

L'uso di reCaptcha a una certa soglia garantirebbe che un attacco da più fronti venga ridotto a icona e che gli utenti normali del sito non subiscano un ritardo significativo per tentativi di accesso legittimi non riusciti. Non posso garantire la prevenzione, poiché è già stato ampliato il fatto che i CAPTCHA possono essere eliminati. Esistono soluzioni alternative, forse una variante di & Quot; Nomina questo animale & Quot ;, che potrebbe funzionare abbastanza bene come sostituto.

Riassumendo lo schema di Jens in un diagramma / base di regole di pseudo stato:

  1. utente + password - > voce
  2. user +! password - > negato
  3. utente + noto_IP (utente) - > porta d'ingresso, // never throttle
  4. utente + unknown_IP (utente) - > catflap
  5. (#denied > n) via catflaps (site) - > farfalle acceleratore (sito) // slow the bots
  6. catflap + throttle + password + captcha - > voce // humans still welcome
  7. catflap + throttle + password +! captcha - > negato // a correct guess from a bot

Osservazioni:

  • Non accelerare mai lo sportello anteriore. La polizia di stato elboniana ha il tuo computer a casa tua, ma non è in grado di interrogarti. La forza bruta è un approccio praticabile dal tuo computer.
  • Se fornisci un " Hai dimenticato la password? " link, quindi il tuo account e-mail diventa parte della superficie di attacco.

Queste osservazioni riguardano un diverso tipo di attacco rispetto a quelli che stai cercando di contrastare.

Sembra che tu stia cercando di difenderti da brute a distribuzione lenta forza . Non puoi fare molto. Stiamo utilizzando una PKI e nessun accesso con password. Aiuta, ma se i tuoi clienti si imbattono nelle workstation di tanto in tanto, questo non è molto applicabile.

Dichiarazione di non responsabilità: lavoro per un'azienda a due fattori, ma non sono qui per collegarlo. Ecco alcune osservazioni.

I cookie possono essere rubati con XSS e browser vulns. Gli utenti generalmente cambiano browser o cancellano i cookie.

Gli indirizzi IP di origine sono contemporaneamente dinamicamente variabili e falsificabili.

Captcha è utile, ma non autentica un essere umano specifico.

È possibile combinare più metodi con successo, ma il buon gusto è sicuramente in ordine.

La complessità della password è buona, qualsiasi cosa basata su password dipende in modo critico dalle password con entropia sufficiente. IMHO, una password complessa scritta in un luogo fisico sicuro è meglio di una password debole in memoria. Le persone sanno come valutare la sicurezza dei documenti cartacei molto meglio di quanto sappiano capire l'entropia effettiva nel nome del loro cane quando vengono usati come password per tre diversi siti Web. Considera di dare agli utenti la possibilità di stampare una pagina grande o piccola piena di passcode monouso.

Domande sulla sicurezza come " qual era la tua mascotte del liceo " sono per lo più un'altra pessima forma di " qualcosa che conosci " la maggior parte di essi è facilmente indovinabile o addirittura di dominio pubblico.

Come hai notato, limitare i tentativi di accesso non riusciti è un compromesso tra la prevenzione degli attacchi di forza bruta e la facilità di fare un account. Criteri di blocco aggressivi possono riflettere una mancanza di fiducia nell'entropia delle password.

Personalmente non vedo comunque il vantaggio di imporre la scadenza della password su un sito web. L'attaccante riceve la password una volta, può cambiarla e attenersi a tale politica il più facilmente possibile. Forse un vantaggio è che l'utente potrebbe notare prima se l'attaccante cambia la password dell'account. Ancora meglio sarebbe se l'utente fosse stato in qualche modo avvisato prima che l'attaccante ottenesse l'accesso. Messaggi come & Quot; N tentativi falliti dall'ultimo accesso & Quot; sono utili al riguardo.

La migliore sicurezza deriva da un secondo fattore di autenticazione che è fuori banda rispetto al primo. Come hai detto, i token hardware nella & Quot; qualcosa che hai & Quot; sono fantastici, ma molti (non tutti) hanno un vero overhead di amministrazione associato alla loro distribuzione. Non conosco alcuna & Quot biometrica; qualcosa che sei & Quot; soluzioni valide per i siti Web. Alcune soluzioni a due fattori funzionano con provider openid, altre hanno SDK PHP / Perl / Python.

La mia più alta raccomandazione è semplicemente di assicurarti di tenere informati gli utenti di tentativi di accesso errati ai loro account-- Gli utenti probabilmente prenderanno molto più seriamente la forza della loro password se vengono presentati con prove che qualcuno sta effettivamente cercando di accedere al proprio account.

Ho effettivamente trovato qualcuno che ha violato l'account myspace di mio fratello perché avevano tentato di accedere all'account Gmail che ho configurato per lui e utilizzato la funzione "Reimposta la mia password tramite e-mail" ... che è andata nella mia casella di posta.

  1. Che ne dici di richiedere una password unica prima di inserire la loro normale password? Ciò renderebbe molto ovvio che qualcuno stava attaccando prima di avere molte opportunità di indovinare la password principale?

  2. Mantieni un conteggio / tasso globale di errori di accesso - questo è l'indicatore di un attacco - durante un attacco sii più severo sugli errori di accesso, ad es. vietare gli IP più rapidamente.

Non credo che ci sia una risposta perfetta, ma sarei propenso ad avvicinarlo sulla base del tentativo di confondere i robot se viene rilevato un attacco.

In cima alla mia mente:

Passa a una schermata di accesso alternativa. Ha più spazi vuoti per nome utente e password che appaiono davvero, ma solo uno di questi è nel posto giusto. I nomi dei campi sono RANDOM - una chiave di sessione viene inviata insieme alla schermata di accesso, il server può quindi scoprire quali campi sono cosa. Se ha esito positivo o negativo, viene quindi scartato in modo da non poter provare un attacco di riesecuzione: se si rifiuta la password, viene visualizzato un nuovo ID sessione.

Si presume che qualsiasi modulo inviato con i dati in un campo errato provenga da un robot - il login non riesce, punto e quell'IP è limitato. Assicurati che i nomi dei campi casuali non corrispondano mai ai nomi dei campi legittimi, quindi qualcuno che utilizza qualcosa che ricorda le password non è fuorviante.

Quindi, che ne dici di un diverso tipo di captcha: hai una serie di domande che non causeranno problemi a un essere umano. Tuttavia, sono NON casuali. Quando l'attacco inizia, a tutti viene data la domanda n. Dopo un'ora la domanda n. 1 viene scartata, per non essere più utilizzata e tutti ricevono la domanda n. 2 e così via.

L'attaccante non può sondare per scaricare il database da inserire nel suo robot a causa della natura usa e getta delle domande. Deve inviare nuove istruzioni alla sua botnet entro un'ora per avere la possibilità di fare qualsiasi cosa.

Poiché diverse persone includevano CAPTCHA come meccanismo umano di fallback, sto aggiungendo una domanda StackOverflow precedente e un thread sull'efficacia di CAPTCHA.

ReCaptcha è stato crackato / hackerato / OCR & # 8217 ; d / sconfitto / rotto?

L'uso di CAPTCHA non limita i miglioramenti della limitazione e di altri suggerimenti, ma penso che il numero di risposte che includono CAPTCHA come fallback dovrebbe considerare i metodi basati sull'uomo disponibili per le persone che cercano di violare la sicurezza.

Potresti anche limitare la potenza in base alla forza della password di un utente.

Quando un utente registra o modifica la propria password, si calcola un punteggio di sicurezza per la propria password, ad esempio tra 1 e 10.

Qualcosa come " password " ottiene un 1 mentre " c6eqapRepe7et * Awr @ ch " potrebbe segnare un punteggio di 9 o 10 e maggiore è il punteggio, maggiore è il tempo necessario per l'attivazione della limitazione.

La prima risposta che di solito ho sentito quando ho posto questa domanda è cambiare le porte, ma dimentica quello e disabilita IPv4. Se consenti solo ai client delle reti IPv6 non pregherai più per la semplice scansione della rete e gli aggressori ricorrono alle ricerche DNS. Non eseguire sullo stesso indirizzo di Apache (AAAA) / Sendmail (MX - & Gt; AAAA) / cosa hai dato a tutti (AAAA). Assicurati che la tua zona non possa essere xferd, attendi che tu possa scaricare la tua zona da nessuno?

Se i bot rilevano che il tuo server ha configurato nuovi nomi host, basta anteporre un po 'incomprensibile ai tuoi nomi host e cambiare il tuo indirizzo. Lasciare scaduti i vecchi nomi e persino impostare ** i nomi honeypot per la rete del bot.

** Testa i tuoi record inversi (PTR) (sotto ip6.arpa.) per vedere se possono essere usati per azzerare su / 4 che hanno record VS / 4 che non lo fanno. OSSIA In genere ip6.arpa avrebbe ~ 32 & Quot;. & Quot; s in un indirizzo ma provare con gli ultimi pochi mancanti potrebbe eludere i blocchi di rete che hanno record VS altri che non lo fanno. Se lo spingi oltre, diventa possibile saltare ampie porzioni dello spazio degli indirizzi.

Nel peggiore dei casi gli utenti dovranno configurare un tunnel IPv6, non è come se dovessero spingersi fino al VPN in una DMZ ... Anche se ci si chiede perché non sia la prima opzione.

Anche Kerberos è bello, ma LDHO IMHO soffia (Cosa c'è di tecnicamente sbagliato in NISPlus? Ho letto che Sun ha deciso che gli utenti volevano LDAP e per questo hanno lasciato cadere NIS +). Kerberos funziona bene senza LDAP o NIS, è sufficiente gestire gli utenti su un host in base all'host. L'uso di Kerberos ti dà una PKI facile da usare, se non automatizzata.

Arriva in ritardo qui ma stavo pensando, ipotizzando un caso difficile: l'attaccante usa molti IP casuali, nomi utente casuali e una password casuale selezionata da un elenco dei 10.000 più popolari.

Una cosa che potresti fare, specialmente se il sistema sembra essere sotto attacco in quanto ci sono molti tentativi di password sbagliati sul sistema e soprattutto se la password è bassa entropia è di porre una domanda secondaria come quali sono i nomi dei tuoi genitori , per esempio. Se un utente malintenzionato colpisce un milione di account provando la password "password1", ci sono buone probabilità che ottengano molto, ma le loro probabilità di ottenere anche i nomi giusti ridurranno drasticamente i successi.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top