Perché alcuni siti Web e programmi limitano le caratteristiche della password?

Penso che la ragione sia la stessa di qualsiasi altra convalida dell'input; per assicurarsi che non causi problemi durante l'elaborazione e la memorizzazione. Ora, per le password questo è ovviamente completamente fuorviante dal momento che dovrebbe essere sottoposto a hash e quindi non memorizzato né elaborato in chiaro.

Prenderò tali limitazioni come un'indicazione che gli sviluppatori non sanno cosa stanno facendo securitywise e probabilmente stanno andando a memorizzare la password in chiaro. Stai lontano.

Ho intenzione di andare con: le stesse vecchie ragioni per cui le persone fanno cose strane.

• Perché all'epoca sembrava una buona idea. Gli sviluppatori potrebbero essere benintenzionati ma scarsamente informati. Non è necessario limitare la lunghezza della password, ma forse gli sviluppatori non ne sono consapevoli. Forse gli sviluppatori non ci hanno nemmeno pensato.

• Perché era più facile delle alternative. Forse stanno usando un'API che non può gestire password di lunghezza arbitraria; questo potrebbe rendere più semplice limitare la lunghezza della password piuttosto che utilizzare un'API migliore. Forse hanno difetti di SQL injection nel loro database, e piuttosto che codificare le cose correttamente per evitare il difetto di SQL injection, è più facile inserire solo alcuni caratteri (ad es. Vietare agli utenti di includere citazioni singole nelle loro password). Forse per qualche motivo è stato più facile usare una matrice a lunghezza fissa rispetto a una stringa di lunghezza variabile. Chi lo sa.

In conclusione: non esiste una giustificazione valida per tali limiti. Sono sicuro che siamo abituati al fatto che il software disponibile in commercio spesso contiene tutti i tipi di strane caratteristiche del design. Succede. È un dato di fatto. È una conseguenza del fatto che "abbastanza buono" è molto più economico di "perfetto".

Un motivo razionale per limitare la lunghezza della password e il possibile set di caratteri è quello di spingere l'utente ad applicare tecniche di gestione password adeguate. In parole povere, se una password è enorme o piena di caratteri strani, allora aumenta la probabilità che l'utente scriva la password su un pezzo di carta (tradizionalmente incollato sotto la tastiera) e / o riutilizzi la stessa password in diversi sistemi .

Concettualmente, come l'utente gestisce le proprie password è una sua responsabilità, e nessuna delle attività del sito web. Ma, in pratica, gli utenti non conoscono la sicurezza e non possono annoiarsi con qualcosa che non ha una retribuzione immediata (specialmente quando gli utenti sono potenziali clienti ). Quindi è compito del sito Web cercare di fare ciò che può per proteggere l'utente.

Si noti che non sostengo che il tentativo di imporre una buona gestione delle password è il motivo per cui un determinato sito limita la lunghezza della password; è solo un motivo per cui I potrebbe prevedere una limitazione della lunghezza della password sul mio sito (se dovessi gestire un sito Web con password utente).

Un altro razionale per il set di caratteri consentito limitato è quello di promuovere l'interoperabilità: preferibilmente, l'utente dovrebbe essere in grado di digitare la sua password su una vasta gamma di dispositivi di input. I caratteri non ASCII non vanno bene per qualcosa che assomiglia a una tastiera americana (è possibile digitare lettere non ASCII su una tastiera americana, lo faccio sempre, ma i metodi variano a seconda del sistema operativo e della configurazione, e non funziona bene con la digitazione cieca come è consuetudine con l'inserimento della password). Gli smartphone hanno restrizioni ancora maggiori. Anche in questo caso, l'interoperabilità è (a mio avviso) una buona ragione per imporre un set di caratteri limitato, ma molti siti Web avranno una tale restrizione per i motivi cattivi (ad esempio, in modo che la password possa essere trascurata in modo accidentale in un SQL richiesta senza un'apposita stringa di escape, qualcosa che può essere descritto solo come ingegneria sciatta.

Pensavo avessimo una domanda come questa, ma il mio search-fu è debole stasera o era su un altro sito.

Fondamentalmente, nella maggior parte delle applicazioni o dei database ha senso definire limiti utili sulle stringhe di input. Ciò consente di interrompere l'immissione una volta raggiunto il limite (che può evitare overflow, ecc.) E garantisce inoltre di poter prevedere le prestazioni del codice.

Potresti anche aver bisogno di una memoria temporanea durante la convalida delle password prima che vengano sottoposte a hash: di nuovo, consentire input arbitrariamente lunghi può causare problemi.

Per quanto riguarda il motivo 32? Una cifra ragionevole per la maggior parte degli scopi - l'entropia in 32 caratteri è enorme. Ovviamente in alcuni ambienti questo non sarà sufficiente, ma per molti di loro un cert o un secondo fattore (come un token) potrebbe essere più appropriato comunque.

Poiché la mia prima domanda ha mancato il segno, fornisco una risposta separata. La ragione principale è che i limiti sono obbligatori. Sebbene la preoccupazione relativa allo spazio di archiviazione e al canto coronato dei dati sia accurata, ci sono alcuni problemi.

Innanzitutto, se leggi la mia risposta originale qui sotto, vedrai che uno dei consigli è l'hashing iterativo (cioè pbkdf). Ciò richiede un gran numero di iterazioni per essere veramente efficace. Se un utente è in grado di inviare una stringa di grandi dimensioni, il costo del calcolo di questo valore hash iterativo diventa rapidamente più costoso del previsto per una semplice funzione di autenticazione.

Qualsiasi singola attività computazionalmente costosa su un server, specialmente quella che è esplicitamente disponibile per un utente non autenticato, è soggetta all'abuso da parte di un utente malintenzionato per eseguire un attacco denial of service.

In secondo luogo, implementando una password a lunghezza fissa fornisce l'opportunità di terminare in anticipo se viene inoltrata una richiesta estremamente lunga. Se i parametri nella richiesta sono al di fuori della lunghezza prevista, è semplice emettere un messaggio di errore e chiudere la connessione.

Il motivo per cui i requisiti di complessità della password sono applicati su molti siti è quello di impedire agli utenti di scegliere una password debole. Ci sono numerosi esempi nella storia recente che mostrano che la maggior parte degli utenti selezionerà password deboli, facili da inserire, facili da ricordare su password complesse. Quando ciò si verifica, il proprietario del sito si espone al rischio in quanto gli utenti invariabilmente incolpano il sito se una password viene rubata o incrinata, e qualsiasi risultato possa avere sia per il sito che per l'utente interessato.

Implementando requisiti di password complessi, riduce la probabilità che un utente malintenzionato possa facilmente indovinare la password. Le password devono anche essere protette da due diversi percorsi di attacco. Il primo, gli attacchi online, richiede che uno sviluppatore del sito abbia una politica che impedisca il successo degli attacchi brute force. Ciò si ottiene richiedendo all'utente di selezionare una password complessa e sufficientemente lunga e limitando il numero di tentativi di accesso non riusciti prima di rallentare (cioè blocchi temporanei, captcha, ecc.) O interrompere i tentativi di accesso (blocchi permanenti, reimpostazione della password obbligatoria, conferme dell'account) , ecc.)

Il secondo attacco è un attacco offline, in cui un utente malintenzionato acquisirà una copia di un database delle password e tenterà di utilizzare una tabella arcobaleno o un cracker password offline per bloccare più account. Questo tipo di attacco viene prevenuto utilizzando un algoritmo di hash strong in combinazione con un sale per utente e preferibilmente con pbkdf2 o bcrypt / scrypt che ridisegna lo stile per aumentare il costo computazionale del cracking offline.

In definitiva, entrambe queste tecniche falliscono se i siti non incoraggiano gli utenti a selezionare una password univoca per i loro vari account. Molti utenti selezionano le stesse password per più account e quando viene visualizzata tale password, in particolare con il proprio account di posta elettronica, è possibile che un utente malintenzionato utilizzi tale credenziale su un altro servizio. Per questo motivo è meglio generare password univoche e forti per ogni sito o almeno diversi gruppi di siti e utilizzare un gestore di password sicuro per memorizzare tutte le diverse password.