Domanda:
Cosa c'è di peggio per la sicurezza della password, una politica delle password scadente o nessuna politica per le password?
Bob Ortiz
2016-07-26 18:56:15 UTC
view on stackexchange narkive permalink

Recentemente ho visto il seguente screenshot su Twitter, che descrive una politica per le password ovviamente terribile:

bad password policy

Mi chiedo cosa sia peggio per la forza della password. Non hai alcuna politica per le password o una politica delle password scadente (come descritto nello screenshot)?

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/43084/discussion-on-question-by-kevin-morssink-what-is-worse-for-password-strength-a).
Dieci risposte:
#1
+97
Josef says Reinstate Monica
2016-07-26 19:42:30 UTC
view on stackexchange narkive permalink

La domanda è: peggio per cosa?

Con la politica che hai pubblicato, le possibili password sono inferiori a 64⁸ (~ 2.8 * 10¹⁴). In pratica, molte password saranno probabilmente [az] * 6 [0-9] [carattere speciale] (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¹². È molto meno delle password con lunghezza 8, quindi non aumenta molto la sicurezza per consentirle. (Consentire password più lunghe ovviamente aumenterebbe molto la sicurezza)

Senza alcuna politica, molte persone useranno anche password sbagliate, certo. Ma un aggressore non può esserne sicuro. Inoltre alcune persone useranno password migliori.

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

Direi che una politica delle password sbagliata è peggio. Ma dipende dallo scenario di attacco.

Con un dump di hash delle password, senza una policy sulle password è molto probabilmente più facile violare qualsiasi password ma più difficile da crackare la maggior parte delle password. Con una cattiva politica come quella fornita , è più facile decifrare tutte le password ma leggermente più difficile decifrare la prima, molto probabilmente.

Se la tua preoccupazione è quanto sia difficile decifrare la tua password, senza alcuna politica puoi utilizzare un Password casuale di 20 caratteri se lo desideri. Con la politica in atto, sei costretto a utilizzare una password non sicura. (in pratica, è più rilevante il modo in cui vengono memorizzate le password e così via, ma qui non è nell'ambito). Quindi, come utente del sito web / servizio, una cattiva politica per le password è molto peggio.

Se la guardi da un punto di vista organizzativo, una cattiva politica per le password è molto peggio di niente.

Nessuna politica sulle password significa, probabilmente nessuno ci ha pensato (non è molto positivo che non pensino alla sicurezza, ma ok ...)

Ma una cattiva politica sulle password significa: Qualcuno ci ha pensato e ha inventato quella merda. Ciò significa che probabilmente non hanno la più pallida idea della sicurezza.

Alla fine, se puoi implementare una politica delle password sbagliate, puoi anche implementarne una buona, quindi non ci sono mai scuse per una politica delle password sbagliate. La semplice modifica del criterio in "La password deve contenere almeno 8 caratteri" aumenterebbe notevolmente la sicurezza e non è difficile.

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/43083/discussion-on-answer-by-josef-what-is-worse-for-password-strength-a-poor-passwo).
Non è possibile visualizzare la cronologia chat
#2
+38
Bryan Field
2016-07-26 20:30:43 UTC
view on stackexchange narkive permalink

Ora mi chiedo cosa sia peggio per la sicurezza della password. Non hai alcuna politica per le password o una politica delle password scadente come nell'immagine?

I requisiti di sicurezza della password che hai menzionato fanno assolutamente più male che bene , soprattutto il massimo length.

  1. Potrebbero usare una routine di 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,
    non fa distinzione tra maiuscole e minuscole, quindi ci sono nessuna chiamata all'assistenza per il blocco delle maiuscole)
  3. Altri elementi sono semplicemente stupidi.

Analisi dettagliata

La tua password deve:

  • Essere lungo esattamente otto caratteri

L'unica volta in cui posso vederla come una soluzione ragionevole è quando il sistema sta eseguendo un schema hash precedente che tronca tutti i caratteri tranne i primi 8.

Ad esempio, le password degli account utente di Solaris 10 utilizzavano tale schema per impostazione predefinita, quindi password come passwordSup @ rsecur☺ sono state troncate alla password !!! L'impostazione predefinita per Solaris 11 non presenta questo difetto.

In questo caso

  1. Gli sviluppatori dovrebbero lavorare sulla migrazione a una routine hash migliore che supporti le lunghezze delle password oltre 8.

  2. Fino a quando non viene implementata una tale correzione, la lunghezza massima è ragionevole.

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

  • Includere almeno una lettera e un numero.

  • Includere almeno un carattere speciale dal seguente insieme: ...

Questi sono un must data la loro breve lunghezza massima. Sono sicuro che puoi capire la necessità di utilizzare metodi così primitivi per aumentare l'entropia quando viene utilizzata una password breve.

  • Nota: la password non fa distinzione tra maiuscole e minuscole.

Anche se questo può essere conveniente per l'utente (non preoccuparti del blocco delle maiuscole), non è mai raccomandato poiché riduce sempre l'entropia della password. In questo caso è ancora più sconsigliato 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 insicura!

Non contiene spazi

L'unico motivo che vedo è se stanno presentando la password in testo normale . (ad es. email della password dimenticata o ricerca del supporto tecnico) Per la maggior parte degli standard si tratta di una progettazione software scadente (non sicura).

Una politica migliore è quella di vietare le ricerche e consentire solo che venga modificata. In effetti, si consiglia vivamente di utilizzare un hash della password forte (lento) come BCrypt che proibisce intrinsecamente le ricerche come parte del suo design principale.

  • Non iniziare con ? o !

Molto strano, ma non un killer significativo dell'entropia delle password.

  • Non iniziare con tre caratteri identici

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.

  • La password deve essere diversa dalle tue precedenti 5 password.

Probabilmente c'è una domanda dedicata a Security Stack Exchange per questo argomento. Questa è una pratica comune per l'online banking e alcuni altri sistemi di autenticazione.

Presumo che questo sia anche associato a un cambio programmato obbligatorio della password. I probabili risultati sono:

  • Gli utenti scriveranno la propria password invece di usare la memoria,
  • Oppure gli utenti sceglieranno uno schema semplice.

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

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

e sebbene questo non sia un problema serio, è disapprovato.

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/43362/discussion-on-answer-by-george-bailey-what-is-worse-for-password-strength-a-cacca).
#3
+15
O'Niel
2016-07-26 19:51:07 UTC
view on stackexchange narkive permalink

Una cattiva politica come questa è peggio di niente.

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

le persone che utilizzano comunque password deboli verranno violate anche in questo caso (perché questa politica restrittiva e debole e l'attaccante è in grado di impostare regole di attacco specifiche). Ma anche le persone che normalmente utilizzano password complesse lo faranno.

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

#4
+6
LvB
2016-07-26 19:50:02 UTC
view on stackexchange narkive permalink

a mio parere non averne nessuno sarebbe meglio Un elenco di ragioni sono:

  • Queste politiche fanno sì che le persone tendano a scrivere lì le password e ad attaccarle ai monitor o simili. (che sicurezza fornisce una password se non?)
  • Queste regole sono facilmente deducibili e (usando questo tipo di scatole) persino annunciate a qualsiasi potenziale intruso. (Ad esempio, diamo alla persona che vogliamo tenere fuori le "regole" di come sono le nostre password in modo che debbano fare solo un set limitato ...)
  • L'entropia di una password migliora significativamente rendendole più a lungo. 8 è abbastanza banale in questi giorni 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 sia fissata in una forma di testo semplice (anche se l'archiviazione è crittografata, la maggior parte delle volte la chiave di crittografia viene archiviata con i dati, il che significa effettivamente che sono archiviati in testo non crittografato).
  • Per la maggior parte delle applicazioni uno schema diverso consentirebbe una sicurezza molto maggiore senza che richiede una password, come:
    • Autenticazione a 2 fattori.
    • Autenticazione del dispositivo secondario.
    • Autenticazione con smart card.

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

detto questo può esserci una vera ragione per cui lo hanno fatto. alcune certificazioni e usi richiedono che alcuni di questi siano implementati (si pensi al settore sanitario o ad alcuni usi governativi).

Se hai bisogno di postare qualcosa sul tuo monitor: crea una password da qualcosa di facile da ricordare che solo tu conosci e una sequenza casuale.Pubblica in sequenza casuale sul tuo monitor.Gli hacker fuori non possono vedere la nota.Dentro di te si spera che non ci siano hacker in grado di capire la tua parte facile da ricordare.Non è una buona soluzione, ma molto molto meglio della tua password completa a disposizione dei tuoi colleghi.
Questo è un cattivo consiglio.è meglio NON annotare MAI le password.E se li hai annotati, NON conservarli con una macchina su cui sono usati.(come un post-it sullo schermo).Non c'è differenza tra un hacker esterno e un hacker interno, e l'ingegneria sociale è il modo preferito per ottenere password (poiché lascia poche tracce)
#5
+4
dandavis
2016-07-26 19:53:07 UTC
view on stackexchange narkive permalink

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

Tutte le combo di 8 caratteri possono essere testate in un secondo con una GPU della famiglia Titan e John the Ripper. Sebbene non tutte le politiche sulle password siano dannose (la lunghezza minima è buona, un carattere + speciale forza un alfabeto crack più grande, nessuna parola del dizionario, ecc.), Quello mostrato è uno scherzo che non è molto divertente. In sintesi, sì, è peggio di niente perché non consentirà ai gestori di password o agli utenti intelligenti di proteggersi meglio della politica predefinita.

Le politiche non dovrebbero mai bloccare le password buone, ma solo quelle terribili.

GPU della famiglia Titan?Dubito che ne abbiate anche bisogno viste le nuove GPU 14 / 16nm in questi giorni.Una Radeon RX 480 da $ 200 (con 5.8 GFLOPS!) Probabilmente brucerà le password come niente.
La richiesta di un carattere speciale in realtà non forza un alfabeto crack più grande: nel mondo reale, ci sarà esattamente un carattere speciale, e quasi sempre arriverà alla fine della password (a volte verrà all'inizio).Inoltre, nel mondo reale, quell'unico simbolo sarà solitamente un "!", Mentre il resto è selezionato da "? @ # $% & *" - questo in realtà * riduce * la dimensione dell'alfabeto, perché l'attaccante sa chesolo otto opzioni per il personaggio finale.
#6
+3
David Richerby
2016-07-28 01:46:35 UTC
view on stackexchange narkive permalink

Cosa c'è di peggio per la sicurezza della password, una politica delle password scadente o nessuna politica per le password?

Dipende da qual è la politica delle password scadente.

  • "La tua password deve essere 'letmein'" è una politica per le password scadente che è decisamente peggio che non avere alcuna politica, poiché impedisce a chiunque di avere una buona password.

  • "La tua password deve contenere almeno due caratteri" è una politica delle password scadente che è decisamente meglio che non avere alcuna politica, poiché consente a chiunque di utilizzare una buona password e previene alcune password errate. p>

#7
+1
Evan Steinbrenner
2016-07-30 00:34:37 UTC
view on stackexchange narkive permalink

Ci sono già molte buone risposte, ma mi piace sempre guardarle da una prospettiva leggermente diversa. Quando si considera come qualcosa influenzerà i tentativi di crackare una password, è necessario considerare come cercheranno di eseguire tale cracking. Fondamentalmente questo si riduce a due metodi. Forza bruta e supposizioni "intelligenti", quindi diamo un'occhiata a quei due.

1) Forza bruta.

Questo è esattamente quello che sembra. Provano ogni possibile password. Questo è il classico tentativo di provare tutti i pin da 0000 a 9999 su un blocco numerico a 4 cifre. I fattori chiave qui sono il numero di password possibili e il tempo necessario per provare ciascuna ipotesi. Qui la regola della password potrebbe essere ottima ed 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 sufficientemente debole e potrebbe garantire che ogni possibile password venga violata in un ragionevole lasso di tempo a un attaccante con risorse sufficienti.

Date le regole in questo caso sembra Suggerisco caldamente qualcosa di abbastanza vecchio sul back-end è del tutto possibile, se non probabile, che la password sia hash con qualcosa di abbastanza debole come MD5 o SHA1 e probabilmente non salata e le regole potrebbero essere catastrofiche. Principalmente la lunghezza, ma non distingue tra maiuscole e minuscole, il 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 facessero distinzione tra maiuscole e minuscole.

Sulla base di alcune ricerche rapide sembra che se assumiamo un attaccante con una quantità ragionevole di risorse e che stia utilizzando uno di quegli hash deboli, sembra molto è probabile che le regole siano davvero catastrofiche e se non lo sono ora corrono sicuramente il rischio di diventare catastrofiche nel prossimo futuro poiché la potenza di calcolo aumenta il tasso di cracking. Potrebbe essere richiesta una password più lunga di 8 caratteri per essere sicura, ma in realtà non la consente.

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

2) Indovinare "intelligente"

Ad un certo punto il metodo della forza bruta diventa poco pratico, ci vorrebbero mesi per testare tutte le password, o impossibile, ci vorrebbero millenni per testarle tutte, e la supposizione "intelligente" prende il sopravvento. Qui è dove vengono visualizzati gli attacchi al dizionario, parole letterali dal dizionario o elenchi di password utilizzate in precedenza e attacchi basati su regole. Gli attacchi basati su regole prendono il dizionario e iniziano ad aggiungere o modificare cose per apportare diverse varianti di quelle password. Aggiungendo 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. Rendere la password "leet" trasformando la password in p @ ssw0rd che sarebbe una password valida ma rapidamente decifrata in questo sistema, ecc. Queste regole possono essere quasi qualsiasi cosa tu possa immaginare che ritieni abbia senso e si evolva costantemente man mano che impariamo di più su come le persone tipicamente scelgono le loro password sulla base di fughe di notizie passate.

Supponendo che il cracking sia arrivato a questo punto, le regole per le password che hanno fornito sarebbero finite per incorporare nelle regole che l'attaccante ha usato per generare la loro possibile password. Qui le loro regole non sono così catastrofiche ma porterebbero comunque a password possibili molto meno valide, quindi accelererebbero il cracking. Probabilmente porterebbe anche ad alcune password molto prevedibili con simboli / numeri aggiunti all'inizio / alla fine della password o come parte di una sostituzione molto prevedibile.

#8
  0
Peter Green
2016-07-27 17:39:07 UTC
view on stackexchange narkive permalink

Se gli utenti scegliessero le password in modo casuale, i criteri delle password peggiorerebbero la sicurezza limitando la scelta delle possibili password, ma gli utenti non scelgono le password in modo casuale. Lo scopo di una buona politica delle password dovrebbe essere quella di spingere un utente a fare più scelte e quindi scegliere una password più forte senza limitare indebitamente lo spazio della password.

Questa politica ha aspetti positivi e negativi.

essere lungo esattamente 8 caratteri

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

Includere almeno una lettera e almeno un numero.

Questo è positivo, spinge gli utenti a scegliere sia un componente basato su lettere che un numero a base di componenti.

La password non fa distinzione tra maiuscole e minuscole.

Ciò riduce in modo significativo la dimensione della password impostata. D'altra parte la maggior parte delle persone non usa le maiuscole a meno che non sia costretta comunque e quando le usa tende a farlo in modi prevedibili.

Includere almeno un carattere speciale

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

Spazi e regole proibiti su? e !

Dubito che questi facciano molta differenza.

caratteri ripetuti vietati all'inizio

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

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

Lo spazio/?!regola non è male _per se_, ma le sue implicazioni sono terrificanti.Suggerisce fortemente che stiano facendo qualcosa con la password in chiaro all'interno dell'applicazione che alcuni caratteri potrebbero rompere.Mi spaventa meno di "non deve contenere un apostrofo", ma non di molto.Anche l'insensibilità tra maiuscole e minuscole e la lunghezza massima potrebbero suggerire la memorizzazione del testo in chiaro.
"una lunghezza massima è cattiva" -> "una lunghezza massima è cattiva"?
#9
  0
MikeP
2016-07-28 08:29:50 UTC
view on stackexchange narkive permalink

Seguirò una strada diversa rispetto a tutte le altre risposte finora ... e dico che a un certo punto non importa. L'algoritmo è MOLTO più importante delle regole delle password.
Ad esempio, qualcuno potrebbe usare ROT13, terribile, sì.
Oppure, migliorare un po 'l'uso di MD5.
O, meglio ancora, SHA-1.
Forse poi aggiungono sale.
Forse usa crypt ().
Magari poi aggiungi pepe.
Tuttavia, un GPGUP può bruciare miliardi di hash di password in un secondo. Allora, che altro?
SHA-2-512 con 128 bit di sale. Molto meglio, comunque, GPGPU può fare molte di queste cose.
Cambia in bcrypt. Molto meglio. Ora, stiamo superando il punto in cui una singola GPGPU può masterizzarli tutti velocemente.
Passa a PBKDF2, con sale e pepe e 10.000 round.
Fino a che per scrypt, e ora una password molto breve è 'uncrackable' poiché l'algoritmo è molto lento.

Ecco una tabella che potrebbe aiutare a spiegarlo:

  Tentativi / secNTLM 350.000.000.000 MD5 180.000.000.000 SHA1 63.000.000.000 SHA512Crypt 364.000 Bcrypt 71.000  

Quindi, una password scadente con hash con bcrypt è meglio di una grande con hash con MD5.

#10
  0
Verbal Kint
2016-08-03 19:02:10 UTC
view on stackexchange narkive permalink

Dipende davvero dall'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 una politica formale sulle password, almeno restrittiva.

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

Certo, l'ultima parte è chiave, come se l'utente non ne sapesse niente di meglio, dovresti costringerlo ad avere una password più sicura di quella che vuole usare. Tuttavia, una policy sulle password dovrebbe solo incoraggiare password più sicure e non limitare la robustezza della password, come illustra il tuo esempio.

Mi sono imbattuto in questo personalmente con il sito web della mia università. La mia password alfanumerica di notevole lunghezza non soddisfaceva la politica delle password, il che scoraggiava alcuni (ma non tutti: /) caratteri speciali. Il risultato è stata una password volutamente più debole, poiché per me era più difficile ricordare una password che non avevo intenzionalmente memorizzato.

E soprattutto in quel caso, sospetto che la "politica delle password" fosse più una scusa per evitare un po 'di analisi / sanificazione delle stringhe sul backend che un modo legittimo per incoraggiare una maggiore sicurezza.

Infine, le politiche sulle password, se implementate, dovrebbero cambiare nel tempo. Cioè, quella che avrebbe potuto essere considerata una password sicura negli anni '90 non lo è più nel 2016, quando il consumatore medio può sfruttare il cloud computing o i cluster GPU per lanciare un'enorme e sempre crescente quantità di potenza del computer alle tue password.



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...