Is the date that a password was last changed useful to an attacker?

Question

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.

Answer 1

Case for plain-text:

1. The attacker could change all the dates for one time and repeat. Not a security vulnerability, but it could annoy the client to no end before it was discovered.
2. Your attacker could increase the number of password resets, therefore gaining more data to use in an attack.
3. If a dictionary attack is used the attacker knows to reset his dictionary attack.
4. Increasing the date would give the attacker more time for whatever attack he/she chooses and will violate your security planning
5. Since the majority of users generally change only one number or letter in their password this could open up an attack given some encryption schemes. If the attacker knows when to check the cypher text it would be easier to build a dictionary of past passwords.
6. If you are using grouped fields (you mentioned blobs) and list the date it changed the attacker knows the exact difference between the two cypher texts.

Case for encrypted text:

1. Based on the encryption scheme a history of the cypher texts could expose some knowledge of the plain text. If the attacker has figured out that your are using dates in your blob (possible since they aren't listed elsewhere) then he/she has a very limited key-space of plain text for that part of the blob. This could open up some vulnerabilities.

I don't know if any of this is practical. I am basing this on a 6 week course on cryptography at coursera, but it my two cents.