Particularly for data which are temporarily sent to the user's browser and then returned in a subsequent POST request. Obviously, sending the IV to the browser along with the encrypted text is a no-no! So how would one know which IV was used for a particular POST field? (You can see why people re-use/hardcode project IVs!)
Even for database data it would not be good practice to store the IV in the database containing the encrypted data: if the database is compromised then so are the IVs.
John Conde - 2020-06-19 14:17:37 - In reply to message 1 from Tofser
In an ideal world, everyone would have the resources to have an environment that is PCI compliant. Not because storing encryption IVs falls under PCI scope, but because these environments are designed for the ultimate data security. These environments, and their data stores, are restricted to users and services that require access (which should be no more than a handful at best) and are, by design, difficult to access (e.g. breach) due to these restrictions. They are also physically separate from the non-PCI environment. So if the primary environment is compromised additional work is required to compromise the secondary environment.
The IV is then correlated back to the record it belongs to via a lookup table or another field in the record that contains encrypted data.
Since most of us do not have access to a PCI environment we have to resort to alternative measures. The most common solution I have seen is to append the IV to the encrypted data when storing it. To an outside observer it just looks like one piece of data. This is effective only as long as the code is not compromised as well.