Confuso sull'uso di una password che "ci vorrebbe secoli per rompere"

49

Sto parlando di questa password - 23##24$$25%%26 e di quelli simili composti da caratteri speciali che appaiono in uno schema, che gli utenti in questi giorni usano molto.

Al lavoro (società finanziaria) stavo creando un elenco di password errate che gli utenti non dovrebbero poter scegliere, che coinvolgono determinati cicli o pattern, e il tipo di cui sopra mostra quel tratto di contenere numeri consecutivi che racchiudono caratteri speciali (ripetute certe volte, qui due volte).

Solo per curiosità, l'ho verificato su un sito molto conosciuto (sulla sua pagina di accesso), e ha dichiarato che ci sarebbero voluti secoli per rompere.

Alcuni altri esempi nell'elenco che richiederebbero anni per rompere, ma sono molto vulnerabili:

1!2@3#4$5%6^ %codice% 2@3#4$5%6^7&

Ora, rimango confuso con la lista, dovrei contrassegnare questi particolari tipi di password come vulnerabili e non consentire agli utenti di farli, anche se impiegano molto tempo per interrompere?

Nota 1 - Stiamo considerando questi vulnerabili come molti utenti (e, quindi, più password simili) stanno seguendo questa tendenza per ricordare facilmente le cose.
Nota 2 - Siamo confusi perché i membri della sicurezza stanno aumentando l'entropia, ciò che stanno ignorando è una maggiore ordine di hash simili nel database
Sorse un attrito tra ragazzi su dove disegnare una linea, definendo quale password essere consentita o non consentita.

Modifiche:

  • Di questo sito di cui sto parlando, ma che non nominerò, su cui ho provato la password è praticamente noto a tutti gli hacker etici / non etici, quasi tutti gli utenti qui su Stack Exchange e molte grandi / piccole aziende ( come usano i suoi servizi).

  • Non memorizziamo le password in testo semplice . Utilizziamo un algoritmo di hashing piacevole, non preparato in casa.
    Un incidente ci ha portato a rivedere le nostre norme sulle password e abbiamo creato un database separato a!b@c#d$e%f^ su una macchina diversa, in cui abbiamo archiviato semplicemente_hashed_newly_created password utente (niente sale, niente, solo hashed_password) senza memorizzare who_created, when_created details. Lo abbiamo fatto solo per un breve periodo. Anche la modifica della password è stata inserita in questo database. Mentre, nel nostro database originale db-2 sat secure_salted_passwords.
    Abbiamo continuato a creare una lista db-1 di password vulnerabili con hash, seguendo un pattern, e siamo rimasti divertiti quando abbiamo trovato L & L - abbiamo visto più gruppi di password simili, con determinati modelli. db-2 e L sono stati successivamente cancellati dai sistemi.

  • db-2 è stato mantenuto su un computer altamente sicuro ed è sicuro, non fornirà qui i dettagli esatti. Siamo consapevoli che anche le intercapedini o le prese elettriche non sono sicure. Sia db-2 che db-2 sono stati distrutti.

  • Non preoccuparti delle password pubblicate qui, dato che abbiamo già condotto il nostro piccolo esperimento e tutte quelle serie specifiche di utenti sono state create per reimpostare le password (ovviamente una nuova password diversa da quella precedente). Questa è la ragione, sono venuto qui pubblicando alcuni campioni.
    E, ho già commentato qui in precedenza, che ho pubblicato un campione di password dalla logica del generatore che ha creato un elenco molto grande di password hash, che possono essere o non essere in L . Ancora una volta, poiché tutti quegli utenti hanno una nuova password, quindi non preoccuparti, tutto è sicuro e protetto.

  • Dal momento che so che il generatore funziona, ho testato alcuni esempi di password su un sito Web e ci siamo confusi su quali sono consentiti o non autorizzati, su quali criteri.

Grazie mille per le tue risposte, accetta la mia gratitudine. Sulla base delle risposte, per il momento abbiamo rinviato qualsiasi tipo di restrizione da porre sulla scelta della password.

    
posta Batman 04.05.2018 - 21:55
fonte

10 risposte

84

I calcolatori online stanno basando i loro risultati su un particolare insieme di ipotesi, che potrebbero non essere applicabili in nessun caso. Non vi è alcuna base per fidarsi dei calcolatori per fornire informazioni su come un utente malintenzionato potrebbe scegliere di infrangere la password.

Ad esempio, se so che usi un pattern e qual è il pattern, aggiusterò il mio bruteforcing per allinearlo al pattern. Non c'è modo per un calcolatore online di renderlo conto. Ci sono altri fattori simili da tenere in considerazione. "Entropia" significa garantire la massima casualità possibile. Un pattern impostato ha una casualità molto ridotta, indipendentemente dai caratteri utilizzati.

Quindi, sì, vietare tali modelli ovvi, se ciò soddisfa il tuo obiettivo.

Tuttavia, mi preoccupa il tuo modo di vietare queste password. Potresti combattere la battaglia sbagliata.

    
risposta data 04.05.2018 - 22:06
fonte
40

Just out of curiosity, I checked this on a very well known website(on its login page) and it stated that this would take centuries to break.

Tali siti Web non possono essere presi come vangelo. Molti sono inutili, e anche per quelli buoni i risultati devono essere interpretati con attenzione. Prima di tutto, come regola generale, un correttore forza può definitivamente dirti che una password è debole ma non può davvero dimostrarti che una password è strong - la password che non riesce a trovare errori potrebbe ricadere su qualche attacco che il misuratore non modella. Per alcuni esempi estremi, questo articolo di Ars Technica descrive attacchi di cracking riusciti su passphrase di lunga durata altrimenti impressionanti :

Almost immediately, a flood of once-stubborn passwords revealed themselves. They included: "Am i ever gonna see your face again?" (36 characters), "in the beginning was the word" (29 characters), "from genesis to revelations" (26), "I cant remember anything" (24), "thereisnofatebutwhatwemake" (26), "givemelibertyorgivemedeath" (26), and "eastofthesunwestofthemoon" (25).

L'altra cosa è che solo perché un metro ti ha detto che giudica la password strong non significa che tutti questi misuratori lo facciano. Ad esempio, il zxcvbn controllore, che è uno dei migliori, pensa che questo sia irrisolto in 3 ore da un attacco offline se il l'hashing della password è debole:

password:              23##24$$25%%26
guesses_log10:         14
score:                 4 / 4
function runtime (ms): 3
guess times:
100 / hour:            centuries  (throttled online attack)
10  / second:          centuries  (unthrottled online attack)
10k / second:          centuries  (offline attack, slow hash, many cores)
10B / second:          3 hours    (offline attack, fast hash, many cores)

match sequence:
'23##24$$25%%26'
pattern:               bruteforce
guesses_log10:         14

Stima 2 minuti per 1!2@3#4$5%6^ , 2@3#4$5%6^7& e a!b@c#d$e%f^ con un attacco di 10B / secondo (3 anni a 10k / secondo), quindi quelli che pensa sono anche peggio. (Anche se totalizza tutti 4/4. Il contatore consiglia di accettare effettivamente una qualsiasi di queste password, perché stima che sia ragionevolmente probabile che resista agli attacchi se la tua applicazione ha implementato l'hashing della password lenta Ma la sua analisi dimostra che sono deboli a un attacco specifico che dovresti mitigare.)

Si noti che gli attacchi di modelli zxcvbn si basano solo sulla conoscenza generale di come la maggior parte degli utenti sceglie le password: non ha alcuna conoscenza specifica su come le politiche o le pratiche della propria organizzazione potrebbero consentire un attacco specializzato a qualcuno che le apprende. E ricorda sempre, lo strumento può dirti che una password è debole, ma non che sia strong - zxcvbn stima che i secoli creino Am i ever gonna see your face again? , che dall'articolo Ars che sappiamo è stato effettivamente incrinato vita reale.

Now, I stand confused with the list, should I mark these particular kinds of passwords as vulnerable and disallow the users going for them, even if they take a very long time to break?

Il tuo istinto di bandire queste password in realtà risulta avere qualche giustificazione, come dimostrato dai risultati di zxcvbn. Il problema è che difficilmente riuscirai a compilare un elenco finito di password che sono allo stesso modo vulnerabili, né dei pattern che un utente malintenzionato potrebbe sfruttare con successo. Ad esempio, per catturare tutte le password che secondo zxcvbn sono vulnerabili come le ultime tre, è necessario un elenco con 1.2 trilioni di voci (10B di password / secondo × 2 minuti). Non pratico. Anche se provi a condensare le cose in una piccola lista di schemi da rifiutare, non conterei di pensare con successo ai tuoi attaccanti.

Una cosa che dovresti assolutamente fare è usare un hashing sicuro delle password, con le funzioni hash della password bcrypt o Argon2. Questo è ciò che i risultati di zxcvbn sopra chiamano "hash lento" e probabilmente rende le voci della password molto più difficili da violare. (Ma ancora una volta, ricorda che un controllore forza può dirti che alcune password sono sicuramente non sicure, ma non è sicuro.)

Cose da considerare in aggiunta:

  • Utilizzare una piccola lista (migliaia) di password che sono note per essere molto comuni e vietarle. Tali elenchi possono essere facilmente trovati online.
  • Utilizza la lista delle password violate di Troy Hunt 500M + , che ha anche un API online. (Assicurati di leggere il materiale su k-anonimato così non lo fai realmente invia password all'API!)
  • Utilizza una libreria di misuratori di forza intelligente come zxcvbn, che è un'alternativa molto più sofisticata alla rilevazione di pattern come quello che stai contemplando.
  • Implementa un secondo fattore di autenticazione, in modo che le password non siano l'unica linea di difesa.
risposta data 04.05.2018 - 23:28
fonte
13

L'indessibilità delle password significa conoscere qualcosa sul tipo di password che le persone potrebbero scegliere. Sappiamo tutti che "Password" è probabile perché è una parola inglese. Ma per sapere che è necessario conoscere l'inglese o avere un'idea di come l'inglese o altre lingue correlate scrivano le parole. Un alieno da qualche parte nelle vicinanze di Betelgeuse che non è mai stato esposto all'Inglese o ad un'altra lingua umana non saprà che "Password" è facilmente ipotizzabile. In altre parole, i pattern sono in qualche modo soggettivi, il che (oltre un certo livello) li rende terribilmente difficili da prevedere in anticipo.

Allo stesso modo, per alcune password del tuo elenco non è immediatamente evidente quale sia lo schema. 1! 2 @ 3 # 4 $ 5% 6 ^ sembra un po '"casuale" a prima vista, ma noterete subito che su una tastiera QWERTY, è semplicemente da 1 a 6 e si alterna ogni altro carattere con il tasto Maiusc.

Inoltre, se qualcuno ti ha mostrato la password CPE1704TKS potresti anche pensare che sia una buona password. Ha 10 caratteri di lettere e numeri, non c'è un pattern ripetibile determinabile ad esso, e non è una parola in nessuna lingua umana. Ti sbaglierebbe comunque, e questa non è una grande password perché è la password usata per lanciare i missili nucleari alla fine del film Wargames.

Per questo motivo, l'uso di calcoli di "crackability" (basati sulla lunghezza e sulla selezione dei caratteri) da un sito Web casuale è in gran parte fasullo. Inoltre dipendono da qualcuno che ottiene gli hash delle password, che è di per sé un importante compromesso di sicurezza. Sono doppiamente falsi perché implicano che tu sappia quanto velocemente un hash prende. Le velocità di hashing variano di molti ordini di grandezza a seconda dell'algoritmo che hai scelto. Quindi prendi i punteggi di "crackability" con un pizzico di sale. Al giorno d'oggi la maggior parte degli attacchi alle password utilizza password comuni o le password riutilizzate non vengono rubate.

In realtà, si tratta semplicemente di mantenere un elenco di "password errate" che altre persone hanno trovato nel corso degli anni che hanno una sorta di significato speciale. La mia ipotesi è che sia da qui che arrivano i ragazzi della sicurezza.

    
risposta data 05.05.2018 - 03:37
fonte
11

È impossibile dimostrare che una determinata password è difficile da decifrare.

Cosa intendi con la (corretta) affermazione che questi "sono altamente vulnerabili" è che esiste un algoritmo più facile da indovinare per generarli, cioè "colpisci la riga numerica di una tastiera QWERTY in un modo così semplice". Questo è un algoritmo facilmente riconoscibile per un umano che passa tutto il giorno a premere le dita su una tastiera del genere, ma i pattern su una tastiera di questo tipo sono in realtà piuttosto "non ovvi per un computer", perché in effetti la maggior parte dei programmi per computer non Non preoccuparti del layout fisico dei tasti .

Potrei ugualmente dare un esempio come YWJjZGVmZ2hpamts , che si potrebbe pensare sia una password ragionevolmente sicura, ma in realtà si sarebbe sbagliato perché capita di essere la codifica Base64 della stringa abcdefghijkl , e ciò potrebbe sembrare assolutamente ovvio a un AI per il quale una stringa è fondamentalmente un pattern di bit.

La nozione di quanto possa essere espresso un dato bit di informazione è chiamata complessità di Kolmogorov . Nonostante la semplice definizione, questo è in realtà un concetto molto complesso: dipende molto dalla lingua in cui si desidera esprimere tutto, ed è non trasferibile . In realtà il meglio che si possa fare è valutare tutti i possibili programmi brevi in un linguaggio di programmazione espressivo con una grande libreria standard, ma se ciò non riesce non garantisce affatto che non ci sia un basso modo entropico per calcolare la password in un'altra lingua che include una funzione standard cruciale. Se non sapessi del layout QWERTY, potresti anche pensare che asdfqwerzxcv sia sicuro, nonostante la completa ovvietà quando lo sai.

Il risultato: se si trova una rappresentazione a bassa entropia di una determinata password, allora sì, proibiscilo. Ma non prendere mai l'asserzione di nessuno (compresa qualsiasi programma ) al valore nominale che una determinata password sia sicura se non sa come la password è stata effettivamente generata. Se vuoi garantire password veramente noncrissibili, l'unico modo è assicurarti che escano da un processo casuale fisico quantistico-meccanico.

Qualsiasi programma relativo al cracking delle password dovrebbe conoscere i layout della tastiera, perché è risaputo che gli umani tendono a ricorrere a tali schemi. Inoltre, 23##24$$25%%26 è abbastanza semplice anche senza conoscendo il layout della tastiera, perché la riga numerica è quasi ordinata in ASCII. Quindi, questi siti stanno facendo davvero un lavoro terribile qui.

Anche ignorando i problemi di runtime. Quello che stai facendo qui è tanto difficile quanto forzare brutemente una password sconosciuta .

    
risposta data 05.05.2018 - 13:03
fonte
10

Una password come "12345678" potrebbe essere considerata casuale, se vuoi. Se si utilizza un generatore di password casuali, la probabilità di generare "12345678" è la stessa di "4h2Ud8yG" (considerando solo le password alfanumeriche). E "12345678" può essere difficile da spezzare come "4h2Ud8yG", se lo si rinforza in modo casuale nell'intervallo da "00000000" a "ZZZZZZZZ". Ma la verità è che le password non dovrebbero essere solo casuali, dovrebbero anche sembrare casuali. Perché? Poiché gli hacker utilizzano spesso la bruteforce in base a dizionari o pattern, quindi le password che non sono basate su parole o pattern sono più sicure. Inoltre, se vengono utilizzate parole e motivi per rendere la password più facile da ricordare, è probabile che tutte le altre password utilizzate dalla stessa persona siano più facili da ricordare allo stesso modo. Quindi, se un utente malintenzionato ruba una delle tue password e sembra "John75", è probabile che interrompa la maggior parte delle tue password con schemi bruteforcing come "nome + numero", "parola + numero" o alcune varianti. Ma se l'attaccante ruba una tua password e sembra casuale come "4h2Ud8yG", allora non sarà in grado di estrarre alcuna informazione da esso.

Quindi hai ragione quando dici che quelle password che hai non sono veramente sicure. Non hanno nemmeno tutta l'entropia che pensi di avere! E questo perché l'entropia della password si basa sul modo in cui una password appare o sul modo in cui viene creata una password. Una password come "1! 2 @ 3 # 4 $ 5% 6 ^", se la pensi come "numero seguito da un simbolo, sei volte", avresti (10x10) ^ 6 = 10 ^ 12 possibilità. Che è inferiore alle possibilità di una semplice password di 8 caratteri composta da lettere minuscole e numeri: 36 ^ 8 = 2,8 x 10 ^ 12 possibilità. Ma se pensi a quell'esempio di password come "numero seguito da simbolo sulla stessa chiave, a partire da 1 in ordine crescente, sei volte", allora le possibilità totali sono ... solo una!

    
risposta data 04.05.2018 - 23:04
fonte
6

Prima di tutto, quegli indicatori di password password sono linee guida, non verità assolute.

In secondo luogo, quanto è sicura una password, o quanto tempo ci vorrà per croppare dipende da alcuni fattori. Per capirlo meglio, è importante capire in che modo le password si "spezzano" in primo luogo.

Ci sono 3 attacchi comuni alle password:

  1. Gli hacker tentano di accedere a un servizio indovinando la password
  2. Gli aggressori hanno trovato la stessa combinazione nome utente / password in una violazione separata e ora la stanno utilizzando contro un servizio non interrotto (riempimento delle credenziali)
  3. Gli hacker hanno ottenuto il dump del database di un servizio e hanno l'hash della password. Ora sono brute-costringendo gli hash a determinare la password in chiaro.

Per impedire agli aggressori di indovinare le password, applichiamo una sorta di "regola entropia" E abbiamo i tentativi di accesso con limite di frequenza. In questo modo gli aggressori non possono forzare il tuo servizio direttamente.

Per evitare che il ripieno di Credential sia più difficile. Indipendentemente dal modo in cui forzate le password, sarà di scarso aiuto se l'utente avesse la stessa password su un sistema separato e vi sia stato salvato in testo normale !

Alcune società (in particolare Amazon, LinkedIn e OpenTable) stanno persino accedendo alle violazioni dei dati e avvisando i loro clienti - anche se tali violazioni sono al di fuori di tali società . Questo aiuta a proteggere dal riempimento delle credenziali (un po '!), Ma potrebbe essere un po' troppo fine.

Infine, c'è il tipico brute-forcing di un hash per le password. È qui che un utente malintenzionato ha in qualche modo ottenuto il possesso degli hash delle password degli utenti e ora sta tentando di indovinare il testo in chiaro dagli hash. Ecco dove sentiamo comunemente ci vorranno secoli per rompere tropo.

Tipicamente l'attaccante utilizzerà uno strumento come ocl-hashcat in combinazione con un elenco di parole di password comune (come le password RockYou o Top1000, ecc.) per indovinare il testo in chiaro. Gli aggressori potrebbero anche forzare la forza bruta ogni combinazione di lettere, numeri e caratteri speciali, ma questo non è comune, perché è meno efficiente di un elenco di parole.

Il rallentamento dell'attacco, di solito ci basiamo su:

  • Uso di una funzione di hash avanzata (Bcrypt anziché MD5)
  • Salatura delle singole password (per forzare gli attaccanti alla forza bruta uno per uno)
  • Impedire agli utenti di utilizzare password deboli
  • Impedire agli utenti di utilizzare password in precedenti violazioni dei dati (perché l'elenco di parole è composto da password precedentemente violate).

Per gli ultimi 2, NIST consiglia quanto segue:

Durante l'elaborazione delle richieste per stabilire e modificare i segreti memorizzati, i verificatori DEVONO confrontare i potenziali segreti con un elenco che contiene valori noti per essere comunemente utilizzati, previsti o compromessi. Ad esempio, la lista MAGGIO include, ma non è limitata a:

  • Password ottenute da precedenti violazioni.
  • parole del dizionario
  • Caratteri ripetitivi o sequenziali (ad esempio "aaaaaa", "1234abcd").
  • Parole specifiche del contesto, come il nome del servizio, il nome utente e i relativi derivati.

Ovviamente, i servizi dovrebbero forzare una reimpostazione della password una volta scoperta una violazione sul loro servizio.

In breve, non essere confuso dal prendere secoli per rompere le assurdità. Applicare una serie ragionevole di pratiche relative alla protezione delle password e si dovrebbe essere bravi, non affidarsi interamente a questi indicatori di sicurezza della password per determinare la propria posizione di sicurezza. Questo collegamento NIST è un buon punto di partenza.

    
risposta data 07.05.2018 - 11:03
fonte
4

La maggior parte dei consigli online sulle password è, per dirla in modo amichevole, senza fondamenta solide. Questo vale soprattutto per la cosiddetta complessità delle password, che si basa su un mito degli anni '80 e fortunatamente - dopo che l'autore originale del NIST l'ha ammesso l'anno scorso - mentre si stava allontanando.

Puoi non fare una stima della forza della password senza capire quali sono le tue minacce. Tutti i banali calcolatori online non hanno senso perché fanno solo alcuni calcoli senza considerare quello che stai cercando di proteggere contro .

La tua minaccia potrebbe essere brute-forcing . In tal caso, la prima cosa da fare è non permettere attacchi di forza bruta. Se qualcuno inserisce una password errata cento volte e non lo stai bloccando, stai facendo qualcosa di sbagliato che non ha nulla a che fare con la forza delle password. La seconda cosa da fare è length > complessità (mettilo in Google, ottimo articolo).

Se la tua minaccia è un attacco del dizionario sugli hash delle password, la prima cosa da fare è proteggere adeguatamente gli hash. Il secondo è il corretto salt e hash con una funzione di hash corretta (bcrypt, scrypt, ecc.) Non MD5 o SHA1). Il terzo è di non consentire parole e permutazioni semplici del dizionario. Usa la stessa logica usata dai cracker, alcuni sono disponibili pubblicamente.

Se la tua minaccia è composta da adesivi a sfioramento o post-it, devi evitare l'applicazione della complessità assurda e assicurarti che gli utenti possano effettivamente ricordare le loro password e digitarle rapidamente. Ancora una volta, lunghezza > complessità. Imposta la lunghezza minima di 12 caratteri, ma consenti parole composte.

E così via ...

In breve: considera le tue minacce, non fidarti delle stime matematiche banali.

    
risposta data 06.05.2018 - 22:50
fonte
4

Just out of curiosity, I checked this on a very well known website (on its login page), and it stated that this would take centuries to break.

Tali affermazioni sono sempre molto discutibili.

Il problema fondamentale è che per calcolare quanto tempo ci vuole un utente malintenzionato per rompere una password è necessario un modello dell'attaccante.

Un utente malintenzionato idealizzato proverà le password in ordine dal più probabile al meno probabile. Ovviamente un vero aggressore non sa quanto sia probabile una determinata password, quindi devono indovinare, tipicamente combinano una sorta di dizionario (che se l'attaccante è in qualche modo concorrente conterrà molto di più delle normali parole inglesi) con un mazzo di regole di generazione.

Il problema è che i modelli di attacker utilizzati dai misuratori di forza delle password sono spesso molto più avanzati rispetto agli effettivi attaccanti nella dimensione dei loro dizionari e alla complessità delle loro regole.

Il problema fondamentale con le restrizioni della password è che qualsiasi restrizione che fai agli utenti spesso fa il minimo indispensabile per far passare la password.

Ora questo può aggiungere un po 'di entropia, normalmente c'è più di un modo minimo per mutare una password in modo che passi le regole, ma l'entropia aggiunta è molto più piccola di quanto un'analisi ingenua possa suggerire. Ad esempio, se imponi agli utenti di aggiungere un numero alla propria password, è probabile che un numero sproporzionato di essi scelga 1.

    
risposta data 07.05.2018 - 15:41
fonte
3

È probabile che tu sia confuso a causa del presupposto che sia possibile definire a priori la vulnerabilità delle password. Al contrario, dipende in gran parte da quale schema un attaccante effettivo proverebbe per primo. L'hacker opportunista probabilmente proverebbe prima un dizionario o un elenco di password trapelate. Ma inserendo anche uno sforzo moderato, possono essere abbastanza precisi. Questo è un motivo per cui è una battaglia persa per far rispettare le linee guida sulle password. La maggior parte delle linee guida incoraggia gli utenti a seguire determinati requisiti minimi quando scelgono le loro password. Questo può aiutare a forzare i bruti a forzarli . Ad esempio,

  • una lunghezza minima della password di X caratteri consente a un utente malintenzionato di evitare di provare tutte le password più brevi di X e di concentrarsi invece sulle password di lunghezza X, X + 1 o X + 2 assumendo che molti utenti soddisfino solo il requisito di lunghezza minima.

  • Applicando un modello come "lettere minuscole, maiuscole, numeri e caratteri speciali", un utente malintenzionato può presumere che ci siano utenti che ottengono la password usando esattamente questo modello .

  • Sarebbe possibile dare loro un feedback se la loro password fosse una password trapelata, ma sussiste il rischio che finiscano per modificarla fino a quando non passa. Ancora una volta, questo è un suggerimento per gli aggressori su come indirizzare la loro forza bruta.

  • La lunghezza massima è piuttosto ovvia. Nel migliore dei casi, una lunghezza riduce il vantaggio dell'utilizzo di gestori di password. Nel peggiore dei casi, possono suggerire i limiti tecnologici sottostanti del sistema di accesso. Inoltre, posizionano un limite superiore nello sforzo peggiore che un attaccante deve spendere.

risposta data 05.05.2018 - 15:39
fonte
1

Per determinare quanto sia difficile craccare una password, devi conoscere la sua entropia, che ovviamente questi siti non possono sapere. Fanno la loro ipotesi migliore e poi la restituiscono come risultato.

Per calcolare correttamente l'entropia di una password, devi presumere che l'autore dell'attacco sia a conoscenza di come è stata creata la password come ha fatto il creatore. Se il creatore include sempre una delle due parole di 10 lettere, allora l'attaccante deve sapere che una di quelle parole sarà presente e quali sono.

Da questo puoi vedere che il pattern è un'entropia molto bassa (non più di 7 bit). Ma dal momento che i siti web non lo sanno, lo considerano molto più alto. Se vuoi una buona password, devi avere casualità. Come convincere un utente ad accettare e includere casualità nella password è un problema. Meglio cercare di capire come ottenere qualcun altro a fare la password o la password equivalente.

    
risposta data 08.05.2018 - 03:51
fonte

Leggi altre domande sui tag