Domanda:
Quanto dovrebbe essere la lunghezza massima della password?
Mohamed
2010-11-12 10:22:36 UTC
view on stackexchange narkive permalink

La lunghezza minima della password consigliata è di circa 8 caratteri, quindi esiste una lunghezza massima standard / consigliata per la password?

Questa domanda sembra essere diventata la domanda canonica su questo sito per "quanto deve essere lunga la mia password utente?", Ma la maggior parte delle risposte sembra concentrarsi sulle politiche dell'amministratore, non sulla lunghezza consigliata per un utente.Qualcuno con abbastanza influenza può creare una nuova domanda indirizzata a quella successiva e correggere i collegamenti duplicati?Mi porrei la domanda da solo, ma probabilmente verrebbe abbattuto come un duplicato.
Il motivo per cui una domanda del genere non è necessaria è in [questo meta post] (https://security.meta.stackexchange.com/a/2775/149193).
La lunghezza minima della password NON è un numero impostato.Chiunque ti fornisca un valore impostato oggi non è corretto domani poiché la potenza di elaborazione aumenta: 8 non è un minimo valido da un po 'di tempo.Max sarebbe determinato dall'implementazione della piattaforma o dell'applicazione.
Dodici risposte:
#1
+20
Rory McCune
2010-11-12 14:40:31 UTC
view on stackexchange narkive permalink

La risposta a questa, come molte domande in Sicurezza è "dipende".

Ci sono diversi fattori da considerare quando si guarda alla lunghezza della password. Il primo è alcune delle cose contro le quali una password lunga è progettata per proteggersi, che è generalmente una forza bruta di attacco per indovinare la password (online o offline).

Per indovinare la password online, se hai ha una politica di blocco relativamente aggressiva (ad esempio, 3 tentativi errati e quindi un blocco indefinito) quindi è improbabile che gli attacchi contro un singolo account abbiano successo a meno che l'attaccante non abbia una buona idea di quale sarà la password.

Se stai cercando attacchi contro una vasta popolazione di utenti con la stessa politica di blocco, in cui l'aggressore può elaborare i nomi utente (ad es. forum web), l'elemento più importante è probabilmente che le password utilizzate non sono di quelle veramente comuni.

Per inciso, una cosa da tenere d'occhio sul lato del blocco dell'account, è che le politiche aggressive qui per le applicazioni online possono rendere un attacco Denial of Service abbastanza facile, senza ulteriori contromisure.

Se c'è il rischio di forza bruta offline, stringi la password gth diventa più importante. il problema qui è che il miglioramento della potenza di elaborazione e dei metodi di attacco lo rendono un bersaglio mobile in termini di forza. Realisticamente, direi che staresti osservando più di 10 caratteri e una forte applicazione del fatto che le password non sono negli elenchi di dizionari comuni (come @andy dice che le passphrase sono una buona opzione qui).

Un altro fattore da considerare qui è la tua base di utenti e come viene utilizzata l'applicazione. In alcuni casi, direi che requisiti di password molto complessi possono effettivamente portare a un'applicazione meno sicura. Se hai un'applicazione in cui gli utenti si trovano nello stesso posto (ad esempio, molte applicazioni aziendali) e rendi la politica delle password molto "forte" (sia in termini di lunghezza della password che di requisiti di rotazione), allora è probabile che gli utenti inizieranno annotare le proprie password, il che probabilmente vanifica uno degli obiettivi di sicurezza per quell'applicazione in primo luogo.

Una buona fonte di molte più informazioni su questo è un libro chiamato Authentication: From Passwords alle chiavi pubbliche

"Molti esperti di sicurezza come Bruce Schneier consigliano alle persone di utilizzare password troppo complicate da memorizzare, annotarle su carta e conservarle in un portafoglio". - http://en.wikipedia.org/wiki/Password#Write_down_passwords_on_paper
#2
+19
Andy
2010-11-12 11:24:58 UTC
view on stackexchange narkive permalink

Finora buone risposte, ma vorrei suggerire un'altra possibilità: passphrase. Come suggerisce lo stesso Jeff Atwood di StackOverflow, se non sei vietato dalle limitazioni tecniche, potresti considerare di consentire e suggerire passphrase. Potresti applicarli, ma questo probabilmente allontanerebbe alcuni utenti sulla maggior parte dei siti. A causa della loro lunghezza, possono essere molto più difficili da decifrare e possono anche essere più facili da ricordare rispetto a una password come "A1lUrB @ se!" o cose del genere.

Questo è un commento, non una risposta.
#3
+16
Doug Kavendek
2010-11-19 23:13:51 UTC
view on stackexchange narkive permalink

Se hai intenzione di eseguire l'hashing della password, perché impostare un limite superiore?

Non è che devi preoccuparti di raggiungere il limite massimo di caratteri nei campi di testo, basati sul web o altro. Quindi potresti plausibilmente impostare un massimo di poche centinaia di caratteri solo per limitare alcune condizioni limite di qualsiasi campo di testo che stai utilizzando.

Naturalmente, se stai parlando di generare una password, proverò ad usarlo su più siti, quindi non importa; nessuno là fuori sembra essere d'accordo su questo. Ancora peggio, ho trovato siti che hanno diversi limiti di caratteri massimi su diversi campi di input, quindi per accedere devi prima digitarlo in modo sbagliato prima di ricevere un campo diverso che consente più caratteri. Ovviamente, se ogni sito lascia che siano le capacità minime previste di un tipico campo di testo senza cercare di limitarlo artificialmente, sarebbero consentiti circa 2k caratteri e non dovresti preoccuparti di questo.

Modificato per aggiungere: qualcosa menzionato di sfuggita qui mi ha fatto riflettere:

devi adattare il lavoro di hashing a ciò che è disponibile e ragionevole sui tuoi server o dispositivi. Ad esempio, abbiamo riscontrato un bug di negazione del servizio minore in Discourse in cui consentivamo alle persone di inserire password fino a 20.000 caratteri nel modulo di accesso

Potrebbe quindi valere la pena porre un limite ragionevole su entrambi l'impostazione e il tentativo di password se si esegue l'hashing delle cose in un modo che deve essere il più costoso possibile dal punto di vista computazionale. Alcune centinaia di caratteri potrebbero ancora impedire alle cose di esplodere troppo, pur essendo ancora molto più di quanto un utente potrebbe mai provare.

"_Se hai intenzione di eseguire l'hashing della password, perché impostare un limite superiore? _" Forse perché se è troppo lungo e se è generato casualmente, la sua entropia potrebbe rivelare la qualità del tuo generatore di numeri casuali.
@Geremia Se poche centinaia di byte di password rivelano la qualità del tuo RNG, hai problemi maggiori rispetto ai limiti di lunghezza della password.Impostare una lunghezza massima inferiore in realtà non ti aiuta.
#4
+15
Alexandru Luchian
2010-11-12 10:39:47 UTC
view on stackexchange narkive permalink

Bruce Schneier ha un paio di articoli interessanti sulle politiche delle password.

Password del mondo reale, che trattano la lunghezza della password, la complessità e le password comuni.

Consigli sulle password: alcune cose da fare e da non fare, tra cui:

  • UTILIZZA un gestore di password
  • CAMBIA frequentemente le password. Cambio la mia ogni sei mesi ...
  • Non riutilizzare le vecchie password.
  • NON utilizzare password composte da parole del dizionario, compleanni, nomi di famiglia e animali domestici, indirizzi o altre informazioni personali.
  • NON accedere ad account protetti da password su reti Wi-Fi aperte o qualsiasi altra rete di cui non ti fidi, a meno che il sito non sia protetto tramite https.

e molti altri

Modifica delle password: una discussione dettagliata su quanto spesso dovresti cambiare in base all'utilizzo e all'ambiente di minaccia .

Anche http://www.wired.com/politics/security/commentary/securitymatters/2007/01/72458
-1 Sono solo io o questo non risponde alla domanda?
https://security.stackexchange.com/a/536/2572 risponde effettivamente alla domanda e bene.
#5
+8
Thomas Pornin
2013-02-02 21:01:47 UTC
view on stackexchange narkive permalink

Non dovrebbe esserci una lunghezza massima per la password: se l'utente accetta di utilizzare una password molto lunga, dovrebbe essere lodato , non bloccato .

Dato che il software è quello che è, diversi sistemi imporranno un limite alla dimensione della password, principalmente a causa di problemi con la GUI, scarsa programmazione o compatibilità con i sistemi più vecchi. Ad esempio, i vecchi sistemi Unix utilizzavano un processo di hashing delle password che utilizzava solo i primi otto caratteri e ignorava completamente tutti gli altri. Allo stesso modo, i vecchi sistemi Windows avevano un limite interno a 14 caratteri. Pertanto, è meglio che la password, una volta troncata ai primi 14 caratteri, sia ancora "forte".

Tuttavia, l'unico limite alla dimensione massima della password dovrebbe essere la pazienza dell'utente. Non ha senso applicare nulla qui.

A meno che non ci sia una buona ragione tecnica.Un esempio è l'uso di BCRYPT da parte di PHP significa che le password vengono troncate oltre i 72 caratteri.
#6
+3
tylerl
2013-02-02 22:14:21 UTC
view on stackexchange narkive permalink

Un minimo comune oggi è di 12 caratteri, che è appena abbastanza grande da impedire il cracking di forza bruta da parte di un'organizzazione ragionevolmente ben finanziata entro un ragionevole lasso di tempo.

Per quanto riguarda la lunghezza massima; ecco alcuni pensieri: una password più lunga di poche centinaia di byte è quasi certamente dannosa (ad es. tentativo di SQL injection). Nota anche che se stai eseguendo l'hashing della tua password (e se non lo sei, devi ricominciare da capo), le password più lunghe del tuo output hash non aggiungono più entropia. Nota che con "più lungo" intendo lo stesso numero di bit nel tuo spazio delle chiavi, non la stessa lunghezza di caratteri. Quindi, mentre consentire password più lunghe della lunghezza dell'hash dovrebbe essere consentito come punto di comodità, non avrebbe senso dal punto di vista matematico che una cosa del genere sia richiesta .

La richiesta di lettere maiuscole e minuscole raddoppia la dimensione del tuo alfabeto, il che produce enormi rendimenti di complessità e probabilmente dovrebbe essere richiesto. La richiesta di caratteri numerici aggiunge forse il 20% in più al tuo alfabeto, il che non è un grosso problema, e la richiesta di simboli aggiunge forse dal 16% al 40% in più (a seconda dei simboli che conti), e ancora, no un rendimento altrettanto significativo, ma certamente non dovrebbe essere vietato.

Non avrei bisogno di maiuscole e minuscole o qualsiasi altra classe di caratteri. Preferisco usare una sorta di stimatore di entropia sulla password e quindi richiedere un valore minimo per il suo output. Quindi gli utenti che utilizzano meno classi di caratteri necessitano di una password più lunga per compensare.
E se abbandonassimo la punteggiatura perché alcune persone annotano le password e i punti e virgola scritti sembrano due punti, i punti sembrano virgole, ecc. leggere la punteggiatura. Ovviamente gli aggressori dovrebbero andare avanti e presumere che ci sia la punteggiatura.
#7
+2
Sairam
2010-11-12 10:56:07 UTC
view on stackexchange narkive permalink

Personalmente preferirei utilizzare un generatore di password (come lastpass.com o 1password) per generare e utilizzare password di minimo 8 caratteri e massimo 32 caratteri (poiché non tutti i siti supportano una lunghezza della password superiore a 10 o 15) e utilizzare una password principale per l'autenticazione (dipende ancora dalla tua fiducia su siti come lastpass.com) o un'utilità 1password crittografata lato client per Mac e Windows).

Non è consigliabile utilizzare un set di password per tutti i siti. I forum in particolare mi inviano tramite posta elettronica le password in testo normale. Alcuni siti hanno la funzione di inviare una semplice password nel caso in cui utilizzi la funzione "Password dimenticata".

Di solito, le restrizioni vengono impostate sul server (per i siti web). Dobbiamo incolpare i server che utilizziamo per non impostare restrizioni sulle password degli utenti.

In breve, utilizza ogni volta password diverse. Se hai più di 10-15 password da ricordare, è tempo di iniziare a utilizzare un gestore di password "sicuro". (Per la cronaca, il password manager di Firefox non è affatto sicuro)

A proposito, se un server ha una restrizione sulla lunghezza della password, di solito è a causa di altre vulnerabilità: ad es. la password è memorizzata in chiaro, e quindi il campo del database assegnato è ciò che limita la lunghezza.
Puoi spiegarci che il gestore di password di Firefox non è sicuro?
Firefox e altri browser come Chrome e IE hanno un gestore di password, ma le password possono essere facilmente recuperate e lette da addon, plugin e altri software sul tuo sistema. Firefox ha una funzione per proteggere il gestore delle password con una password principale. Mi chiedo se AviD o qualcun altro commenterebbe la sicurezza di FF con la funzione di password principale abilitata.
#8
+2
Roger C S Wernersson
2010-11-17 13:45:28 UTC
view on stackexchange narkive permalink

16 caratteri.

Questo ti dà 96 bit secondo Wikipedia, che è ben oltre qualsiasi cosa crackabile secondo quell'articolo.

Personalmente uso un programma di password per il mio cellulare, combinato con la funzione Master Password di Firefox. La mia password principale ha più di 25 caratteri e si basa su Dice Ware, il che lo rende abbastanza facile da ricordare. Quasi tutte le mie password vengono rigenerate in modo casuale, dato che Firefox le ricorda comunque per me.

Consiglio terribile, 16 caratteri sono troppo piccoli se vuoi usare una combinazione di parole separate da spazi, che sono di gran lunga più sicure. Non voglio essere costretto a utilizzare alcuna funzione di password principale per la mia e-mail e ha 35 caratteri.
Concesso. Stavo cercando una risposta breve e utile. 16 caratteri casuali, maiuscole e minuscole, numeri e caratteri speciali sono un buon minimo. Cinque parole diceware sono superiori a questo.
Ma * perché * è abbastanza?Mi piace che sia una risposta pratica, ma penso che dovrebbe essere supportata da una spiegazione.
Sarebbe una domanda diversa.La risposta dovrebbe essere nell'articolo di Wikipedia a cui mi collego.
#9
+1
geoffc
2010-11-19 23:43:26 UTC
view on stackexchange narkive permalink

Ero presso un cliente in cui il responsabile della sicurezza era pazzo. Voleva utilizzare ogni singola politica di complessità delle password possibile. (Novell eDirectory ha MOLTI problemi di complessità delle password e voleva utilizzare un plug-in aggiuntivo per aggiungerne altre!)

Al punto che sarebbe impossibile generare una password che possa essere ricordata. Mi aspettavo che le masse non lavate lo trovassero e lo catramassero e lo coprissero di piume dopo che è stato implementato.

In altre parole, puoi andare troppo lontano.

Scusa, mi hai perso da qualche parte.Hai detto "era impossibile generare una password che possa essere ricordata".Questo ha senso.Ma poi dici: "In altre parole, puoi andare troppo lontano".Capisco che tu l'abbia trovato fastidioso, ma la domanda è quanto dovrebbe essere forte una password.Hai scoperto che questo criterio causava password più deboli e quindi una minore sicurezza?O ha danneggiato in modo significativo la produttività dell'azienda?O nessuno dei due era il caso ed era davvero una buona politica quella, nel 2010 o prima, era nuova per le persone?
#10
  0
Luc
2019-01-10 06:02:37 UTC
view on stackexchange narkive permalink

Consiglio

Nel 2019, la casualità richiesta per una password / passphrase sicura è:

  • 12 caratteri generati casualmente con lettere minuscole, maiuscole e cifre; o
  • 6 parole generate casualmente. ( Non scegliere le parole da solo! Questo crea schemi.)

È impossibile ricordarne venti, quindi memorizza solo alcune importanti che usi regolarmente . Ad esempio, potresti memorizzare quello per il tuo account di posta elettronica e quello per il tuo gestore di password. Per tutto il resto, memorizza le password in un gestore di password.

Rilevante: l'utente medio ha davvero bisogno di un gestore di password?
La risposta più votata è un chiaro "sì ".

Rilevante: Quanto sono sicuri i gestori di password?
Dalla risposta in alto, di paj28 (enfasi mia):

per la maggior parte delle persone questi rischi sono accettabili e suggerirei che l'approccio di utilizzare un gestore di password [per] la maggior parte delle tue password sia migliore rispetto all'utilizzo della stessa password ovunque - che sembra essere l'alternativa principale. Ma non memorizzerei tutte le password lì dentro; fare uno sforzo per memorizzare quelli più importanti, come l'online banking.

I gestori di password comunemente menzionati sono KeePass (X), 1Password e LastPass. Quello nel tuo browser dipende: quando usi Firefox con una password principale, è quasi uguale a usarne una dedicata. Se il tuo browser non richiede una password prima di poter accedere alle password, non è molto sicuro (ma i dettagli dipendono dall'esatta implementazione, che è un intero argomento a sé stante).

Sviluppatori

Quando crei un'applicazione, ecco alcune considerazioni utili:

Come eseguire l'hashing sicuro delle password?
Riepilogo: usa Scrypt o Argon2, tanto lentamente quanto te possono andare. Se non sono disponibili, Bcrypt o PBKDF2 sono alternative accettabili. Aggiungi sia sale e pepe.

Devo avere una lunghezza massima per la password?
Riepilogo: solo contro gli attacchi DoS, quindi pochi kilobyte.

Implementa l'hashing della password lato client
Divulgazione completa: mi collego alla mia risposta perché penso che sia il più completo. Assicurati di leggere anche le opinioni di altre persone.

Dettagli

Potresti chiederti "perché il mio codice PIN è di sole 4 cifre allora? Questo è sufficiente per proteggere il mio conto bancario!" C'è una domanda dedicata a questo, ma il riepilogo è di due cose: hai bisogno della tua carta di credito per l'accesso (un secondo fattore di autenticazione) e il chip ti blocca dopo 3 tentativi.

I siti web sono molto più indulgenti, quindi un utente malintenzionato può fare più tentativi. Inoltre, i siti Web dovrebbero essere violati prima o poi, dopodiché l'attaccante può decifrare la password con hash in modo efficiente.

La maggior parte dei siti Web memorizza la password con una sorta di crittografia unidirezionale, chiamata hashing. Non esiste una chiave di decrittazione. Applicando nuovamente lo stesso algoritmo di hashing, il sistema può confrontare la password (che hai appena digitato) con quella memorizzata (dal database) e sapere se sono uguali. Ma con solo il database, non puoi conoscere la password originale.

In passato, i metodi di hashing veloce erano comuni. Ciò significa anche che un utente malintenzionato, che ha ottenuto l'hash, può fare in modo che il suo computer esegua miliardi di tentativi al secondo su un computer da gioco medio. Supponendo dieci miliardi di tentativi al secondo, una password casuale di 11 caratteri dura per circa 165 anni. E questo è solo un giocatore, immagina di avere accesso ai dati aziendali a cui sono interessati alcuni concorrenti stranieri: con un po 'di potenza di calcolo in più, quei 165 anni si trasformano improvvisamente in alcuni mesi di cracking. E il prossimo anno ci saranno nuove CPU più veloci allo stesso prezzo, riducendo nuovamente la forza. Questo è il motivo per cui dodici caratteri sono il minimo per una password complessa: quel carattere in più aggiunge letteralmente diecimila anni al tempo di cracking (165 anni contro 10 230 anni) ed è sicuro per il prossimo futuro.

A proposito, calcolare la forza della password è facile: variant ^ length / guesses_per_time . Le variazioni sono quanti elementi unici ci sono e la lunghezza è il numero di elementi che usi. Quindi, se si utilizzano solo cifre, sono disponibili dieci variazioni (da 0 a 9). Se usi parole da un dizionario, sono comunque molte parole nel dizionario. Quindi, guesses_per_time è la velocità con cui presumi che l'attaccante possa craccare. Un valore ragionevole è decine di miliardi al secondo.
Esempio: 10 ^ 14 / 10e9 / 3600 mostra quante ore ci vorrebbero per decifrare un codice di 14 cifre, quando presumi 10e9 tentativi al secondo (ci sono 3600 secondi in un'ora, 60 * 60).

Alcuni siti web sono intelligenti e utilizzano un algoritmo di hashing lento. Non possiamo dire quali siano, perché il server fa l'hashing, quindi non puoi vederlo dall'esterno. In tal caso, il calcolo di una singola ipotesi richiederà molto più tempo (per il server, ma anche per un utente malintenzionato). In un caso ragionevole, un attaccante ben finanziato può fare solo cinquantamila tentativi al secondo, nel qual caso sarebbe sufficiente una password di 9 caratteri. Ma 9 personaggi casuali sono già molto difficili da memorizzare per molti account diversi, soprattutto se non li usi tutti regolarmente. Pertanto, è necessario un gestore di password per avere davvero una sicurezza nelle password.

Ma è davvero necessario avere password univoche? Perché non riutilizzare password complesse su alcuni siti diversi? Perché i siti web vengono spesso compromessi. Non è un evento quotidiano, ma prova a inserire i tuoi indirizzi e-mail in haveibeenpwned.com: sicuramente succede spesso. Questo è il modo in cui gli account vengono violati più frequentemente: riutilizzo della password. I compromessi dei gestori di password sono molto meno comuni.

#11
-1
Coach David
2019-01-09 23:36:01 UTC
view on stackexchange narkive permalink

Mi sembra che la lunghezza e la complessità della password siano state eccessive. Se abbinato a buone politiche di blocco, 10 dovrebbe essere più che sufficiente. Attualmente 4 numeri sono sufficienti per garantire le transazioni bancomat. Anche i blocchi del telefono partono da 4, ma spesso ne richiedono 6. La politica di blocco è la parte più importante della formula. Se richiedi a un utente di contattare qualcuno per sbloccare un account, le dimensioni possono essere inferiori. Se il blocco viene eseguito per un periodo di tempo, la password dovrebbe riflettere.

La differenza è che devi essere in possesso fisico del tuo telefono per provare a sbloccarlo.Se 10.000 persone hanno una password di 4 cifre, avresti buone possibilità di accedere a uno degli account semplicemente provando 1 password su ciascuno.
@AndrolGenhald Direi che la differenza è che hai un numero limitato di tentativi su un telefono o una smartcard (come una carta di credito o una SIM): dopo tre o cinque tentativi, sei bloccato o limitato alla tariffa.I consigli sulle password tengono presente che qualcuno potrebbe applicare il cracking online o offline, dove puoi fare da qualche parte tra 100 e alcuni miliardi di tentativi ogni secondo.Non ci sono molti siti Web che applicano la limitazione della velocità ed è meglio presumere che il database venga rubato a un certo punto.
@CoachDavid Vedi questa domanda perché non è così semplice come "4 numeri dovrebbero essere sufficienti per tutto": [Forza della password e codice a 4 pin delle banche?] (Https://security.stackexchange.com/q/61814/10863)
@Coach David - faresti meglio a porre una domanda qui se stai cercando informazioni
#12
-1
Alberto Salvia Novella
2020-02-04 01:21:57 UTC
view on stackexchange narkive permalink

I criteri che utilizzo per le password sono i seguenti:

  • Essere generato dal sito web stesso, quindi gli utenti non possono utilizzare password non sicure per impostazione predefinita.
  • Essere generato dal computer , quindi il suo schema è veramente caotico. Le password generate dall'uomo hanno schemi prevedibili.
  • Essere composte solo da lettere minuscole , quindi sono facili da ricordare e abbastanza veloci da poter essere digitate su qualsiasi tipo di dispositivo e tastiera.
  • Essere lungo 20 caratteri . Quindi ha abbastanza entropia per essere indecifrabile da una botnet quando i tentativi non sono allungati artificialmente, come quando la polizia sta cercando di decrittografare il tuo archiviazione utilizzando Echelon.

Quando scrivo la password la divido in gruppi di quattro, quindi è più facile da ricordare. Ad esempio:

  bxkx osnt spmf jmwz ivyj  


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