However; if a company uses "robust" password security and password hashes; is there a security need to then change these hashes ... as every time the hash is generated it will be different.

A parte: l'hash non è diverso ogni volta, è diverso per utente. Se un hash era diverso ogni volta che veniva calcolato non avremmo modo di confrontare la password inviata dall'utente e la password memorizzata.

Sì, c'è la necessità di sicurezza di cambiare le password quando sono compromesse - non c'è modo di sapere quanto fossero forti le password degli utenti, e non c'è modo di conoscere le capacità di hash delle password degli utenti malintenzionati. Se si perde un singolo salt, alta difficoltà bcrypt hash della password 'password', sarà comunque crackato in pochi minuti. Costringere gli utenti a reimpostare la propria password garantisce che anche le password deboli non vengano esposte.

Is it a good idea based on the idea some point in the future BCRYPTs may become easy to bruteforce?

No, la ragione è come sopra: stai isolando gli utenti dalle loro scelte di password deboli. Inoltre, un database di bcrypt rubato potrebbe diventare più fattibile alla forza bruta man mano che la potenza di elaborazione aumenta, ma A: Non vediamo aumenti drammatici della potenza di elaborazione con la stessa frequenza di alcuni anni fa e B: Idealmente, l'amministratore sta aumentando la difficoltà fattore dell'hash di bcrypt nel tempo - l'algoritmo è progettato per essere facilmente sintonizzabile per difficoltà.