Perché limitare la lunghezza della password?

Question

Questa domanda è ispirata da Esiste un rischio per la sicurezza nel non impostare una lunghezza massima della password? .

In particolare la risposta accettata https://security.stackexchange.com/a/238033/9640 dice che i limiti sono consigliati per evitare di esaurire il server.

Inoltre mi sembra che se il server sta eseguendo l'hashing della tua password con un hash di cifre, non ci sono vantaggi in termini di sicurezza nell'avere una password più lunga di n cifre. Un'entità in grado di forzare in modo ragionevole lo spazio delle cifre n, non dovrebbe forzare lo spazio delle cifre (n + 1) per forzare la password delle cifre (n + 1). In termini pratici, una password di 1000 cifre non è realmente più sicura di una password di 500 cifre.

Tuttavia, che dire del doppio hashing della password.

1. L'utente immette una password di lunghezza arbitraria.
2. Il client hash la password a una lunghezza fissa.
3. Il server può rifiutare l'hash del client se non è di lunghezza fissa (proteggendo il server dall'esaurimento delle risorse).
4. In caso contrario, il server considera l'hash del client come password e procede nel modo consueto (lo esegue nuovamente).

In questo modo, se vuoi una password lunga 10.000 caratteri, scegli quella. Il tuo browser ti trasformerà in modo invisibile, trasformerà la tua password lunga 10.000 caratteri in una password lunga 128 caratteri (ancora molto sicura) e l'unico cambiamento nel server è che ora il server sa che tutte le password devono essere lunghe esattamente 128 caratteri in modo che possa rifiutare alcuni accessi più facilmente.

Il vantaggio principale di questo schema è che a nessun utente verrà mai detto "la tua password è troppo lunga". Personalmente trovo che questo messaggio sia scoraggiante. Ma ammetto che questo vantaggio non è monumentale. Quindi, se ci sono buchi di sicurezza che non vedo, questo schema probabilmente non ne vale la pena.

Answer 1

Finché stai molto attento alla funzione di hashing lato client, sembrerebbe che non ci sia motivo per cui non potresti. Ma aspetta!

È necessario ricordare che non tutte le password sono per applicazioni basate sul Web con un unico client scritto e distribuito dall'autore.

Invece, potrebbe essere un'API arbitraria. L'aggiunta del requisito secondo cui la password deve essere sottoposta ad hashing utilizzando una funzione specifica aggiunge complessità all'implementazione.

In altri casi ancora, la password potrebbe essere impostata sul lato server (si pensi ai server SQL in cui il comando "set password" è letteralmente un'istruzione SQL). Se la funzione di hashing iniziale è stata scelta male (pensa a md5 per postgres), ora sei bloccato con essa finché tutti i client non supportano la nuova funzione di hashing e tutti gli utenti hanno cambiato le loro password.

A prima vista potrebbe sembrare una ragione pratica e non una ragione di sicurezza. Ma questo diventa un problema di sicurezza 10 anni dopo, quando il protocollo è ancora in uso e la maggior parte dei client supporta ancora solo una funzione di hashing terribilmente insicura (e sì, questo è il caso di postgres).