Obviously I want my application's users to change their passwords on some semi-regular basis (in fact a few of our apps must be UL-approved, and they require a system to enforce changing passwords every 90 days). The simplest way to do that is to store the last time the user changed their password on their record. I am also implementing a flag that, if set, basically marks their password as "temporary", forcing the user to change their password on their next successful login.
The question is simple: does storing this data in plain text (the flag and/or the date) expose a vulnerability?
I see one main attack vector, and it's rather serious; an attacker who gained edit rights to the user table could modify the date field or flag, forcing the user to change their password at will, possibly exposing it to a keylogger installed on the client machine. That does require multiple "ins", but if they get in one way they can get in other ways. Read-only information could still provide a similar vector by identifying the next user that must change their password, making them the next target for sniffing their new password.
I do have a system for password-based user data encryption already in place that obfuscates other sensitive data in the system; The question (which I may well have answered myself) is whether to include these fields in the encrypted blob. If I do so, it makes legitimately forcing users to change their passwords more difficult (I might want to force every user to change their password, and some other data to boot, if I were to discover the DB had been dumped), but also prevents an attacker doing the same.