Domanda:
Quali sono i motivi tecnici per avere una lunghezza massima delle password ridotta?
enderland
2013-03-31 02:30:37 UTC
view on stackexchange narkive permalink

Mi sono sempre chiesto perché così tanti siti web hanno restrizioni molto rigide sulla lunghezza della password (esattamente 8 caratteri, fino a 8 caratteri, ecc.). Questi tendono ad essere banche o altri siti in cui mi interessa davvero la loro sicurezza.

Capisco che la maggior parte delle persone sceglierà password brevi come "password" e "123456" ma ci sono ragioni per forzare questo? Utilizzando un'applicazione come 1Password, quasi tutte le mie password sono qualcosa come fx9 @ # ^ L; UyC4 @ mE3<P] uzt o altre lunghe stringhe generate casualmente di improbabile indovinare le cose.

  • Esistono motivi specifici per cui i siti Web impongono limiti rigorosi sulla lunghezza delle password (più come 8 o 10, capisco perché 100000000 potrebbe essere un problema ...)?
Devo aggiungere che una password sicura può anche essere "fiocco corretto della batteria del cavallo". Non c'è motivo per questo e posso solo dirti di contattare i siti che ancora applicano questa regola.
@s4uadmin No, "correcthorsebatterystaple" non è sicuro perché è molto noto e probabilmente esisterà in un attacco di dizionario. Inoltre, hai provato a utilizzare questa password su DropBox?
@AlvinWong Credo che s4uadmin abbia fornito un esempio ben noto, non il suggerimento che qualcuno effettivamente selezioni "la graffetta corretta della batteria del cavallo" come propria password letterale.
@JeffFerland Sì, il mio commento risponde all'amministratore di s4u * letteralmente * mentre tu hai risposto * in senso figurato *. Io stesso * uso * una password lunga, non "correttahorsebatterystaple" però ...
@s4uadmin: Mai sentito parlare di un attacco al dizionario, eh?
@AlvinWong, dal codice sorgente javascript di Dropbox, questo è un easter egg: `if (pwd == 'correcthorsebatterystaple' || pwd == 'Tr0ub4dour & 3' || pwd == 'Tr0ub4dor & 3') {// easter egg [...] "
Mehrdad, un attacco del dizionario non funzionerà qui. A meno che il tuo dizionario non contenga parole come Correcthorsebatterystaple
Senza dimenticare che gli hacker ora hanno "la graffetta corretta della batteria del cavallo" come * prima * voce nei loro elenchi di forza bruta :)
Non intendo dire che approvo questa idea, ma mi è stato chiesto di utilizzare una password facile da ricordare perché scriverla è un rischio per la sicurezza. Questo potrebbe essere un motivo tecnico / umano per mantenerli brevi. Non sono d'accordo perché nel momento in cui qualcuno ha le mani sulla tua password scritta o sul tuo documento di testo in cui potresti averla salvata, le tue misure di sicurezza hanno già fallito.
Ho chiesto a uno di questi istituti, che ha una lunghezza massima della password breve, circa questo un anno fa. La loro risposta a me: "Durante la valutazione con la nostra gestione del rischio, è stato stabilito che una password massima di 10 caratteri sarebbe stata sufficiente."
Allo stesso modo, perché un sito dovrebbe limitare i tipi di caratteri che possono essere utilizzati in una password, ad esempio, senza punteggiatura `! @ #%". `Ecc ...?
La mia ipotesi: poiché la password è memorizzata come testo normale in una colonna del database, digita `varchar (10)`
@Ryan Una "lista di forza bruta" ... Quindi almeno devono provare la lista di parole (dizionario) prima.MrGreen
La mia università ha un limite di lunghezza massima della password di 16 caratteri.Quindi, quando sono arrivato, ho creato una password di 16 caratteri.Quindi ho provato ad accedere al loro VPS e non funzionava (moriva ogni volta, senza errori).Non riusciva a capirlo per anni.Alla fine si è scoperto che il router Cisco che stavano usando per il VPS gestiva solo una password fino a 12 caratteri ... Quindi il mio limite massimo effettivo ora è di 12 caratteri, se voglio usare il VPS.
Ho appena provato "correcthorsebatterystaple" come password su Dropbox, e in realtà mi ha permesso di registrarmi.Triste.
Quattordici risposte:
#1
+1720
Tom Leek
2013-03-31 02:48:46 UTC
view on stackexchange narkive permalink

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

Oh, e pensavo che gli orsi stessero prendendo il controllo di Internet ...
Mi piace anche questa storia; non lasciare mai che i fatti si frappongano a un buon racconto morale: http://skeptics.stackexchange.com/questions/6828/was-the-experiment-with-five-monkeys-a-ladder-a-banana-and- a-water-spray-condu :)
diversi scimpanzé sono stati feriti durante la realizzazione di questa risposta. (a proposito, mi è piaciuta la spiegazione!)
Ci sono prove che questo sia davvero il motivo? Per esempio. qualcuno ha effettivamente chiesto a qualcuno che ha progettato un sistema con una lunghezza massima della password perché lo ha fatto in quel modo?
Per la natura della risposta, però, lo sviluppatore di scimpanzé non dovrebbe più essere presente.
Soluzione semplice ... lasciami impostare la password su quello che voglio e tronca semplicemente quando la invio. Almeno dammi l'illusione che sto effettivamente scegliendo la mia password. Poi di nuovo non puoi applicare numeri e strane regole sui personaggi (cosa buona secondo me)
@Joe che scuote la mia fiducia nel servizio. Non memorizzare mai le mie password in testo normale. Saresti felice di vederlo? http://thenextweb.com/microsoft/2012/09/21/this-ridiculous-microsoft-longer-accepts-long-passwords-shortens/
Il troncamento di @kush all'invio non impedisce l'hashing, sebbene l'hashing rimuova il punto di troncamento al momento dell'invio.
.. Questa è la banana ... vorrei più dire che DES-crypt usando i primi 8 caratteri è il tubo dell'acqua. Affinché la tua storia sia completa dovresti rimuovere i tubi dell'acqua e vedere chi osa sfidare di nuovo ...
In altre parole, algoritmi moderni implementati correttamente e non c'è assolutamente alcun motivo per un limite massimo di password, se non per renderlo non completamente folle (vediamo, diciamo una password lunga 1 MB?). Gli hash LANMAN di Windows NT avevano problemi simili con un massimo di 14 caratteri suddivisi in password 2x7 caratteri e sottoposti a hash senza salting.
Ecco perché non dovresti documentare il come ma il perché. E questo vale per tutte le regole.
Sono con @LarsH. Siamo sicuri che tutto questo possa effettivamente essere ricondotto alla funzione crypt?
@LarsH e Kevin, cosa ?! Stai davvero _pensando_? No no no, dovresti votare ciecamente e accettare. È un po 'ironico, vedi, non avrai una risposta per questo, ci si aspetta che ti comporti in modo molto simile agli scimpanzé nella risposta stessa.
@LarsH: Un giorno ho chiesto a uno scimpanzé (supporto tecnico di livello 2 per il ripristino delle password, al telefono) perché le password dovevano essere di 6 cifre e non di più (nessuna lettera), generate dal sistema e inviate tramite posta cartacea non tracciata. La risposta è stata "Siamo una banca e non possiamo assumerci rischi per la sicurezza". Ho rinunciato alla banana.
Puoi persino rimuovere i tubi dell'acqua e gli scimpanzé continueranno a picchiare chiunque tocchi la scala a pioli.
"Questa è la banana." Qual è la banana, il fatto che `crypt ()` ignorava i caratteri dopo i primi 8? Ciò non sembra adattarsi all'analogia, dove la banana è la ricompensa che tutti possono vedere è desiderabile, ma quali scimpanzé hanno imparato per tradizione che non dovrebbero inseguirli. Mi sembra che la banana sia qualcosa di simile a "maggiore sicurezza consentendo password più lunghe". I limiti della legacy `crypt ()` potrebbero essere il * waterhose * piuttosto che la banana. (La corrispondenza tra l'analogia e la realtà è ovviamente ipotetica.)
@PPC Prova aneddotica FTW !!
Ma come fanno gli scimpanzé a entrare nei tubi?
OMG, la rete è piena di scimpanzé. Per la cronaca, sto attualmente lavorando a un progetto per rimuovere il limite di 8 caratteri per le password per un cliente che ha oltre 40.000 utenti e molte applicazioni. Le cose non sono così semplici come molti di voi vorrebbero pensare. Sì, il limite crypt () è il motivo principale del limite di 8 caratteri. Crypt era necessario per supportare le app legacy. Il limite di 8 caratteri aveva senso quando è stato originariamente imposto (CPU, rete, velocità I / O).
Ho creato il mio account su questo sito solo per dare un voto positivo alla tua risposta. Fantastica spiegazione! Signore, sei un vero genio !!
b..ma, pensavo che la mia banca mi limitasse a 8 caratteri per la mia protezione
@LeoKing Questo è security.stackexchange, quindi le persone non si limitano a 666, ma mirano a [Strong Primes] (https://en.wikipedia.org/wiki/Strong_prime).
Rilevante: http://skeptics.stackexchange.com/questions/6828/was-the-experiment-with-five-monkeys-a-ladder-a-banana-and-a-water-spray-condu
Qualcosa di simile a come funziona la religione.Mi ha fatto sorridere.Grazie per l'incredibile analogia.
+1;L'ultima volta che ho sentito questa spiegazione, si è conclusa con "Questo è ciò che chiamiamo << politica aziendale >>".
#2
+234
Polynomial
2013-03-31 02:49:54 UTC
view on stackexchange narkive permalink

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.

Per quello che vale, le buone funzioni di hashing delle password non saranno molto influenzate dalla lunghezza della password. Con PBKDF2, utilizzato con HMAC, la password è la _key_ HMAC, quindi, mediante l'applicazione di HMAC, viene prima normalizzata a un valore non più lungo di un blocco interno (tipicamente 64 byte). Per ottenere 10 secondi di lavoro extra dalla CPU a causa di una password molto lunga, quella password dovrebbe essere lunga circa 1,5 GB, non un semplice megabyte.
Sì, probabilmente eliminerebbe la larghezza di banda molto prima della CPU
Non esiste una funzione di hashing che renda sicura una password come `asdfhjkl`.
@Kaz Nessuno ha detto che ci fosse.
@Kaz E se lo salassi?
@Polynomial bcrypt avrebbe solo la lunghezza della password avere alcun effetto sul tempo della CPU sulla prima iterazione IIRC e quindi è solo un singolo hash di 1 MB di dati (il tuo server rallenta fino a 1 MB?). Penso che la larghezza di banda sia molto più un problema.
@JoePhilllips: Salting non migliora la sicurezza di una password intrinsecamente, protegge solo dagli attacchi offline. Anche in questo caso, una password come "asdfhjkl", essendo di soli otto caratteri, è del tutto possibile infrangere fintanto che conosci il sale. Salting non aiuta affatto una singola password, ma protegge enormemente l'intero database rendendo impossibile controllare un singolo set di password in un'unica iterazione: è necessario un controllo per ogni singolo utente. Le singole password sono ancora deboli e suscettibili di essere violate, ma solo se sono abbastanza importanti da disturbare il targeting.
con i discorsi sulle password nelle gamme Mega e Giga, perché non usare semplicemente i file come password? Credo che sia usato in alcuni posti (anche TrueCrypt lo fa)
Ogni carattere in una frase password contribuisce con un po 'di entropia all'hash. Ma se l'hash alla fine è una stringa di N bit, allora è superfluo se la frase della password ha molto più di N bit di entropia. Facciamo un esempio ridicolo. Supponiamo che l'hash sia largo 16 bit e utilizzi una password da un megabyte. Il cracker potrebbe trovare una combinazione di caratteri molto breve che produce lo stesso hash e quindi serve al posto della tua password da un megabyte. Ci sono sicuramente rendimenti decrescenti oltre una certa lunghezza della password rispetto alla forza della funzione di hashing.
@Kaz: La tua affermazione "Ogni carattere in una frase password contribuisce con un po 'di entropia all'hash" non è sempre vera: a causa degli attacchi al dizionario, "corretta batteria di cavallo" è una password (meno cattiva) rispetto a quando aggiungi la E finale
@PPC Password quality! = Password entropy. L'entropia è una misura puramente statistica.
Cosa - niente scimpanzé ?!
Puoi aggiungere "I nostri clienti sono troppo stupidi per ricordare password lunghe" al tuo elenco di motivi. Non che siano stupidi, solo percepiti in quel modo.
"Per quanto riguarda la sicurezza, non è necessario limitare la lunghezza delle password. Dovrebbero comunque essere hash, utilizzando un KDF come bcrypt." Nota che bcrypt ha un limite superiore di 72 caratteri; ignora semplicemente qualsiasi cosa oltre a questo.
#3
+85
SztupY
2013-03-31 02:52:09 UTC
view on stackexchange narkive permalink
  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

Per costruire su questo: più lunga è la password, più costoso è l'hash. Questo è un argomento orribile poiché l'hashing di 128 caratteri con [PBKDF2] (https://en.wikipedia.org/wiki/PBKDF2) dovrebbe avere solo un costo trascurabile rispetto all'hashing di 8 caratteri, annullando qualsiasi [DoS] (https: // en.wikipedia.org/wiki/Denial_of_service_attack) rischio (dalla sola lunghezza pw). Peggio ancora sarebbe memorizzare la password in testo normale, anche se ciò potrebbe sollevare problemi di archiviazione. Sono favorevole a limitare la lunghezza della password, ma non vedo alcun motivo per cui tale limite sia inferiore a cento.
Per inciso, vale la pena sottolineare che tutte le password hanno una lunghezza limitata.Anche se il modulo consente un numero illimitato di caratteri, il server Web è quasi certamente configurato con una dimensione massima del payload POST.Anche se il server web non è configurato per rifiutare le richieste, alla fine il browser e / o il PC esauriranno la memoria per memorizzare la password.Certo, la maggior parte delle persone normali non proverà a inserire password mega-lunghe, ma - specialmente per un target di alto valore come una banca - uno sviluppatore degno dovrebbe essere in grado di dirti qual è quel limite e cosa succede quandoviene colpito.
#4
+70
Luc
2013-03-31 18:45:27 UTC
view on stackexchange narkive permalink

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

Il mio supermercato (shopping online) tira fuori la stessa scusa. Assolutamente ridicolo e chiaramente implementato da qualcuno senza il concetto di sicurezza.
Sembra che alcuni di quegli scimpanzé abbiano trovato lavoro su Bol.com :-)
Haha, praticamente lo stesso per la compagnia tedesca Telekom: D
#5
+40
MDR
2013-03-31 03:56:48 UTC
view on stackexchange narkive permalink

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.

Questo può essere il pensiero, ma IMHO questa linea di pensiero è profondamente imperfetta. Perché prendere la possibilità di utilizzare password lunghe e sicure perché alcuni utenti preferiscono quelle brevi? La reimpostazione della password di solito non comporta l'intervento del servizio clienti. Inoltre, se le password * possono * essere "rubate direttamente" (ad es. Sono memorizzate in testo normale), lo stai facendo completamente sbagliato.
In base alla mia esperienza, i clienti che non digitano / ricordano correttamente la password ostacolano l'assistenza clienti tramite e-mail e telefono. Con password rubate, mi riferisco ai milioni di computer zombificati con trojan / ascoltatori chiave e ai numerosi tentativi di phishing. Symantec ha pubblicato # qualche anno fa sul numero di password rubate.
@MDR: Se non sono autorizzati a utilizzare password più lunghe / più forti, le loro password vengono facilmente violate e di nuovo verranno all'assistenza clienti. E perché gli utenti dovrebbero rivolgersi all'assistenza clienti se ** dimenticano ** la password, ** se ** il tuo servizio web offre la funzione ** password dimenticata **.
Buone risposte, ma per accontentare il pubblico di "utenti che inventeranno password lunghe anche quando possono averne di brevi, poi dimenticatele e richiamate invece di usare la reimpostazione della password", escludete gli "utenti che usano password lunghe in un gestore di password ". Pandering per ingannare un compito infinito e inutile, quindi è meglio educare il gruppo smemorato e abilitare il gruppo sensibile. Questo è IMHO perché i piccoli limiti di lunghezza della password sono un'idea profondamente viziata.
@SaiManojKumarYadlapati: se una password può essere forzata bruta, c'è un difetto nel tuo sistema. Inoltre, se una password può essere rubata tramite keylogger / computer zombificato, cosa che avviene in modo molto regolare, e si ottiene l'accesso a informazioni "critiche", anche questo rappresenta un difetto nel sistema.
@Anthony: Fai un buon, ma quello che credo sia un punto teorico. So che la nostra azienda impiega diverse persone per le "relazioni con i clienti". So che i 2 principali motivi per cui i clienti ci chiamano o inviano un'e-mail, che non sono correlati a problemi specifici dell'azienda, sono tutti legati all'accesso. Il motivo n. 1 è "sono stati registrati con l'indirizzo e-mail sbagliato" Il motivo n. 2 è che non possono digitare la password / non ricordano la password. E anche se sono d'accordo al 100% con quello che dici, la mia esperienza professionale (a prescindere da una grande banca) mostra che questo problema può costare denaro a un imprenditore.
@MDR: I blocchi a livello di sistema e l'allocazione IP individuale ecc. Non sono funzionalità ma punizioni per gli utenti autentici quando qualcuno cerca di violare il proprio account. Mi dispiace di aver perso la connessione a Internet prima di completare il mio commento in precedenza.
Meh. "Le password non possono essere create in modo sicuro perché gli utenti sono troppo stupidi" è un consiglio di disperazione. Scioccante vederlo in una banca.
Un'altra domanda: supportare gli utenti costa denaro. Lo sappiamo. Ma sai per certo che i tuoi costi aumenteranno se consenti password più lunghe o è solo una superstizione? Quali sono le prove? Quello che stai facendo è abbassare i tuoi costi quotidiani (forse), ma anche aumentare le probabilità che potrebbero perdere alla lotteria degli hacker se il tuo database della password viene penetrato. Hai un risparmio (forse) ma devi soppesarlo sull'altro costo, o è una falsa economia.
Ho affrontato tutti questi problemi nei commenti in linea.
Sicuramente non ci sarebbe bisogno di ridurre la dimensione massima, però. Basta non impostare un minimo. I tipi di persone che usano password più lunghe presumibilmente sarebbero in grado di ricordarle meglio (ad esempio, utilizzando un gestore di password o un qualche tipo di pattern). Immagino che le persone con password più brevi abbiano password più brevi allo scopo di ricordarle meglio (il che le rende molto vulnerabili agli attacchi di forza bruta, però).
Non vedo come costringere gli utenti a non utilizzare la password memorabile che hanno pensato renderà le password più facili da ricordare.
#6
+27
user2228243
2013-03-31 05:16:25 UTC
view on stackexchange narkive permalink

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

Mi sono divertito alla tua ultima frase.
Un gruppo con membri lenti ha davvero bisogno di un leone nella parte posteriore per mantenere la motivazione.
la sicurezza di IE6 conta come un leone nella parte posteriore?
@SargeBorsch L'affermazione più generale sostiene che conta come una "x" nella "y" per alcuni valori di "x, y".
@TobiaTesan Adoro il tuo commento
#7
+21
Omer van Kloeten
2013-03-31 12:30:28 UTC
view on stackexchange narkive permalink

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.

Questo. Se hanno eseguito l'hashing delle password, avrebbero tutte la stessa lunghezza. Pertanto, se un sito dice "lunghezza massima X caratteri", presumo che 1) memorizzi testo in chiaro o 2) utilizzi una convalida inutile. # 1 sembra più probabile.
Mostrare la password nell'e-mail è la prova che la memorizzano in testo normale?Non potrebbero hash e archiviarlo dopo aver inviato l'e-mail?Non dico che lo siano, ovviamente, e penso che inviare la password in un'e-mail sia probabilmente insicuro per un altro motivo, ma almeno non sembra una prova definitiva.
L'email è un mezzo insicuro per definizione, questo è sconsiderato.Senza contare che le persone non possono mai eliminare l'email e chiunque abbia accesso alla propria casella di posta può semplicemente cercare la parola "password" e avere accesso immediato al proprio account.
#8
+20
dr jimbob
2013-03-31 04:22:25 UTC
view on stackexchange narkive permalink

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.

Steamstore ha un limite di 63 caratteri.Immagino di evitare overflow lunghi / interi .
#9
+11
Joseph Scott
2013-03-31 10:38:59 UTC
view on stackexchange narkive permalink

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.

`per assicurarti che tutte le password univoche siano effettivamente considerate uniche dal tuo sistema di autenticazione. scusa, ma non puoi. Ecco perché utilizziamo hash crittograficamente potenti.
Non credo che ci sia alcun motivo per applicare una regola secondo cui ogni utente dovrebbe avere una password univoca.Due utenti diversi possono benissimo avere la stessa password.L'unico svantaggio di bcrypt che butta via tutto oltre i primi 72 caratteri è che chiunque cerchi di decifrare una password deve solo provare stringhe di lunghezza massima = 72, cioè anche se imposto una password lunga 100 caratteri, i 28 caratteri extra non dannome qualsiasi sicurezza aggiuntiva.
#10
+8
sharp12345
2013-04-03 00:03:34 UTC
view on stackexchange narkive permalink

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.

A seconda dell'RDBMS, alcuni di questi caratteri aggiuntivi potrebbero essere utilizzati per le iniezioni SQL e, si spera, finirebbero per essere omessi durante la sanificazione dei parametri di input, quindi non ne consiglierei davvero l'uso senza menzionare che i caratteri consentiti possono variare e dovrebbero essere usati con attenzione.
#11
+7
Joachim Wagner
2015-07-30 15:32:40 UTC
view on stackexchange narkive permalink

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.

#12
+6
Daniel Miessler
2013-03-31 10:03:43 UTC
view on stackexchange narkive permalink

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.

#13
+3
Christophe Franco
2013-03-31 10:20:44 UTC
view on stackexchange narkive permalink

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

#14
+1
HopefullyHelpful
2015-07-30 21:34:06 UTC
view on stackexchange narkive permalink

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.



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