I'm not entirely certain if this belongs on Information Security or here, so if it needs moved I'll delete it and repost.

An application I'm developing has a "feature" that alerts a user when a password they logged in with does not meet the password requirements. While this is not a common situation, it is possible that the password requirements were hardened after the user last changed their password. We test this on login, by validating the password they logged in with against the new requirements. If the password does not meet the new requirements, login is allowed but we inform the user via. a somewhat ugly message that their password doesn't meet the requirements.

Password Nag Notice

The message, for those who cannot view the image, is:

It looks like the last password you logged in with doesn't meet our requirements, we would really appreciate it if you would visit the @Html.ActionLink("'Change your password'", "ChangePassword") page and update it to meet them. Until then, we'll show you this reminder each time you login.

It's completely dismissible, and that works for the duration of the current session, so if you log-out then back in it will show up again, or if you log in on a different device it will appear again. However, if you do anything to update your password to conform to the newer restrictions, we remove the message as soon as that happens, so if you are logged on on three devices, and change your password on a fourth, the three others will have that message disappear on the next page load.

I'm not sure what is best, because any message implies that we don't store passwords securely (we do, we only test this on login and then flag the user profile), so I'm curious if there is an accepted behavior when it comes to this.

I thought about adding a tool tip that says "How do we know this?" and when the user hovers, explaining what method is used to show the message.

Every time you login we re-test your password against the policies configured in this website, if your password no longer meets these policies, we alert you. We also validate your password against recent data-breaches, to ensure we can provide the safest experience possible.

  • How could you know what the password is after they set it, if you are hashing them (a best practice)?
    – K.A.Monica
    Commented Sep 22, 2017 at 23:26
  • 1
    @K.A When they log in, if it succeeded, then I test the password they provided against the new regulations. I thought that was clear. Commented Sep 23, 2017 at 0:46
  • 2
    I'm undecided on this which is why I'm commenting rather than answering. But what about wording the message in such a way that it sounds like everyone is seeing it and must change their password. But only show it to those who need it. Thus those who see the message don't feel like they have been singled out or that their password has been interrogated. It feels a little dishonest as you'd be doing something while implying that you aren't, hence my hesitation. But it's a worthwhile consideration nonetheless
    – Darren H
    Commented Sep 23, 2017 at 10:09
  • @202_accepted: It does now. Thanx.
    – K.A.Monica
    Commented Sep 24, 2017 at 16:39

2 Answers 2


I would recommend simply redirecting all users who set their password before the new requirements to a "change password" page after they log in. Provide a message at the top of the form informing them that your password requirements have changed, and all users are required to reset their passwords. If you conduct some quick tests with the design of this page, you might find that people have concerns about a breach or something, and you could address those in the copy. Clearly show the new requirements, too, of course.

In my opinion, there's no need to broadcast the fact that you know anything about someone's password. Setting a new password may be inconvenient but it is not uncommon to be asked to do so (periodically, upon an update to the system, etc.).

  • The only problem with this is that it's quite difficult to have it tell all users that message, because passwords have no SetDate - I may add one, but I'm curious if just rewording the message to sound like all users are told this might be better. ("We've changed our password requirements since you last updated your password, please ...") Commented Sep 25, 2017 at 13:50

How about just testing length and displaying that in the warning (even if other policies exist).

  • That's the way to make a password the most secure anyway (longer length exponentially increases the difficulty of brute force hacking it, and other requirements like special characters make it harder to remember and more likely to be shared across sites or written down)
  • The user is confident that you are following best practices, because the length is self-evident in the password text field (you didn't need to know what the password actually was to display the warning).
  • The warning clearly diagnoses the problem and is easy to fix, instead of the unspecified "requirements" (it's frustrating to not know what is wrong with the password)

e g.

Your password is too short to meet our password length requirements. Please go to the "ChangePassword" page and choose a longer password at your earliest convenience.

Alternatively, or if the current password meets the length requirements but fails other requirements, consider showing a time-based message i.e. "Your password was last changed X days ago...". Once again, highlighting a single problem that is easy to fix and doesn't remind them that you know their password (during login).

  • Interestingly the requirements are: 12+ chars, no overly sequential/repeated/obvious sequences (123 is fine, 1234 barred), and it cannot have 'password', 'letmein', etc in it. (Take the top 25 most commonly used passwords from Wikipedia, and you cannot have or use one of those in your password.) I can show the specifically failed requirements, not hard to do that. Commented Sep 23, 2017 at 1:54
  • But yes- showing the specific reasons why the password fails would make me uncomfortable as a user because it reveals you knew what it was, even for a fleeting moment. That's why I was suggesting focusing on the length only.
    – J. Dimeo
    Commented Sep 23, 2017 at 1:58
  • So with this all said, would it still be worth including something like "How does this work?" that, when hovered, goes into detail on how we store passwords (PBKDF2), and tells the user exactly how we flag it (a "boolean" on the profile)? It might help assure the user that we're not doing anything that goes against best-practices with regard to storage/salting, also ensuring them that we're not doing anything bad with regards to testing it. Also, if you're curious on the requirements, see: codereview.stackexchange.com/questions/176382/… Commented Sep 23, 2017 at 14:07
  • Refactored to be more functional AND reasonable/effective password rules? you're my hero! As a power user, I always appreciate that level of detail, so as long as you can incorporate a tooltip like that unobtrusively (for example a simple (i) or (?) icon with the full details on hover), it can't hurt.
    – J. Dimeo
    Commented Sep 24, 2017 at 1:47
  • Believe it or not, on registration I actually have an i icon in the password box that tells you all the requirements: i.sstatic.net/8FNz3.png Commented Sep 24, 2017 at 12:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.