Non avere un programma già pronto all'uso è un vantaggio irrisorio. Una volta che modificheranno hashcat o john the ripper sei al punto di partenza. Può essere una spina nel fianco per gli hacker della domenica, ma è un ostacolo da poco per chi è un po' più esperto.Però tralasciando la sicurezza matematica della cosa, penso che in questo caso utilizzare due hash renda la vita più difficile al attaccante, dato che per l' appunto c' è da "ingegnarsi" senza trovare soluzioni già pronte. So che bcrypt_sha256 non è altro che una combinazione dei due algoritmi, ma la lentezza per decodificarlo con software che si trovano in giro è molta di più, dato che al posto di partire da una semplice wordlist e tramite bcrypt paragonare ciascuna parola con la password codificata, in pratica bisogna partire da possibili password hashed con sha256 e solo in seguito utilizzare bcrypt (come nella funzione che ho riportato nell' altra risposta).
La velocità dell'algoritmo è praticamente irrilevante perché bcrypt è pensato per essere reso più lento o più veloce a seconda delle proprie esigenze. Quando chiami la funzione di hash hai un parametro da scegliere (un numero) che indica il costo dell'algoritmo. Passando da un costo c a un costo c+1 il numero di rounds raddoppia. Di norma si fanno migliaia di rounds e, chiaramente, se stai già facendo 4096 iterazioni (valore fissato in Django) di blowfish non è quella singola iterazione di sha a rallentarti. Se si fossero preoccupati che bcrypt non è abbastanza lento avrebbero semplicemente alzato il parametro costo.In più c'è il vantaggio che l' algoritmo risulta più lento rallentando di conseguenza i tentativi a forza bruta per il login.
Combinare funzioni di hash per aumentare la sicurezza è uno di quegli esempi del vero significato di don't roll your own crypto: prima di fare cose fuori dall'ordinario devi informarti bene, perché c'è il serio rischio di ottenere side effects indesiderati. In questo caso non penso che si siano inventati niente, però di sicuro non hanno aumentato la sicurezza perché dal punto di vista matematico l'hanno addirittura diminuita. È comunque un algoritmo sicuro, ma è meno sicuro di bcrypt liscio. Chiaramente le loro intenzioni erano altre, secondo me non volevano vietarti di inserire password più lunghe di 72 caratteri (scelta che personalmente non condivido).
Sì, volendo puoi procedere in questo modo, ma visto che stavi parlando di "riflettere a livello teorico" sappi che l'ostacolo vero è bcrypt perché sha256 è bello veloce. A livello pratico, io procederei a mo' di catena di montaggio. Con il codice discusso qui e il mio laptop vecchio di 7 anni riesco facilmente a calcolare qualche milione di sha256 al secondo (sulla cpu e in single core!). Il problema è che se la password è robusta non c'è niente che tu possa fare: bcrypt è sicuro.Forse non è del tutto inutile utilizzare una rainbow table in questo caso, dato che il salt viene applicato soltanto con bcrypt e non con sha256 (nella funzione che ho riportato sopra). Perciò si potrebbe partire da una serie di password precedentemente hashed con sha256 ed inseguito applicare bcrypt