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:
- Am I going overboard with this? Should I just let users pay the price for being security unaware?
- Am I missing an obvious scenario that I need to prevent also?
- Can each scenario be evaluated using regex? This is the most extendable method of adding future checks that I can think of.
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!