Presenting vt-password errors to the user

[Max Spicer]

Hi,

I'm wondering how to present the errors that vt-password finds to the end user. I've set up quite a few validation rules to check for things like length, alphabetical and keyboard sequences, at least three of upper case, lower case, numbers, punctuation etc. The result of all this is that the user can get a daunting list of errors for a password.

One thing that makes this problem worse is that the sequence rules and the character class rules can generate multiple error messages for the same error. For example, if the password is abcdefgh then the sequence rules will create the following errors:

password contains the illegal sequence abc

password contains the illegal sequence bcd

password contains the illegal sequence cde

etc

With the character class rules, each class rule that is not met generates an error message and then the character class rule adds an extra message to say that not enough rules have been met. Example, with a password of 'trousers':

password must contain at least 1 digit

password must contain at least 1 uppercase characters

password must contain at least 1 non-alphanumeric characters

password matches 1 of 4 character rules, but 3 are required

This is problematic firstly because of the sheer number of error messages, but also because taken on their own they are actually incorrect. A password doesn't have to contain at least 1 digit, provided that it has sufficient other characteristics. The final 'password matches 1 of 4 character rules, but 3 are required' doesn't really make much sense when appearing on its own.

I'm thinking that in general the validators should be reworked a bit to reduce the number of errors they produce. The sequence validators should have the option of only reporting the first sequence found. The character class rules should only report one error, maybe with some optional sub-error messages.

Rather than just file bugs on this, I wanted to know how others use this in practice. At the moment, if the user was to try setting their password to 'a', they would get the following:

Password a is invalid because:

Password must be at least 8 characters in length.

Password contains the dictionary word 'a'.

Password contains the reversed dictionary word 'a'.

Password must contain at least 1 uppercase characters.

Password must contain at least 1 digit characters.

Password must contain at least 1 non-alphanumeric characters.

Password matches 1 of 4 character rules, but 3 are required.

Password contains the dictionary word 'a'.

Password contains the reversed dictionary word 'a'.

This is too much information! I'm thinking of putting my rules in some sort of order of priority and then only reporting the first three errors. However, this doesn't work because of the character class rules returning multiple errors.

Any thoughts?

Thanks,

Max Spicer

[Daniel Fisher]

There is certainly a balance to be struck between password complexity and error messages. We found that our users were more frustrated when they didn't get all the errors at once. For instance, if the user sees:

password contains the illegal sequence abc, then they correct that and see:

password contains the illegal sequence bcd, then they correct that and see:

password contains the illegal sequence cde, then they punch their computer.

A better compromise is probably to raise the sequence threshold to 5 or more.

I don't think there is any right or wrong answer, we just want the API to support whatever policies people find generally useful.

--Daniel Fisher

[Max Spicer]

Hi,

I can see your argument with the sequences. You could offer both solutions with an option on the AbstractSequenceRule controlling whether to report all found sequences or just the first.

The case of the error messages coming from the CharacterRules is more serious as the generated errors are actually wrong. If I create a CharacterCharacteristics rule set to match two out of LowercaseCharacterRule, UppercaseCharacterRule and DigitCharacterRule then validate a password of 'abc', I will get two errors: the password must contain an uppercase character; and the password must contain a digit character. This isn't true, as the password 'abcA' is perfectly valid and yet contains no digit. Likewise, 'A1' is valid but contains no lowercase character. I do not think the errors from the CharacterRules should be reported separately to the enveloping error from the CharacterCharacteristicsRule. To work around this, I've had to filter out the unwanted errors in my calling code and then write a completely custom error message for INSUFFICIENT_CHARACTERISTICS, setting it to something like "Passwords must contain at least two of the following: lowercase characters, uppercase characters, digits". This is a definite hack!

Max

--
 
---
You received this message because you are subscribed to the Google Groups "vt-middleware-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vt-middleware-u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Daniel Fisher]

On Tue, Aug 6, 2013 at 11:02 AM, Max Spicer <max.s...@york.ac.uk> wrote:

Hi,

I can see your argument with the sequences. You could offer both solutions with an option on the AbstractSequenceRule controlling whether to report all found sequences or just the first.

I think that is a good compromise.

 

The case of the error messages coming from the CharacterRules is more serious as the generated errors are actually wrong. If I create a CharacterCharacteristics rule set to match two out of LowercaseCharacterRule, UppercaseCharacterRule and DigitCharacterRule then validate a password of 'abc', I will get two errors: the password must contain an uppercase character; and the password must contain a digit character. This isn't true, as the password 'abcA' is perfectly valid and yet contains no digit. Likewise, 'A1' is valid but contains no lowercase character. I do not think the errors from the CharacterRules should be reported separately to the enveloping error from the CharacterCharacteristicsRule. To work around this, I've had to filter out the unwanted errors in my calling code and then write a completely custom error message for INSUFFICIENT_CHARACTERISTICS, setting it to something like "Passwords must contain at least two of the following: lowercase characters, uppercase characters, digits". This is a definite hack!

I like the simplicity of what you described, but I think it may be just as hard to generalize as what we already have. For instance, is your error message specific enough if configured with character rules that require > 1 character type? Once again we're back to usability, but if you require 3 digits and your message only says 'digits', is that enough information for your users?

Perhaps the characteristics rule could present a single error message that is derived from the messages produced from the rules it contains by modifying message properties and performing concatenation.

What if the message looked like: INSUFFICIENT_CHARACTERISTICS=Passwords must contain at least %2$s of the following:

and everything following the ':' was the messages produces by the rules it contained. In your case, INSUFFICIENT_CHARACTERS=%1$s %2$s characters

Since you aren't using the character rules outside of the characteristics rule the abbreviated message is only used as part of the enveloping rule. This would seem to be a good compromise and the implementation feels straight forward. Thoughts? Or did I just describe exactly what you implemented? ;)

--Daniel Fisher

 

[Max Spicer]

Hi,

Apologies for the delayed response.

I can see your argument with the sequences. You could offer both solutions with an option on the AbstractSequenceRule controlling whether to report all found sequences or just the first.

I think that is a good compromise.

I'll open an issue on this.

I like the simplicity of what you described, but I think it may be just as hard to generalize as what we already have. For instance, is your error message specific enough if configured with character rules that require > 1 character type? Once again we're back to usability, but if you require 3 digits and your message only says 'digits', is that enough information for your users?

My error message was only ever intended as a local workaround. As you say, it wouldn't work as a general solution.

 

Perhaps the characteristics rule could present a single error message that is derived from the messages produced from the rules it contains by modifying message properties and performing concatenation.

What if the message looked like: INSUFFICIENT_CHARACTERISTICS=Passwords must contain at least %2$s of the following:

and everything following the ':' was the messages produces by the rules it contained. In your case, INSUFFICIENT_CHARACTERS=%1$s %2$s characters

I think this is the way forward! Again, I'll open an issue.

Thanks,

Max