Preventing the Password Hint From Giving the Password Right Away

Question

I'm implementing a password + password hint code I and want to prevent the user from making the password hint reveal the actual password right away.

Here are the scenario that I want to prevent:

Lets say that the password is: foobar123

Then the password hint can't be:

• "foobar123"
• "The password is: foobar123"
• "f-o-o-b-a-r-1-2-3" (or any other x len separator)
• "f00bar123" (replace o with zeros)

several questions:

1. Am I going overboard with this? Should I just let users pay the price for being security unaware?
2. Am I missing an obvious scenario that I need to prevent also?
3. Can each scenario be evaluated using regex? This is the most extendable method of adding future checks that I can think of.

Answer 1

I would simply give the user a fixed set of questions to choose from, to which they supply the answer. In this way you are never exposing user input values, only the user's selected value from your pre-canned list of choices. This would avoid your problem entirely.

Alternatively, if you have the user's email address, you could simply have a password reset that sends a link with an encoded key that allows a one-time password change. This way you need not provide a hint, simply a means of changing the password in response to one of these single-use tickets.

Answer 2

Does it need to be a hinting model?

The way I've done this in the past is to:

A- Have a security question.
B- Have a captcha.
C- Provide a new temporary password to an email on file only that must be changed on first use.

Answer 3

1. Personally, I say you are probably going overboard. But it somewhat depends on both the severity of compromised data (e.g. is this a web site to vote for Ms. High School or is it a web site for high-end auction house or is it a web access form for CIA?), the amount of users, and the likelihood that anyone would sue you for negligence in design after using bad hint and having their access compromised.

2. You can do the regex for the most dumb ones (e.g. take 6-character sub-strings of the password and do a match of those sub-strings in the hint), as well as character count for the smart ones. E.g. if the hint uses 60 to 80% of the characters in password (by count), reject it. An even more nuanced solution is to count with position, e.g. count "o" only if it comes after "f". but this is probably overboard too.

3. Also consider non-hint solutions (multiple choices, non-verbal hints, e-mailable password change requests)

Answer 4

You can't prevent users from doing something dumb. No matter what protections you put in place, they will find a way to get around them. For example:

• "321raboof backwards"
• "foo and bar123"
• "foobar (124 - 1)"

Answer 5

I don't believe there's a deterministic way to generate a hint, unless you're limiting passwords to something like birthdays or given names.

But they wouldn't be strong passwords would they?

Let the user suggest a hint - and pay the price for an obvious one.

Give plenty of advice that the hint shouldn't be obvious, but I think it must be up to the user to decide.

Answer 6

It's not your problem if they compromise the security of their account. Save on unnecessary coding and testing, and just don't worry about this feature!

Answer 7

If your threat model makes password hints acceptable, I think you're going overboard with your meticulous password exposure prevention.

However, if your threat model doesn't make them acceptable, but you're being pressured into offering the feature, then be as fascist as you can.

Finally, don't limit people to canned password hints. They're extremely annoying. They imply that you know what is and isn't public knowledge in my life. Most of the sites I notice canned-only password hints on, offer hints that are all a matter of public record.

Good luck!

Answer 8

I am about to change our password hint model to one with canned choices. To those who said it's the users own problem if they put a stupid question and answer I would mention that it become the problem of those who work for our help desk tech support. That's what we'e trying to avoid.