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.

  • 1
    Correct me if I'm wrong, but wouldn't an attacker with write-access to the user table be able to do a huge amount of damage anyway? I'm also unconvinced that read-access is a great way to identify "next user to sniff"; wouldn't a keylogger work just as well on a typical login as on a password/change login?
    – GWLlosa
    Commented Dec 21, 2012 at 22:26
  • True all; this is the kind of thing I wanted to tease out. If the account were still vulnerable given the same vectors with or without the data in question, then that data isn't "sensitive". But, it remains to be demonstrated that this information would provide no significant advantage in any situation where it could be accessed.
    – KeithS
    Commented Dec 21, 2012 at 22:30
  • This leak may help the attacker to narrow down the time frame during which he has to do the keylogging, without any access to the DB, and possibly through non-software means (physical attack at the least secure premises, videokeylogger etc.). Other than that, can see no problem provided your database is secured. Commented Dec 22, 2012 at 17:33
  • Hey @KeithS on a slight tangent to your question, what specific document defines that 'UL Approved' applications must require regular password changes? I've never heard of this requirement before and haven't been able to find the relevant standard on the UL site. Edit: Just realized this was several years old after commenting.
    – PwdRsch
    Commented Sep 18, 2015 at 15:44
  • @PwdRsch - No problem. The specific document requiring this password policy is UL 1981 Second Edition, which governs site certification for alarm central station automation and monitoring systems. I don't have the document in front of me so I can't quote chapter and verse.
    – KeithS
    Commented Sep 24, 2015 at 18:14

2 Answers 2


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.


I think it would be useful to an attacker. Assume that

  1. I managed to get hold of a dated backup copy of your password table.
  2. Last changed is stored in plain text.

Then I could estimate the distribution of password ages. This would help me determine whether it is worth my computing time to try to brute force the passwords.

For example, if the password table is over 2 years old and the maximum password age is almost a year, then I will figure you force a password change every year and all the passwords are stale.

Alternatively, if the password table is a day old and the minimum password age is a year old (or belong to new users), then most likely all the passwords are still current.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .