Quali motivi tecnici ci sono per avere una lunghezza massima delle password bassa?

Prendi cinque scimpanzé. Mettili in una grande gabbia. Sospendi alcune banane dal tetto della gabbia. Fornire gli scimpanzé con una scala a pioli. MA aggiungi anche un rilevatore di prossimità alle banane, in modo che quando uno scimpanzè si avvicina alla banana, i tubi dell'acqua vengono azionati e l'intera gabbia è completamente imbibita.

Presto, gli scimpanzé apprenderanno che le banane e la scala a pioli sono meglio ignorate.

Ora rimuovi uno scimpanzé e sostituiscilo con uno nuovo. Quello scimpanzé non sa niente dei tubi. Vede la banana, nota la scala a pioli e poiché è un primate intelligente, immagina di salire sulla scala per raggiungere le banane. Poi afferra abilmente la scala a pioli ... e gli altri quattro scimpanzali saltano su di lui e lo picchiano a squarciagola. Presto impara a ignorare la scala a pioli.

Quindi, rimuovi un altro scimpanzé e sostituiscilo con uno nuovo. Lo scenario si verifica di nuovo; quando afferra la scala a pioli, viene colpito dagli scimpanzè quattro - sì, incluso il precedente scimpanzé "fresco". Ha integrato la nozione di "non toccare la scala a pioli".

Itera. Dopo alcune operazioni, hai cinque scimpanzè pronti a dare un pugno a qualsiasi scimpanzè che oserebbe toccare la scala a pioli - e nessuno di loro sa perché.

Originariamente, alcuni sviluppatori, da qualche parte, stavano lavorando su un vecchio sistema Unix del secolo precedente, che usava il vecchio " crypt "basato su DES , in realtà una funzione di hashing password derivata dal codice a blocchi DES. In quella funzione di hashing, vengono utilizzati solo i primi otto caratteri della password (e solo i 7 bit bassi di ciascun carattere). I personaggi successivi vengono ignorati. Questa è la banana.

Internet è pieno di scimpanzé.

Queste restrizioni sono spesso messe in atto per vari motivi:

• Interazione con sistemi legacy che non supportano password lunghe.
• Convenzione (ad esempio "l'abbiamo sempre fatto in quel modo")
• Semplice ingenuità o ignoranza.

Per quanto riguarda la sicurezza, non è necessario limitare le lunghezze delle password. Dovrebbero essere comunque sottoposti a hash, usando un KDF come bcrypt. Per aiutare con le prestazioni, potrebbe essere utile inserire un limite molto grande (ad esempio 512 caratteri) nella lunghezza della password, per evitare che qualcuno ti invii una password da 1 MB e DoS per il server per 10 secondi mentre calcola l'hash.

1. Se lo memorizzano in testo in chiaro o in chiaro in chiaro, è probabilmente il valore massimo che può essere memorizzato nel DB. D'altra parte uno dovrebbe arrivare il più lontano possibile da questi siti
2. Per evitare attacchi DOS. Questo di solito è se hanno un limite molto alto, come 512 o 1024 byte
3. Rispettare le normative che vengono effettivamente fatte da persone che non sanno nulla della sicurezza IT
4. Per ragioni ereditarie, come ha sottolineato Tom Leek

Btw. ecco un elenco (storico) di siti di alto rango con lunghezza massima delle password:

link

Ho fatto questa domanda su Bol.com, uno dei più grandi negozi online dei Paesi Bassi. La loro risposta è stata quella di evitare di essere inondati di e-mail di supporto sulle password dimenticate. Hanno quindi ignorato curiosamente la mia richiesta sulla funzione di reimpostazione della password che ti invia semplicemente un link di ripristino quando hai dimenticato la password.

Ho concluso che è molto probabile una decisione del team di gestione. In alternativa potrebbe essere che non hanno le password hash e usano questo per impedire che il loro database venga allagato (anche se è possibile avere un nome utente più lungo, quindi sembra improbabile). Inoltre non hanno risposto a una domanda sul fatto che abbiano le password hash (penseresti che se tutto va bene non ci sarebbe alcun motivo per non rispondere).

Citerò un tentativo di ridurre i problemi relativi al servizio clienti.

Le password più grandi e complesse sono, maggiore è la probabilità per il cliente di inserire una password non valida, ottenere bloccato e quindi contattare il servizio clienti legando il tempo di quella persona.

È incredibile quante persone non siano in grado di digitare con precisione una password debole normale, per non parlare di una password di alcuni caratteri più lunga o che deve avere un carattere extra o 2 iniettati per complessità.

Forse OT, ma le password lunghe non sono necessariamente una vera misura di sicurezza garantita poiché le password vengono rubate direttamente su una base abbastanza comune al giorno d'oggi.

Tentativi di accesso non riusciti e il rilevamento della geo-distanza dall'utilizzo normale dell'account di accesso è una metrica molto più accurata. se un IP appartenente a un paese con profilo di hacking / attacco noto alto si collega ad una banca americana e quell'accesso non è mai stato utilizzato da quella posizione prima .....

Un sacco di posti di alto profilo come SF / banche hanno generalmente un numero di tentativi di accesso fallito molto basso, con conseguenti blocchi a livello di sistema. Alcuni come SF arrivano a fare allocazioni IP individuali, il che significa che non è possibile accedere da un nuovo indirizzo IP senza autorizzarlo.

"Interazione con sistemi legacy che non supportano password lunghe." come detto sopra è il motivo per cui una società per cui ho lavorato ha imposto una lunghezza massima della password.

Come variante del tropo "un gruppo si muove alla stessa velocità del suo membro più lento" l'uso di più sistemi a cui tutti gli utenti dovevano accedere utilizzando le stesse credenziali di accesso significava che qualsiasi restrizione di uno di quei sistemi avrebbe avuto da applicare a tutti account.

Quindi, se un'applicazione non è piaciuta ^ allora tutte le password per tutti i sistemi non potrebbero avere un ^. Se ad un programma non piacciono le password > 8 caratteri quindi tutti gli account dovevano avere password < 9 caratteri. Quindi in un ambiente complesso come BigCo in cui ho lavorato, questo potrebbe comportare una dozzina o due dozzine di software diversi; il display LCD era quello che ricevevano tutti.

Hanno usato anche IE6.

Un'altra possibilità che vorrei affrontare non è che le password siano talvolta limitate dalla lunghezza del campo utilizzato per salvarle, se salvate in testo normale. Se il tuo campo è un VARCHAR (32), puoi salvare al massimo 32 caratteri.

Tuttavia, ciò significa qualcosa di ancora peggiore: la password viene salvata in testo normale. Questo è il motivo per cui accettiamo questi tipi di reati come prove (leggere) su plaintextoffenders.com .

Un limite di lunghezza della password è ragionevole fintanto che quel limite consente ancora passphrase forti; ad esempio, il limite non è inferiore a 64 caratteri. Un limite elevato quando si imposta la password è significativamente migliore rispetto al troncamento silenzioso della password.

Se l'applicazione salva la password con hash a 128 bit (si spera salato e allungato a chiave), non c'è alcun vantaggio nel consentire password più lunghe di ~ 64 caratteri. Ad esempio, con una passphrase diceware con parole di 5 caratteri con spazi tra di esse, una passphrase di 64 caratteri consente 10 parole che avranno un'entropia di oltre 128 bit.

Uno sviluppatore potenzialmente potrebbe essere preoccupato per l'iniezione SQL o gli attacchi di overflow del buffer immessi tramite il campo della password - garantito che dovresti usare i metodi standard per prevenire questi attacchi: usa sempre i parametri associati con SQL (rispetto alla manipolazione della stringa per costruire query) e controlla sempre correttamente le stringhe (possibilmente utilizzando un linguaggio di programmazione sicuro o librerie sicure con protezioni integrate). Devi essere preoccupato per questi attacchi a tutti gli input dell'utente; questo non è univoco per il campo della password, quindi la protezione ottenuta con una dimensione massima della password è probabilmente trascurabile.

Potrebbero esserci anche dei motivi tangenziali per i limiti. Una banca che fornisce agli utenti carte bancomat con un codice PIN (numero di identificazione personale) può scegliere di obbligare gli utenti a utilizzare PIN di lunghezza compresa tra 4 e 10 cifre. Consentire a un utente di impostare e utilizzare un PIN di 50 cifre probabilmente avrebbe un piccolo vantaggio in termini di sicurezza rispetto a un PIN di 8 cifre: quando un utente malintenzionato ha bisogno sia della carta bancomat di un utente (che non è stata chiamata come rubata), utilizzare un monitorato ATM, e viene bloccato dopo 4 tentativi sbagliati. Un PIN di 50 cifre potrebbe essere più costoso in termini di costi umani per la tua banca, poiché verrebbe dimenticato / inserito in modo errato più frequentemente - potrebbe far scattare un dipendente da indagare (ad esempio, controllare il video ATM e confrontare con transazioni precedenti) o avere un il dipendente accompagna il cliente attraverso un meccanismo di ripristino della password necessariamente lungo (ad esempio, il meccanismo di ripristino deve essere costoso, quindi non è il collegamento più debole). L'intero processo potrebbe portare a una scarsa esperienza utente del cliente che la banca vuole evitare.

Come altri hanno già notato, la grande ragione che arriva per 8 caratteri o meno riguarda i vecchi sistemi che non supportano nulla di più lungo.

Poi c'è l'idea generale di porre un limite superiore a ciò che è ragionevole. Diciamo che è di 500 caratteri. Non sarebbe irragionevole pensare che chiunque fornisca più di 500 caratteri per una password possa essere inutile.

Ma anche se si utilizza un sistema di hashing della password attualmente consigliato, ci sono ancora dei limiti. Bcrypt, che è ampiamente utilizzato e da quello che posso dire generalmente considerato un'opzione buona / strong per le password di hashing, tratta solo i primi 72 caratteri. Tutto ciò che va oltre i 72 caratteri viene buttato via. Se la mia password è lunga 100 caratteri e la tua è 150, se iniziano con gli stessi 72 caratteri bcrypt li considererà uguali.

Dato questo limite specifico in bcrypt, se stai usando bcrypt potresti voler imporre un limite di 72 caratteri per assicurarti che tutte le password univoche siano effettivamente considerate univoche dal tuo sistema di autenticazione.

Molti siti pensano che non sia necessario avere una password lunga in quanto vi è una protezione brute-force (come il numero limite di tentativi di accesso per IP), il che fa una piccola differenza per avere password long vs short, in entrambi i casi ci vorrebbe anni per provare tutte le possibili combinazioni.

L'unico consiglio sarebbe quello di usare caratteri casuali (! @ # $% ^ & * -_ = + / \ '") un lungo con a-z A-Z 0-9.

Direi che ci sono tre ragioni principali:

1. Sistemi legacy che non supportano caratteri speciali
2. Il desiderio di mantenere basso il supporto e di utilizzare il sistema, mantenendo le password degli utenti effettivamente memorizzabili. In altre parole, se permetti agli utenti di creare e utilizzare password che non riescono a ricordare, lo faranno e, di conseguenza, ti infastidiranno o smetteranno di utilizzare il sito a causa del fastidio
3. Gli sviluppatori che non vogliono preoccuparsi di analizzare caratteri speciali provenienti da utenti non fidati, che potrebbero essere potenzialmente pericolosi

In passato il motivo principale era probabilmente la mancanza di abilità per supportare le password (n. 1), e oggi è probabilmente la mancanza di desiderio a supportarle- - principalmente da # 2, ma parzialmente da # 3.

Jet un'altra ragione è la progettazione dell'interfaccia utente e l'esperienza utente complessiva: non è ovvio per molti utenti cosa sta succedendo quando viene raggiunta la lunghezza visibile del campo di input dato che ogni personaggio è mostrato come una stella o un punto grande. Questo può confondere gli utenti e causare emozioni negative (meno probabilità di comprare qualcosa, di tornare indietro o di raccomandare il sito a un amico). Le soluzioni tecniche sono possibili ma è semplicemente più semplice limitare la lunghezza, ad es. a 20 caratteri, in modo che il cursore non raggiunga mai la fine del campo di input.

Con ulteriori restrizioni (in genere, solo i numeri accettati), può anche essere motivato dal fatto che consente (o potrebbe consentire, se un giorno sorgesse la necessità) di inserire la password attraverso alcune interfacce con capacità limitate ...

Ecco perché molte banche hanno fissato tali restrizioni per le password di accesso Web, per consentire l'accesso attraverso sistemi legacy che hanno solo tastierini numerici (bancomat, telefoni ...)

Tutti i siti bancari che conosco hanno un sistema simile a un pin che blocca il tuo account dopo 3 tentativi di password falliti. Ciò significa che le password lunghe sarebbero controproducenti perché sono più facili da ignorare o dimenticare, soprattutto perché non puoi vederle (e se potessi vederle la sicurezza sarebbe anche peggio).

Se prendi ad es. un sistema di pin per smartphone in cui si digitano 4 numeri, le probabilità di indovinarlo correttamente entro 3 tentativi è dello 0,03%. Con 8 cifre, le probabilità di indovinarlo correttamente (se la sequenza viene generata casualmente e non scelta stupidamente) diventano così piccole, che se si provassero a indovinare 7 miliardi di password per i popoli, si dovrebbe solo indovinare in media le password delle 21 persone. Se sono ammessi personaggi e / o caratteri speciali, le probabilità di indovinare diventano ancora più piccole, moltiplicate per un fattore rispettivamente di 1 ^ -4 o 1 ^ -6.

Anche se gli utenti sono autorizzati a scegliere le password e le sceglierebbero in maniera semi-predittiva, entro 3 tentativi è impossibile decifrare qualsiasi account specifico e la tua media non migliorerebbe troppo, anche se avresti un sacco di dati, come tutti i compleanni di una famiglia e i nomi di tutti i membri della famiglia e di ogni amico della persona. Ed è anche improbabile che tu abbia un elenco affidabile e completo di questo tipo per una grande popolazione.