Hai bisogno di usare lo stesso numero di round per tutti con bcrypt?

L'ottimizzazione del fattore di costo per BCrypt è principalmente un problema per le applicazioni lato server. Se il fattore di costo è troppo alto, il server può diventare molto occupato solo con il calcolo degli hash, quando un numero di persone tenta di accedere allo stesso tempo. Ecco perché cerchiamo di trovare un numero adeguato di round per questo server.

Se stai facendo il lato client di calcolo, ogni client ha abbastanza potenza CPU da solo per calcolare anche un gran numero di round, la potenza cresce con il numero di client. Tuttavia, le applicazioni Web dovrebbero calcolare il lato del server hash.

Se dai un'occhiata a questa implementazione in PHP vedrai che il numero di round è memorizzato in un database, che significa che è possibile modificare il numero di round, se necessario.

Quindi, se si memorizza il numero di round da qualche parte, non è necessario avere lo stesso numero di round per ogni utente.

Non è necessario avere lo stesso numero di round ovunque. Quando si esegue l'hashing di nuovo di una determinata password (ad esempio quando viene verificata una password), è necessario utilizzare lo stesso numero di round (in caso contrario non si ottiene lo stesso valore), quindi se il il numero non è hardcoded, quindi deve essere memorizzato insieme al valore di salt e hash. Ma la solita implementazione di bcrypt fa proprio questo: l'output è una stringa che codifica l'output effettivo a 192-bit ma anche il conteggio sale e iterazione.

Infatti, nella maggior parte dei casi in cui l'hashing della password si verifica sul lato client , il sale è ancora memorizzato sul server, quindi è necessario organizzare l'invio del sale come passaggio precedente; puoi inviare il conteggio delle iterazioni nello stesso messaggio.

Si noti, tuttavia, che la sicurezza extra contro la forza bruta è direttamente proporzionale a questo conteggio delle iterazioni, quindi le istanze in cui si consente che il conteggio dell'iterazione sia basso saranno relativamente più deboli. Questo conteggio è un compromesso tra sicurezza e comodità dell'utente: maggiore è il conteggio, migliore è la sicurezza, ma anche maggiore è l'attesa dell'utente umano.