La RFC non specifica, ma penso che se questi valori fossero disponibili, potrebbero aiutare l'aggressore.
Ad esempio, per scrypt, se il parametro dimensione del blocco r , i parametri costo CPU% memoriaN e il parametro di parallelismo p sono disponibili, l'attacco conoscerà quali valori utilizzare quando si applica la bruteforcing.
Qualche idea?
Direi che i parametri di costo contano come "dettagli di implementazione" e fare affidamento su di essi essendo nascosti sarebbe quindi sicurezza attraverso l'oscurità .
Mantenerli segreti in modo attivo sarebbe come usarli come una sorta di pepe a bassa entropia. Non interamente inutile, ma quasi. Inoltre, se un utente malintenzionato riesce a craccare una password, conoscerà i fattori corretti. Quindi prova solo password1 con alcuni fattori diversi su tutte le password e il gioco è fatto. Se si desidera un ulteriore segreto per proteggere le password, basta usare un normale pepe o crittografare gli hash. Quelle sono soluzioni realmente destinate a risolvere questo problema.
Questo non significa che devi rivelarli a tutto il mondo a meno che tu non abbia ragione di farlo. Certo, se vuoi dire a qualcuno di vantarsi di quanto è sicuro il tuo sistema, vai avanti. Ma non lo metterei sulla mia pagina web, specialmente se erano bassi, dal momento che potrebbero incoraggiare gli aggressori. (D'altra parte, dire "noi usiamo bcrypt" è come mettere un cartello "attenti al cane" sul recinto.)
La maggior parte delle persone usa uno dei pochi gruppi di fattori di costo. Ti incoraggio a scegliere i fattori di costo in base a ciò che è buono per il tuo sistema e non a ciò che è difficile da indovinare.
Si noti che il fattore di costo è proprio lì nell'hash, quindi è necessario ridurlo attivamente dalla stringa per implementarlo. Ma non mi preoccuperei.
Domanda piuttosto correlata: Posso condividere la funzione di hash della password che ho usato in un rapporto pubblico?