Quale lunghezza massima della password scegliere quando si usa bcrypt?

Non sono favorevole al troncamento silenzioso perché induce gli utenti a credere che l'intera password sia stata accettata quando non lo era. Preferirei che un sistema impostasse una lunghezza massima, se necessario, e restringesse l'utente a quello durante l'immissione della password. Uno scenario errato di cui ho sentito parlare è un cambio di codice che inizia l'elaborazione dei caratteri oltre la lunghezza massima precedente e improvvisamente la password più lunga gli utenti non possono accedere. Il sistema ha solo un record dei primi 72 caratteri e la loro stringa più lunga non corrisponde a quella senza il vecchio troncamento del sistema. Ciò porta a utenti frustrati.

Come alternativa al troncamento a 72 caratteri dovresti considerare pre-hashing la password con qualcosa come SHA-256. Permette di considerare l'intera stringa di password dell'utente oltre i 72 caratteri pur continuando a fornire la protezione computazionale di bcrypt.

Di solito sono la persona che si oppone ai limiti sciocchi, ma devo chiedermi: chi usa seriamente password di oltre 72 caratteri? Una password così lunga sarebbe molto poco pratica da digitare, quindi è quasi certamente un robot (o ctrl + v da un gestore di password). I robot * e i gestori di password non si preoccupano se devono ricordare stringhe alfanumeriche casuali piuttosto che passphrase.

Supponendo che non usano caratteri speciali, cioè 26 + 26 + 10 = 62 possibilità per carattere e diciamo fino a 72 caratteri. Questo consente possibilità di 62^72 = 1.13*10^129 . Convertendo in bit di entropia, un numero molto più gestibile, otteniamo log(62^72)/log(2) = 428.7 bit di entropia.

Ultimo controllo, le chiavi a 256 bit sono considerate ragionevoli anche post-quantum, quindi questo dovrebbe essere abbondante .

Nel raro caso in cui si tratti di una passphrase, prendiamo un dizionario molto standard: quello predefinito sul mio sistema Debian. Dopo alcune potature standard (insensibilità alle maiuscole, rimozione di varianti possessive come "cavallo" anziché "cavallo") contiene circa 50k parole. Di questa matematica sono meno sicuro, ma penso che questo significhi che ogni parola, quando selezionata a caso (come dovresti con le passphrase), fornisce circa log(50000)/log(2)=15.6 bit di entropia. La lunghezza media delle parole in generale è considerata di 5 caratteri, più uno spazio, quindi 72 è di circa 12 parole.

Questo arriva a 15.6*12 = 187.3 bit di entropia in una passphrase di 72 caratteri. Come limite inferiore, perché il mio ditt non contiene tutte le parole. Direi che sei bravo.

Il vero limite stupido sono i 72 caratteri di bcrypt, ma se è quello con cui devi lavorare, penso che sia un limite ragionevole da impostare per gli utenti.

* OK, va bene, forse ai robot interesserebbe. Chiedimi di nuovo quando c'è l'Emendamento sui diritti dei robot.

Modifica: stavo rispondendo al titolo. Per rispondere a ulteriori domande nel tuo post:

So the question is, is it better to just set the password length limit to 72 characters or let users choose longer passwords [...] even though they will be truncated?

Non troncare silenziosamente. Non c'è alcun vantaggio in questo. O riceverai richieste di supporto "boo-hoo Non posso usare una password di 105 caratteri" o alla fine qualcuno scopre "OMG Devo solo inserire il primo 56% della mia password per far funzionare questa merda ?! ?!?". Penso che quest'ultimo abbia effettivamente un punto ragionevole e il primo sarà estremamente raro (se mai).

The first criterion is security and only then usability

Penso che potresti essere interessato a conoscere i certificati TLS sul lato client.