Prendi cinque scimpanzé. Mettili in una grande gabbia. Sospendi alcune banane dal tetto della gabbia. Fornisci agli scimpanzé 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 attivati ​​e l'intera gabbia è completamente bagnata.

Presto, gli scimpanzé scoprono che le banane e la scala a pioli è meglio ignorarli.

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, si immagina di salire sulla scala a pioli per raggiungere le banane. Quindi afferra abilmente la scala a pioli ... e gli altri quattro scimpanzé gli saltano addosso e lo picchiano. Presto impara a ignorare la scala a pioli.

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

Ripeti. Dopo alcune operazioni, hai cinque scimpanzé pronti a prendere a pugni qualsiasi scimpanzé che oserebbe toccare la scala a pioli, e nessuno di loro sa perché.

In origine, qualche sviluppatore, da qualche parte, stava lavorando su un vecchio sistema Unix del secolo precedente, che utilizzava la vecchia "crypt" basata su DES, in realtà una funzione di hashing della password derivata dal cifrario a blocchi DES. In quella funzione di hashing, vengono utilizzati solo i primi otto caratteri della password (e anche solo i 7 bit inferiori di ogni carattere). I caratteri successivi vengono ignorati. Questa è la banana.

Internet è pieno di scimpanzé.

Queste limitazioni vengono spesso applicate per vari motivi:

• Interazione con sistemi legacy che non supportano password lunghe.
• Convenzione (ovvero "abbiamo sempre fatto in questo modo ")
• Semplice ingenuità o ignoranza.

Per quanto riguarda la sicurezza, non è necessario limitare la lunghezza delle password. Dovrebbero comunque essere sottoposti ad hashing, utilizzando un KDF come bcrypt. Per migliorare le prestazioni, potrebbe valere la pena porre un limite molto ampio (ad esempio 512 caratteri) sulla lunghezza della password, per evitare che qualcuno ti invii una password di 1 MB e faccia il DoS al tuo server per 10 secondi mentre calcola l'hash.

1. Se lo memorizzano in testo normale o in chiaro crittografato, questo è probabilmente il valore massimo che può essere memorizzato nel DB. D'altra parte bisogna allontanarsi il più possibile da questi siti
2. Per evitare attacchi DOS. Questo di solito è se hanno un limite molto alto, come 512 o 1024 byte
3. Per conformarsi alle normative che sono effettivamente fatte da persone che non sanno nulla di sicurezza IT
4. Per motivi legacy, come ha sottolineato Tom Leek

Btw. ecco un elenco (storico) di siti di alto livello con lunghezze massime di password:

http://web.archive.org/web/20130907182806/https://defuse.ca/password- policy-hall-of-shame.htm

Ho posto questa domanda su Bol.com, uno dei più grandi negozi online dei Paesi Bassi. La loro risposta è stata quella di evitare di essere invasi da 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 per la reimpostazione quando hai dimenticato la password.

Ho concluso che molto probabilmente è una decisione del team di gestione. In alternativa, potrebbe essere che non abbiano password hash e lo utilizzino per evitare che il loro database venga inondato (anche se puoi avere un nome utente più lungo, quindi questo sembra improbabile). Inoltre non hanno risposto a una domanda sull'eventuale hash delle password (penseresti che se tutto fosse a posto non ci sarebbe motivo per non rispondere).

Cito un tentativo di ridurre i problemi relativi al servizio clienti.

Più le password sono grandi e complesse, maggiore è la probabilità che il cliente inserisca una password non valida, venga bloccato e quindi contatti il ​​servizio clienti per bloccare il tempo di quella persona.

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

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

I tentativi di accesso non riusciti e il monitoraggio della distanza geografica dal normale utilizzo dell'accesso sono metriche molto più accurate. se un IP appartenente a un paese noto con alto profilo di hacking / attacco accede a una banca americana e tale accesso non è mai stato utilizzato da quella posizione prima .....

Molti luoghi di alto profilo come SF / le banche generalmente hanno un numero molto basso di tentativi di accesso non riusciti con conseguenti blocchi a livello di sistema. Alcuni come SF arrivano fino a fare l'allocazione IP individuale, il che significa che non puoi accedere da un nuovo indirizzo IP senza autorizzarlo.

"Interazione con sistemi legacy che non supportano password lunghe." come accennato in precedenza, è il motivo per cui un'azienda per cui ho lavorato impone una lunghezza massima per la password.

Come variazione del tropo "un gruppo si muove alla stessa velocità del suo membro più lento" l'uso di più sistemi che tutti gli utenti dovevano avere accesso all'utilizzo delle stesse credenziali di accesso significava che qualsiasi restrizione da parte di uno di quei sistemi avrebbe dovuto essere applicata a tutti gli account.

Quindi se un'applicazione non come ^ allora tutte le password per tutti i sistemi non potevano avere un ^. Se a un programma non piacevano le password> 8 caratteri, tutti gli account dovevano avere password < 9 caratteri. Quindi in un ambiente complesso come BigCo in cui ho lavorato, questo potrebbe coinvolgere una dozzina o due dozzine di software diversi; l'LCD era quello che avevano tutti.

Usavano anche IE6.

Un'altra possibilità che mi piacerebbe affrontare che non ha già è che le password a volte sono limitate dalla lunghezza del campo che viene utilizzato per salvarle, quando vengono salvate in testo normale. Se il tuo campo è un VARCHAR (32), puoi salvare al massimo 32 caratteri.

Tuttavia, questo significa qualcosa di ancora peggio: che la password viene salvata in testo normale. Questo è il motivo per cui accettiamo questo tipo di reati come prove (leggere) su plaintextoffenders.com.

Un limite di lunghezza della password è ragionevole fintanto che tale limite consente ancora passphrase complesse; ad esempio, il limite non è inferiore a 64 caratteri. Un limite elevato quando si imposta la password è significativamente migliore del troncare silenziosamente la password.

Se l'applicazione alla fine memorizza la password con hash a 128 bit (si spera salato e allungato con la chiave), non c'è alcun vantaggio nel consentire le password più a lungo di ~ 64 caratteri. Ad esempio, con una passphrase Diceware con parole di 5 caratteri con spazi tra loro, una passphrase di 64 caratteri consente 10 parole che avrebbero un'entropia di oltre 128 bit.

Uno sviluppatore potrebbe essere potenzialmente preoccupato per SQL injection o attacchi di overflow del buffer iniettati tramite il campo della password - ammesso che dovresti usare i metodi standard per prevenire questi attacchi: usa sempre parametri legati con SQL (rispetto alla manipolazione di stringhe per costruire query) e sempre correttamente i limiti controlla le tue stringhe (possibilmente usando una programmazione sicura lingue o librerie sicure con protezioni integrate). Devi essere preoccupato per questi attacchi su tutto l'input dell'utente; questo non è univoco per il campo della password, quindi la protezione ottenuta da una dimensione massima della password è probabilmente trascurabile.

Potrebbero esserci anche ragioni tangenziali per i limiti. Una banca che fornisce agli utenti carte bancomat con un 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 poco guadagno in termini di sicurezza in pratica rispetto ad un PIN di 8 cifre: quando un utente malintenzionato ha bisogno di entrambe le carte bancomat dell'utente (che non sono state chiamate come rubate), utilizzare 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 - forse indurre un dipendente a indagare (ad esempio, controllare il video ATM e confrontare con precedenti transazioni riuscite) o avere un dipendente accompagna il cliente attraverso un meccanismo di reimpostazione della password necessariamente lungo (ad esempio, il meccanismo di reimpostazione deve essere costoso, quindi non è l'anello 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 ragione principale che viene fuori per 8 caratteri o meno è avere a che fare con sistemi più vecchi che non supportano nulla di più lungo.

Poi c'è la buona idea generale di ponendo un limite superiore a ciò che è ragionevole. Diciamo che sono 500 caratteri. Non sarebbe irragionevole pensare che chiunque fornisca più di 500 caratteri per una password potrebbe non funzionare bene.

Ma anche se stai utilizzando un sistema di hashing delle password attualmente consigliato, ci sono ancora dei limiti. Bcrypt, che è ampiamente utilizzato e da quello che posso dire generalmente considerato un'opzione buona / forte per l'hashing delle password, si occupa solo dei primi 72 caratteri. Tutto ciò che supera 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 quel limite specifico in bcrypt, se stai usando bcrypt potresti volerlo imponi un limite di 72 caratteri per assicurarti che tutte le password univoche siano effettivamente considerate uniche dal tuo sistema di autenticazione.

Molti siti pensano che non sia necessario avere una password lunga poiché esiste una protezione dalla forza bruta (come la limitazione del numero di tentativi di accesso per IP), il che fa poca differenza per avere password lunghe o brevi, in entrambi i casi ci vorrebbe anni per provare tutte le combinazioni possibili.

L'unica raccomandazione sarebbe quella di usare caratteri casuali (! @ # $% ^ & * -_ = + / \ '") lunghi con az AZ 0-9.

Jet un'altra ragione è il design 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 poiché ogni carattere viene mostrato come una stella o un grande punto. Questo può confondere gli utenti e provocare emozioni negative (meno probabilità di acquistare qualcosa, tornare o consigliare il sito a un amico). Sono possibili soluzioni tecniche ma è solo più facile limitare la lunghezza, ad es. a 20 caratteri, in modo che il cursore non raggiunga mai la fine del campo di immissione.

Direi che ci sono tre ragioni principali:

1. Sistemi legacy che non supportano caratteri speciali
2. Il desiderio di mantenere basso il sovraccarico del supporto e l'uso del sistema alto , mantenendo le password degli utenti effettivamente memorizzabili. In altre parole, se consenti agli utenti di creare e utilizzare password che non possono ricordare, lo faranno e di conseguenza ti infastidiranno o smetteranno di utilizzare il sito a causa del fastidio
3. Sviluppatori non volendo doversi preoccupare di analizzare caratteri speciali da utenti non attendibili, che potrebbe essere potenzialmente pericoloso

In passato il motivo principale era probabilmente la mancanza di capacità di supportare le password (# 1), e oggi è probabilmente la mancanza di desiderio di supportarle - principalmente dal # 2, ma in parte dal # 3.

Con ulteriori restrizioni (generalmente si accettano solo numeri), può anche essere motivato dal fatto che consente (o può consentire, se un giorno se ne presentasse la necessità) di inserire la password tramite qualche interfaccia con capacità limitate ...

Ecco perché molte banche hanno stabilito tali restrizioni per le password di accesso al web, per consentire l'accesso attraverso sistemi legacy che hanno solo tastiere numeriche (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 digitare o dimenticare, soprattutto perché non puoi vederle (e se le potessi vedere la sicurezza sarebbe anche peggio).

Se prendi ad es. . un sistema a pin per smartphone in cui si digita 4 numeri, le possibilità di indovinarlo correttamente entro 3 tentativi sono dello 0,03%. Con 8 cifre, le possibilità di indovinarlo correttamente (se la sequenza è generata casualmente e non scelta stupidamente) diventano così piccole che se provassi a indovinare le password di 7 miliardi di persone, in media indovineresti solo 209 password di persone giuste. Se sono consentiti caratteri e / o caratteri speciali, le possibilità di indovinare diventano ancora più piccole, moltiplicate rispettivamente per un fattore 1 ^ -4 o 1 ^ -6.

Anche se gli utenti sono autorizzati a scegliere le password e lo farebbero sceglili in maniera semi-predittiva, entro 3 tentativi è impossibile craccare un account in particolare e la tua media non migliorerebbe troppo, anche se avresti molti dati, come tutti i compleanni di una famiglia ei nomi di tutti nella famiglia e in ogni amico della persona. Ed è anche improbabile che tu abbia un elenco affidabile e completo di questo tipo per una vasta popolazione.