It looks like an assumption, and a poor one at that. I'm certainly no security expert, and the danger here is almost absurdly obvious.
That said - the article addresses the claimed advantage of storing the value:
"The rationale was that as technology progressed and password cracking became easier, users could be contacted to update their password."
"The rationale was that as technology progressed and password cracking became easier, users could be contacted to update their password."
I would argue that this a misguided motivation for storing the password entropy. Bcrypt is purposefully designed to combat the problem of more efficient brute-forcing due to future GPU/CPU speed improvements by incorporating a 'work factor'. At any time, application owners can specifically increase the work factor and the hashing process will be intentionally slowed further. In this way, the future reversibility of the password hashes can be reduced without requiring that users update their passwords.
Re:A Tale of Security Gone Wrong
by gavingmiller on Thursday April 07, 2016 @06:49PM
(#11451320)
It's an assumption on my part, and anecdotally a correct one. Having included this entropy example in a number of talks and asking the audience what's wrong, the majority of the technical audience did not know, nor did they have an appropriate guess.
Can someone help me understand if this is an assumption or a status quo?
Then, what does storing this information gain you from an app owner perspective?