Voglio fare alcuni punti oltre all'eccellente risposta di @ NeilSmithline.
Prendendo un valore casuale a 256 bit e tagliandolo con SHA-256, l'output avrà ancora (approssimativamente) 256 bit di entropia. Dico "all'incirca" perché è un problema aperto se SHA256 esegue effettivamente il mapping su ogni stringa possibile su 256 bit, ma per tutti gli scopi pratici è abbastanza vicino.
Bcrypt: il vantaggio di bcrypt è che richiede che l'attaccante esegua molti giri di hash su ogni ipotesi, rallentandoli e aumentando i costi dell'elettricità.
Forza brutale: Diciamo che un pazzo voleva provare brute-forzando le stringhe casuali 256 bit di SHA256. In media dovrebbero fare 2 supposizioni 255 . Supponendo che ogni ipotesi richieda 1 nanosecondo e consuma un valore di energia di un elettrone, ci vorrebbe 10 60 anni (che è 10 50 * ageOfUniverse) e richiederebbe un gruppo motopropulsore che consumi l'equivalente di energia di 9.000 galassie della Via Lattea . 2 256 è un numero grande.
Bottom line: Quindi sì, nessuno andrà bruto-forzando i valori casuali a 256-bit che hai eseguito attraverso SHA256 non salato, non c'è motivo di aggiungere calcoli extra sotto forma di bcrypt. Buon per te per aver pensato alla sicurezza e aver fatto delle belle domande: -)
(In realtà, il link debole è il generatore di numeri casuali, non l'hashing: se un utente malintenzionato può restringere l'elenco di possibili semi per l'RNG che ha generato quei valori casuali, potrebbe essere possibile un attacco di dizionario. caso bcrypt potrebbe aggiungere qualche rallentamento utile.)