Domanda:
Perché non è diventata la norma inibire le ripetute tentazioni di password?
donjuedo
2017-02-01 04:02:16 UTC
view on stackexchange narkive permalink

Tutti sono consapevoli della convenzione / necessità di password complesse. Con il numero di diversi tipi di indizi che le persone possono utilizzare nelle loro password, oltre alle varie permutazioni di maiuscole e lettere di sostituzione, un hacker dovrebbe in media fare molti tentativi per ottenere la password corretta.

Questo link: Rallentamento degli attacchi ripetuti alle password discute alcuni sforzi per scoraggiare tutte quelle supposizioni, anche se non è la stessa domanda che mi pongo: perché non è diventata la norma interferire con le ipotesi ripetute? Un aumento del tempo di backoff dopo ogni ipotesi sbagliata è un modo, e altri sono stati discussi.

Ho visto pochissimi tentativi di inibire tali supposizioni sui sistemi Linux o qualsiasi autenticazione basata sul web. Sono stato escluso da un sistema quando ho sbagliato 3 volte.

Gli IT impongono sempre più vincoli, come il conteggio dei caratteri, le lettere, le cifre, le maiuscole e l'esclusione del nome utente dalla password. Ma questo aumenta semplicemente il numero di tentativi necessari in una situazione in cui il numero non è realmente limitato.

Citazione necessaria!Molti sistemi implementano le limitazioni, sebbene possano essere silenziose piuttosto che con un blocco esplicito;possono anche essere limitazioni generali delle richieste del sito piuttosto che essere specifici per l'accesso.Per ssh (che ha già ritardi incorporati), vedi anche la popolarità di fail2ban.Sospetto che il motivo per cui in realtà non si verificano spesso blocchi è perché sono * ben sintonizzati * per non attivarsi per il normale comportamento dell'utente e non stai attivamente e persistentemente cercando di violare gli account utente.
La misura di una buona sicurezza è la capacità di ** distinguere ** tra utente legittimo e utente malintenzionato.Un sistema di sicurezza che blocca un utente legittimo dal proprio account non soddisfa i criteri di disponibilità della triade CIA (riservatezza, integrità e disponibilità).Una buona politica di blocco degli account dovrebbe essere progettata in modo che non vengano mai rilevati da utenti legittimi.Se tutto ciò che conta è tenere fuori i cattivi indipendentemente dal costo per gli utenti legittimi, ho il miglior sistema di sicurezza al mondo: `function login (un, pw) {return" Sorry wrong password ";} ".
Aggiungendo commenti precedenti, tali limitazioni saranno silenziose per evitare di aiutare gli aggressori a sapere esattamente quali protezioni sono impiegate.
È abbastanza comune che i sistemi restituiscano il loro normale messaggio di "nome utente o password errati" una volta bloccato un account, altrimenti si rivela se esiste un account, a meno che non si tenga traccia di ogni nome utente inserito e si risponda in modo identico.
@LieRyan, ad esempio, il nuovo sistema captcha significa che un vero essere umano non dovrebbe spesso dover selezionare dalle foto
@LieRyan: Ho imparato la CIA come "riservatezza" (nessun altro può leggerlo), "integrità" (sto leggendo ciò che è stato inviato) e "Autenticità" (viene davvero da chi penso).
AilidlkseiCMT https://en.wikipedia.org/wiki/Information_security#Availability
"Il personale IT impone sempre più vincoli, come il conteggio dei caratteri, lettere, cifre, maiuscole e l'esclusione del nome utente dalla password." Citazione necessaria.Normalmente sono i capi con i capelli a punta che aggiungono stupide password "requisiti di forza".https://xkcd.com/936/
La sicurezza della password è importante anche per gli hack in cui l'hacker ha ottenuto un elenco di password con hash.Se la password di tutti fosse sbagliata, la forza della funzione hash sarebbe meno importante.
Non sono sicuro di essere d'accordo con l'idea che "tutti siano consapevoli della necessità di password complesse".Guarda qualsiasi dump di password da recenti violazioni e ti garantisco che troverai un'alta percentuale di password banali lì dentro ...
Perché le persone usano ancora MD5 per l'hashing delle password?Perché non sanno meglio o non si [email protected] "Autenticità" farebbe parte di, integrità "secondo la tua stessa definizione.
Sei risposte:
#1
+113
Mike Ounsworth
2017-02-01 04:08:47 UTC
view on stackexchange narkive permalink

Vorrei sfidare la tua supposizione secondo cui non viene fatto.

[avvertimento: approssimazioni selvagge da seguire]

Ricorda che un attacco di forza bruta riuscito richiederà milioni o miliardi di tentativi al secondo per eseguire il crack in un lasso di tempo ragionevole (diciamo, da un paio d'ore a un mese a seconda della forza della tua password). Anche un limite di velocità di 100 tentativi di password al secondo aumenterebbe il tempo di cracking da un mese a centinaia di migliaia di anni. Forse i miei standard sono bassi, ma è abbastanza buono per me, e nessun utente umano che tenta legittimamente di entrare nel proprio account lo noterà mai. Ancora meglio se il limite di velocità fosse l'IP piuttosto che il nome utente solo per prevenire alcuni tipi di attacchi Denial-Of-Service.

Inoltre, non so quale distribuzione Linux stai usando, ma sui miei sistemi Ubuntu e CentOS, quando digito erroneamente la password nella schermata di accesso della GUI o del terminale, si blocca per 1 secondo prima di riavviarmi.


Anche se il server non è attivo tentativi di accesso limitanti la velocità (come dovrebbero essere), solo il tempo di ping da solo è sufficiente per rallentarti fino a milioni di anni. Probabilmente eseguirai il DDOS del server prima di avvicinarti a 1 miliardo di tentativi / secondo. Il denaro vero è ottenere una copia del database delle password con hash e inserirla in un rig GPU dove sono possibili miliardi di ipotesi al secondo.

TL; DR: se lo sei ti impegnerai a rafforzare il tuo server di accesso, otterrai più soldi migliorando l'hashing della password e rendendo il tuo database difficile da rubare piuttosto che implementando la limitazione della velocità nella schermata di accesso.


AGGIORNAMENTO : da quando è diventato virale, traggo qualcosa dai commenti:

Questa logica si applica solo ai server di accesso. Per i dispositivi fisici come telefoni o laptop, il tipo "3 tentativi e si blocca" o "10 tentativi e il dispositivo si cancella" ha ancora senso perché qualcuno potrebbe navigare con le spalle mentre digiti la tua password o vedere il motivo sfumato sullo schermo o sappi che un PIN di 4 cifre ha comunque solo 10.000 combinazioni, quindi il numero di tentativi che devono fare è molto molto molto più piccolo.

È interessante pensare che forse alcuni sistemi danno * l'apparenza * che non è stato fatto per mitigare il rischio di DOS e identificare i cattivi (forse è quello che intendevi, Mike?) In contrasto con i sistemi che comunemente implementano blocchi.
@symcbean In realtà non stavo pensando all'honeypotting.Il punto era più che un "blocco" di 10 millisecondi è sufficiente per fermare un attacco di forza bruta drive-by, quindi perché disturbare i tuoi utenti senza motivo?Ora, per telefoni e PC con macchie sullo schermo o persone che guardano alle spalle, forse c'è un argomento per un blocco dopo 3, ma l'OP chiedeva specificamente dei server web.
Su Linux, in particolare nelle configurazioni del server, esiste un servizio chiamato Login Failure Daemon (LFD).Invece di disabilitare un accesso, LFD vieta temporaneamente l'indirizzo IP che tenta di accedere.
@MikeOunsworth Un blocco dopo 3 è del tutto impossibile a meno che il dispositivo non sia gestito centralmente e consenta uno sblocco tramite un IT aziendale o simili, e anche in questo caso è complicato nella pratica.Le persone digitano le password 3 o più volte troppo spesso, specialmente nei casi in cui viene applicata la modifica della password.
DDOS = attacco Denial of Service distribuito.Non puoi farlo da solo.
@JanDvorak Questo è esattamente il mio punto: non c'è modo che un singolo computer possa generare ovunque vicino a 1 miliardo di richieste di accesso al secondo.
@DRF Nella mia esperienza, 3-5 tentativi di blocco sono in realtà una pratica abbastanza comune.L'AD della mia azienda attuale è impostato su 3. Penso di aver bisogno dell'amministratore di rete per sbloccare il mio account forse una o due volte in oltre 8 anni.Ho anche dovuto chiedere all'amministratore di rete di sbloccare gli account di altri utenti che stavano tentando di accedere a un servizio Web che ho scritto una manciata di volte in quel periodo.Per impostazione predefinita, il mio telefono Samsung cancella effettivamente la memoria del telefono se il codice di accesso viene digitato in modo errato 10 volte.A giudicare dalla situazione con l'FBI nel caso del tiratore del San Bernardino, iOS apparentemente utilizza lo stesso valore predefinito.
Ciò presuppone che l'obiettivo sia quello di compromettere una password specifica e non solo "la password di chiunque".In quel caso l'aggressore (dopo aver enumerato gli account utente), ha appena provato tutti gli account con "Password1" o equivalente e da lì parte, probabilmente ottenendo l'accesso con un numero relativamente basso di tentativi (rispetto ai numeri necessari per una forza bruta diun account) questo è più rilevante nelle app Web rispetto ai box Linux, dove è probabile che ci sia una grande popolazione di utenti.
RoryMcCune Se usi fail2ban, o qualcos'altro per il limite di velocità basato sull'IP piuttosto che il limite di velocità basato sul nome utente richiesto, non è la stessa cosa?
Per non parlare del fatto che un blocco come questo può facilmente diventare un attacco DOS stesso - tutto ciò che devi fare è trovare i nomi utente degli utenti del servizio e "indovinare" tre password sbagliate e voilà - il servizio non è più utilizzabile.Particolarmente efficace se gli amministratori non hanno un accesso speciale, quindi non possono annullare i blocchi: P
#2
+60
Ken Whitesell
2017-02-01 06:22:34 UTC
view on stackexchange narkive permalink

Esiste un problema significativo con il blocco delle persone dopo ripetuti tentativi non validi: in realtà diventa un vettore di attacco per un tipo di attacco Denial of Service. Pensa a cosa potrebbe accadere a un supporto tecnico o a un sito di assistenza clienti se duecentomila account finissero tutti bloccati in modo coerente da qualcuno che cerca di interrompere un servizio.

C'è anche un sito web che utilizzo questo mi invia un messaggio fisico ogni volta che cambio la password: qualcuno particolarmente sgradevole potrebbe davvero creare problemi trovando un elenco di account e sospendendoli ripetutamente.

C'è sicuramente una chiamata di giudizio da fare tra sicurezza e usabilità, e personalmente non credo che ci sia una risposta fissa o semplice.

Non proveresti a bloccare la macchina (IP di origine) invece dell'utente che viene utilizzato?In questo modo un utente malintenzionato dovrebbe essere in grado di (fingere di) provenire dallo stesso IP dell'utente legittimo.Ora, anche se potrebbe essere possibile, penso che dovrebbe essere molto più difficile ...
Le reti Bot di @Thomas significano che puoi utilizzare migliaia o milioni di indirizzi IP per provare ad accedere a un account.
@Thomas E come archiviate queste informazioni?Se ho una botnet con diecimila computer e faccio il blocco su tutti gli utenti del sistema da diecimila macchine diverse, il tuo sistema sopravviverà?Qual è la possibilità che sono riuscito a bloccare anche alcuni utenti legittimi (NAT e simili)?Come può l'utente sapere perché non può più accedere al suo account, soprattutto quando una buona pratica di sicurezza è evitare di dire all'utente che il suo account è stato bloccato?Il tuo servizio può gestirlo?
Stranamente, [Stack Exchange stesso è stato utilizzato per un attacco di inondazione della reimpostazione della password] (http://meta.stackexchange.com/questions/270051/please-rate-limit-the-password-reset-functionality)
@Luaan "È sempre qualcosa" (RFC 1925)
#3
+5
Slava Knyazev
2017-02-01 04:08:21 UTC
view on stackexchange narkive permalink

Una complessità sufficiente rende tecnologicamente poco pratico la forza bruta, rallentarla non farebbe molto di più.

"Ma questo aumenta semplicemente il numero di tentativi necessari" è un modo strano se si dice miliardi di anni in più.

Il rallentamento che immaginavo potrebbe essere 1 secondo in più dopo il primo errore, quindi 2 secondi, poi 4, poi 8 e così via.Ovviamente, questo deve essere ripristinato dopo aver soddisfatto un criterio.Con un tale livello di ritardo, anche una password modesta sembrerebbe sufficiente (a me, un principiante).
@donjuedo Ma a quale scopo?Con una complessità sufficiente, semplicemente non importa.Il server sarà un fossile quando lo avrà.
Ha lo scopo di ricordare password più facili, pur mantenendo la sicurezza.
Quindi utilizzare password meno complesse?È semplicemente una cattiva idea, non importa come la guardi.
Stiamo confrontando (password complesse indovinate ad alta velocità) con (password meno complesse indovinate a bassa velocità).Nessuno dei due è intrinsecamente migliore dell'altro.Ciò che è importante è quello che hai detto, "non pratico per la forza bruta", o il tempo previsto per il crack è troppo lungo.
le password complesse indovinate ad alta velocità SONO intrinsecamente migliori però.La velocità è lineare, la complessità esponenziale.
Questo è un tipo di risposta "incolpare la vittima".La scelta di una password entropica è una buona misura, ma quella che gli * utenti * adottano per proteggersi dagli aggressori.La limitazione dei tentativi di accesso, invece, è una misura adottata da * sviluppatori * e * amministratori * per proteggere gli utenti dagli aggressori * e da se stessi *.Gli sviluppatori e gli amministratori non possono salvare * tutti * gli utenti dalle loro scelte sbagliate, ma abbiamo la responsabilità di fornire garanzie ragionevoli.
@donjuedo che proteggerà solo la password debole dal bruteforcing * attraverso quel singolo canale *.Se ad es.Gli hash salati vengono trapelati da un database, quindi le password deboli sarebbero vulnerabili al bruteforcing "attorno" al server e al throttle, mentre le password complesse sarebbero comunque protette.
#4
+4
Goodbye SE
2017-02-02 15:48:24 UTC
view on stackexchange narkive permalink

Si presume che le password possano essere verificate solo utilizzando il login, ma molto spesso si verifica una fuga di dati / hack che consente a qualcuno di ottenere le tabelle hash della password. Se li ha, può semplicemente forzare gli hash, che è molte volte più veloce rispetto all'utilizzo del login ed è qui che hai davvero bisogno di buone password.

#5
+2
Rory McCune
2017-02-02 19:48:03 UTC
view on stackexchange narkive permalink

Un concetto molto importante che finora non vedo menzionato nelle altre risposte è la differenziazione tra forza bruta offline e online.

Nella forza bruta offline l'attaccante ha accesso alle password con hash e qui la difesa principale sta usando un algoritmo di hashing della password appropriato (ad esempio bcrypt). i punti sugli algoritmi di hashing, il cracking della GPU, ecc., riguardano solo la forza brute offline

Presumo che questa domanda riguardasse la forza brute online in cui l'attaccante sta tentando di accedere al sistema probabilmente da remoto.

Con gli accessi remoti per servizi come SSH, come è stato accennato, l'individuazione remota della password è comunemente inibita tramite fail2ban o simili.

Dove non è comune è nelle applicazioni web (lo so perché do ai proprietari di risultati di applicazioni web per mancanza di questa funzione abbastanza comunemente).

In alcuni sistemi è impostato un blocco diretto, ma questo comporta il rischio di negazione del servizio da parte degli aggressori che indovinano la password e anche alcuni inconvenienti per l'utente a seconda del meccanismo di riattivazione degli account.

Una soluzione migliore è forzare un ritardo crescente nei tentativi di accesso per rendere l'attacco meno fattibile, tuttavia è importante notare che in alcuni casi un utente malintenzionato potrebbe voler compromettere solo un account (e non preoccuparsi veramente di chi ha l'account che ottiene) in cui nel caso in cui possano provare solo un piccolo numero di password comuni nella base utenti, con l'aspettativa che qualcuno le abbia utilizzate.

La tua supposizione sulla domanda relativa alla forza bruta online è corretta.Quando ho postato, non avevo nemmeno considerato un attacco offline e l'ho notato solo dopo che è stato menzionato qua e là.
#6
+1
dark_st3alth
2017-02-01 04:20:40 UTC
view on stackexchange narkive permalink

Il modo più semplice per esaminarlo è con un'altra domanda. Perché SHA-1 / MD5 è ancora in uso quando sono presenti difetti / problemi noti?

In poche parole, la valutazione del rischio dell'individuo / azienda ritiene che tali problemi non siano di grande preoccupazione. Proprio come nel caso dei timeout a rotazione.

Quando facevo l'amministrazione per una scuola locale, era abbastanza comune per gli insegnanti "indovinare" le proprie password. Costringere gli insegnanti ad aspettare è stato molto più un inconveniente, quindi bloccare un account dopo 4 o 5 password errate e chiedere loro di telefonarmi per sbloccarlo.

Anche i timeout a rotazione sono un grosso problema da affrontare. Per un sistema locale, questo potrebbe non essere un problema, ma prendi l'esempio della mia scuola (proprio come sopra) o di una grande impresa con oltre 1.000 dipendenti. Non è più possibile lavorare perché qualcuno è seduto a una richiesta di password, in attesa di poter inserire la password corretta. Forse qualcuno ha pensato che sarebbe stato divertente convincere qualcuno a sedersi a un prompt per alcune ore o un malintenzionato voleva rallentare la produzione? Tieni presente che ci deve essere un modo per amministrare la durata dei timeout, di quanto aumentano e un modo per ripristinarli.

Direi che un sistema di blocco, come quello consentito da Windows, è effettivamente più sicuro. Richiede un intervento amministrativo e può essere molto più veloce da annullare (più il tempo impiegato per esaminare i log). Su un sistema basato sul Web, un timeout a rotazione potrebbe essere più vantaggioso, ma come abbiamo già visto, gli hash delle password saranno trapelati e i timeout a rotazione non sarebbero di aiuto.

In realtà la schermata di accesso di Windows * ha * un ritardo.Ottieni un paio di tentativi gratuiti, quindi inizia ad aggiungere ulteriori ritardi.(Mi sono imbattuto in questo, mentre stavo cercando di accedere con una tastiera diversa.)
@MartinBonner Ciò si verificherà dopo il 3 ° (o 5 °?) Ingresso errato, dove c'è un ritardo significativo.Se ricordo bene, non esiste la funzione "rolling", il ritardo non diventa sempre più lungo.Poi di nuovo, a questo punto dovrebbe essere attivato un blocco dell'account.
I blocchi hanno i loro rischi, tuttavia, soprattutto quando un utente malintenzionato è remoto, il che è che è abbastanza facile per loro eseguire il servizio DoS, specialmente se il formato del nome utente è noto.
@dark_st3alth Il blocco dell'account ha senso solo in un dominio.Sebbene una buona parte delle macchine Windows venga eseguita in un dominio, non puoi davvero ignorare tutti quei computer che non lo fanno.In che modo un utente non di dominio si riprenderà dal blocco?


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...