Che cosa è peggio per la sicurezza della password, una politica di password scadente o nessuna politica di password?

La domanda è: peggio per cosa?

Con la politica che hai pubblicato, le password possibili sono inferiori a 64⁸ (~ 2.8 * 10¹⁴). In pratica, molte password saranno probabilmente [a-z] * 6 [0-9] [carattere speciale] (ad es. Aabaab1!) E password simili.

Tutte le password possibili con gli stessi caratteri e lunghezza inferiore a 8 sono solo 64⁷ + 64⁶ + 64⁵ + ... che è ~ 4.5 * 10¹². Questo è molto meno delle password con lunghezza 8, quindi non aumenta la sicurezza molto per consentire loro. (consentire password più lunghe aumenterebbe ovviamente molto la sicurezza)

Senza alcuna politica, molte persone useranno anche cattive password, certo. Ma un attaccante non può esserne sicuro. Anche alcune persone useranno password migliori.

Senza alcuna politica, un utente malintenzionato non può mai essere sicuro di quanto sia difficile craccare una password. Se mi dai un DB di hash delle password, potrei provare a risolverlo. Ma se non ci sono risultati, dopo un po 'di tempo potrei fermarmi. Con la policy in atto posso essere sicuro che dopo 64 ^ 8 tentativi ho tutte le password.

Direi che una cattiva politica delle password è peggiore. Ma dipende dallo scenario di attacco.

Con una copia di hash delle password, senza criteri di password è molto più facile crackare qualsiasi password ma più difficile da decifrare la maggior parte delle password. Con una cattiva politica come quella data, è più facile craccare tutte le password, ma è più difficile decifrare il primo, molto probabilmente.

Se la tua preoccupazione è quanto sia difficile craccare la tua password, senza alcuna politica puoi usare una password casuale di 20 caratteri se vuoi. Con la politica in atto, sei costretto a utilizzare una password non sicura. (in pratica, è più pertinente il modo in cui le password vengono archiviate e così via, ma è fuori portata qui). Quindi, come utente del sito web / servizio, una politica di password errata è molto peggio.

Se lo guardi da un punto di vista organizzativo, una politica di password errata è peggio di niente.

Nessuna politica delle password significa, probabilmente nessuno ci ha pensato (non molto bene che non pensano alla sicurezza, ma ok ...)

Ma una politica di password errata significa: Qualcuno ci ha pensato e ha inventato quella merda. Ciò significa che probabilmente non hanno idea della sicurezza.

Alla fine, se è possibile implementare una politica di password errata, è anche possibile implementarne una buona, quindi non ci sono mai scuse per una politica di password errata. Cambiare semplicemente la politica in "Una password deve essere di almeno 8 caratteri" aumenterebbe molto la sicurezza e non è difficile da fare.

Now I'm wondering what is worse for password strength. Having no password policy at all or a poor password policy like in the picture?

I requisiti di sicurezza della password che hai citato fanno assolutamente più male che bene , in particolare la lunghezza massima.

1. Potrebbero usare una routine hash molto vecchia e insicura. (quindi una lunghezza massima)
2. In alcune aree, questo supporta la comodità rispetto alla sicurezza.
   (nessuno spazio è utile quando si rappresenta una password in testo normale,
   senza distinzione tra maiuscole e minuscole, quindi non ci sono chiamate di supporto per il blocco delle maiuscole)
3. Gli altri articoli sono semplicemente stupidi.

Scomposizione dettagliata

Your password must:

• Be exactly eight characters long

L'unica volta che riesco a vedere questo come una soluzione ragionevole è quando il sistema esegue uno schema di hash legacy che tronca tutti tranne i primi 8 caratteri.

Ad esempio, le password degli account utente di Solaris 10 hanno utilizzato tale schema per impostazione predefinita, pertanto le password come passwordSup@rsecur☺ sono state troncate in password !!! L'impostazione predefinita per Solaris 11 non presenta questa mancanza.

In questo caso

1. Gli sviluppatori dovrebbero lavorare sulla migrazione a una routine hash migliore che supporti lunghezze di password superiori a 8.

2. Finché non viene implementata una tale correzione, la lunghezza massima è sensata.

In qualsiasi altra situazione, sarebbe sicuramente una cosa stupida avere una lunghezza massima così breve.

• Include at least one letter and one number.

• Include at least one special character from the following set: ...

Questi sono un must dato la loro lunghezza massima corta. Sono sicuro che puoi comprendere la necessità di utilizzare tali metodi primitivi per aumentare l'entropia quando viene utilizzata una password corta.

• Note: the password is not case-sensitive.

Sebbene ciò possa essere conveniente per l'utente (non preoccuparti di Caps-Lock), non è mai consigliato in quanto diminuisce sempre l'entropia della password. In questo caso è ancora più scoraggiato a causa della presenza di una lunghezza massima di 8 caratteri.

Questo dovrebbe essere risolto ma ora sarebbe un problema per loro perché gli utenti esistenti sono già abituati alla configurazione non sicura!

Not contain any spaces

L'unica ragione che vedo per questo è se stanno presentando la password in testo normale. (Ad esempio, l'e-mail di password dimenticata o la ricerca del supporto tecnico) Per la maggior parte degli standard si tratta di una progettazione software scadente (non sicura).

Una politica migliore è vietare le ricerche e consentire solo che venga modificata. In realtà, si consiglia vivamente di usare un hash di password strong (lento) come BCrypt che impedisce intrinsecamente le ricerche come parte del suo design di base.

• Not start with ? or !

Molto strano, ma non un killer significativo di entropia della password.

• Not begin with three identical characters

Meh, non sono troppo preoccupato per questo, ma mi chiedo perché guardano solo all'inizio. 3 caratteri identici / adiacenti ovunque in una password di 8 caratteri sono più deboli di quanto potrebbe essere.

• The password must be different to your previous 5 passwords.

Probabilmente c'è una domanda dedicata allo Stack di sicurezza dello stack per questo argomento. Questa è una pratica comune per l'online banking e alcuni altri sistemi di autenticazione.

Suppongo che questo sia anche associato alla modifica programmata obbligatoria della password. I risultati probabili sono:

• Gli utenti annoteranno la loro password invece di usare la loro memoria,
• Oppure, gli utenti sceglieranno un modello semplice.

Tuttavia, se la modifica della password non è obbligatoria, l'unico problema è

• È necessario continuare a memorizzare il valore dell'hash delle password inutilizzate affinché il confronto funzioni.

e anche se questo non è un problema serio, è disapprovato.

Una cattiva politica come questa è peggio di nessuna.

Questa politica significa che le persone che normalmente usano "123", ora avranno una password un po 'più sicura, ma è ancora debole. Significa anche che le persone che usano qualcosa come 'fzFEZ # 5 $ 3rt4564ezezRTyht' (generato casualmente), o semplicemente: 'cat j_umps sul wall412' verniciato marrone (strong entropia), ora avranno una password molto più debole.

In questo caso, le persone che usano password deboli saranno ugualmente compromesse (perché questa politica restrittiva e debole e l'attaccante è in grado di impostare regole di attacco specifiche). Anche le persone che normalmente utilizzano password complesse lo saranno anche.

In altre parole, è molto meno sicuro. Senza alcuna politica, solo le persone che utilizzano password deboli sono vulnerabili; ora tutti sono vulnerabili.

a mio parere non avere nessuno sarebbe meglio Una lista di ragioni sono:

• Queste politiche fanno sì che le persone tendano a scrivere le password e ad attaccarle ai monitor o allo stesso modo. (quale sicurezza fa una password che fornire?)
• Queste regole sono facilmente deducibili e (usando questo tipo di box) persino annunciate a qualsiasi potenziale intruso. (Come lascia dare alla persona che vogliamo tenere fuori le "regole" di come sono le nostre password quindi devono solo fare un set limitato ...)
• L'entropia di una password migliora in modo significativo aumentandone la durata. 8 è in questi giorni abbastanza banale che un attacco potrebbe utilizzare un dispositivo mobile per forzare una password.
• la regola per mescolare i casi e non controllarli suggerisce che la password è fissata in un semplice modulo di testo (anche se la memoria è crittografata, la maggior parte delle volte la chiave di crittografia viene archiviata con i dati che in pratica significa che sono memorizzati in testo chiaro).
• Per la maggior parte delle applicazioni uno schema diverso consentirebbe una sicurezza di gran lunga maggiore senza richiedere una password, come:
  • Autenticazione fattore 2
  • Autenticazione dispositivo secondario
  • Autenticazione smart card.

Queste politiche sembrano essere pensate da qualcuno che non comprende appieno come le minacce a una password influiscono sul sistema. invece spuntano "tutte le caselle" per qualche motivo.

Detto questo, ci può essere una vera ragione per cui l'hanno fatto. alcune certificazioni e usi richiedono che alcuni di questi siano implementati (si pensi al settore sanitario o ad alcuni usi governativi).

Nessuno è migliore di quello mostrato, in particolare a causa del limite di 8 caratteri.

Tutte le 8 combinazioni di caratteri possono essere testate in un secondo con una GPU della famiglia Titan e John the Ripper. Mentre non tutte le politiche sulle password sono dannose (la lunghezza minima è buona, una + char speciale costringe un alfabeto crack più grande, nessun dizionario, ecc.), Quella mostrata è una battuta che non è molto divertente. In breve, sì, è peggio di niente perché non consente ai gestori di password o agli utenti intelligenti di proteggersi meglio della politica di default.

Le politiche non dovrebbero mai impedire buone password, solo terribili.

What is worse for password strength, a poor password policy or no password policy at all?

Dipende dal criterio della password scadente.

• "La tua password deve essere" letmein "" è una cattiva politica delle password che è decisamente peggio che non avere alcuna politica, dal momento che impedisce a chiunque di avere una buona password.

• "La tua password deve essere almeno di due caratteri" è una politica di password scadente che è decisamente meglio che non avere alcuna politica, dal momento che permette a chiunque di usare una buona password e impedisce alcune password sbagliate.

Ci sono già un buon numero di buone risposte, ma mi piace sempre guardarlo da una prospettiva leggermente diversa. Quando stai pensando a come qualcosa influenzerà i tentativi di cracking di una password, devi guardare come tenteranno di fare il cracking. Fondamentalmente questo si riduce a due metodi. Forza bruta e ipotesi "intelligenti", quindi guardiamo questi due.

1) Forza bruta.

Questo è esattamente ciò che sembra. Provano ogni possibile password. Questo è il classico che prova ogni pin da 0000 a 9999 su un blocco numerico a 4 cifre. I fattori chiave qui sono il numero di password possibili e quanto tempo ci vuole per provare ogni ipotesi. Qui la regola della password potrebbe essere ottima e eliminare completamente la forza bruta come opzione praticabile a causa del requisito di 8 cifre. Potrebbe anche essere completamente catastrofico se viene utilizzato un hash abbastanza debole e potrebbe garantire che ogni possibile password venga violata in un ragionevole lasso di tempo a un utente malintenzionato con risorse sufficienti.

Dato che le regole in questo caso sembrano suggerire strongmente qualcosa di abbastanza vecchio sul back-end, è del tutto possibile, se non probabile, che la password sia sottoposta a hash con qualcosa di abbastanza debole come MD5 o SHA1 e probabilmente non salata e le regole potrebbero essere catastrofico Principalmente la lunghezza, ma anche senza distinzione tra maiuscole e minuscole, che riduce i possibili caratteri del ~ 30%. Attualmente hanno 26 caratteri + 10 numeri + 28 simboli per 64 caratteri diversi in una password. Avrebbero 90 caratteri se fossero sensibili al maiuscolo / minuscolo.

Sulla base di alcune ricerche rapide sembra che assumendo un attaccante con una quantità ragionevole di risorse e che stiano usando uno di quegli hash deboli sembra molto probabile che le regole siano davvero catastrofiche e se non lo sono ora sono certamente in pericolo di diventare catastrofici nel prossimo futuro, mentre la potenza di calcolo aumenta il tasso di cracking. Potrebbe essere necessaria una password più lunga di 8 caratteri per essere sicura, ma in realtà non lo consentono.

È possibile applicare la forza bruta a tutte le password di 8 caratteri in un attacco offline?

2) "Intelligent" indovinando

Ad un certo punto il metodo della forza bruta non è pratico, ci vorrebbero mesi per testare tutte le password, o impossibile, ci vorrebbero millenni per testarle tutte, e prende il sopravvento "intelligente". Qui è dove si vedono gli attacchi di dizionario, sia parole letterali dal dizionario o elenchi di password precedentemente utilizzate, sia attacchi basati su regole. Gli attacchi basati su regole prendono il dizionario e iniziano ad aggiungere o modificare le cose per fare diverse varianti di quelle password. Aggiungere un numero e un carattere speciale alla fine di una parola di sei lettere per ottenere una password di 8 cifre che soddisfi i requisiti della password. Rendendo la password "leet" trasformando la password in p @ ssw0rd che sarebbe una password valida ma rapidamente incrinata in questo sistema, ecc. Queste regole possono essere praticamente qualsiasi cosa tu possa immaginare che tu pensi abbia senso e si evolva costantemente mentre impariamo di più su come le persone in genere scelgono le proprie password in base alle perdite precedenti.

Supponendo che il cracking sia arrivato a questo punto, le regole della password che hanno fornito sarebbero state incorporate nelle regole che l'utente malintenzionato aveva usato per generare la loro possibile password. Qui le loro regole non sono così catastrofiche, ma porterebbero comunque a password di gran lunga meno valide, quindi accelererebbero il cracking. Potrebbe anche portare a password molto prevedibili con simboli / numeri aggiunti all'inizio / alla fine della password o come parte di una sostituzione molto prevedibile.

Ho intenzione di seguire un percorso diverso rispetto a tutte le altre risposte finora ... e di dire che a un certo punto, non importa. L'algoritmo importa molto più delle regole della password.
Ad esempio, qualcuno potrebbe usare ROT13, terribile, sì.
Oppure, un po 'meglio usa MD5.
O, meglio ancora, SHA-1.
Forse poi aggiungono sale.
Forse usa crypt ().
Forse poi aggiungi pepe.
Ancora, un GPGUP può masterizzare miliardi di hash delle password in un secondo. Quindi, cos'altro?
SHA-2-512 con sale a 128 bit. Molto meglio, ancora, GPGPU può fare un sacco di questi.
Passare a bcrypt. Molto meglio. Ora, stiamo superando il punto in cui una singola GPGPU può semplicemente bruciarli tutti velocemente.
Passare a PBKDF2, con sale e pepe pieni e 10.000 giri.
Fino a scriverlo, e ora una password molto breve è "noncrassibile" poiché l'algoritmo è così lento.

Ecco un table che potrebbe aiutare a spiegarlo:

    Tries/sec
NTLM    350,000,000,000  
MD5     180,000,000,000  
SHA1     63,000,000,000  
SHA512Crypt     364,000  
Bcrypt           71,000    

Quindi, un hash di password schifoso con bcrypt è migliore di un hash di grandi dimensioni con MD5.

Dipende davvero all'utente finale. Per come la vedo io, se tu come azienda / sito web non sei responsabile se l'account di qualcuno è compromesso, è meglio rinunciare a un criterio formale per le password, almeno restrittivo.

Sono sempre stato dell'opinione che l'utente debba essere responsabile della propria sicurezza dato che capisce le implicazioni di cose come password deboli.

Certo, quell'ultima parte è la chiave, come se l'utente non lo sapesse meglio dovresti costringerli ad avere una password più sicura di quella che vogliono usare. Ma una politica per le password dovrebbe incoraggiare solo password più sicure e non limitare la forza della password, come illustra il tuo esempio.

Mi sono imbattuto personalmente in questo sito Web. La mia password alfanumerica di notevole lunghezza non ha soddisfatto la politica della password, che ha scoraggiato alcuni (ma non tutti: /) caratteri speciali. Il risultato era una password intenzionalmente più debole, poiché per me era più difficile ricordare una password che non ho intenzionalmente commesso per memoria.

E soprattutto in quel caso, sospetto che la "politica delle password" sia stata più di una scusa per evitare qualche parsing / risanamento delle stringhe sul back-end di quanto non fosse un modo legittimo per incoraggiare una migliore sicurezza.

Infine, le politiche sulle password, se implementate, dovrebbero cambiare nel tempo. Cioè, quella che poteva essere considerata una password sicura negli anni '90 non è più così nel 2016, quando il consumatore medio può sfruttare cloud computing o cluster GPU per gettare una quantità enorme e sempre crescente di potenza del computer nelle tue password. p>     

Se gli utenti sceglievano le password in modo casuale, le policy sulle password avrebbero peggiorato la sicurezza limitando la scelta delle password possibili, ma gli utenti non selezionavano le password casualmente. L'obiettivo di una buona politica di password dovrebbe essere quello di spingere un utente a fare più scelte e quindi scegliere una password più strong senza limitare indebitamente lo spazio della password.

Questa politica ha aspetti positivi e negativi.

be exactly 8 characters long

Una lunghezza minima è buona, una lunghezza massima è cattiva.

Include at least one letter and at least one number.

Questo è positivo, spinge gli utenti a scegliere sia un componente basato su lettera sia un componente basato su numero.

Password is not case-sensitive.

Ciò riduce significativamente la dimensione della password impostata. D'altra parte la maggior parte delle persone non usa mai le maiuscole se non costrette comunque e quando le usano tendono a farlo in modi prevedibili.

Include at least one special character

Ancora una volta, spinge il creatore della password a fare un'altra scelta.

Forbidden spaces and rules on ? and !

Dubito che facciano molta differenza.

forbidden repeated characters at start

Probabilmente una buona cosa, significa che l'utente non può semplicemente riempire la password con ripetizioni di una singola lettera.

In generale, direi che se hai utenti clueless questa politica è probabilmente meglio di niente, ma se i tuoi utenti hanno un'idea delle password decenti probabilmente farà più male che bene.