#1951 Change password policy to improve security for 'Edit Entry'

[Mark377]

For the following Policy option setting in effect:
Tools>Options>Policy(tab)>Feature(column): "Unhide Passwords*" not checked

In order to increase security while an 'Edit Entry' window is displayed on your screen, I'm requesting the current policy option be changed to:

1. Not show Quality entropy and number of character calculations.

2. Show a fixed number of asterisks to represent the hidden Password/Repeat for each and all entries. (Suggest hiding password with 2-4 asterisks or something else to indicate a password exists for the entry.)

These enhancements to the policy option setting would prevent curious people from seeing your entry's Quality information or counting the number of asterisks to get the password length.

Thanks for considering this feature request.

-Mark377

[Mark377]

[Updated 11-24-2014: added item 3, more explanation, and revised editing]

For the following Policy option setting in effect:
Tools>Options>Policy(tab)>Feature(column): "Unhide Passwords*" not checked

In order to increase security while an 'Edit Entry' window is displayed on your screen, I'm requesting the current policy option be changed to:

1. Do not show Quality entropy and number of character calculations.

2. Show a fixed number of asterisks to hide Password/Repeat for each and all entries.

3. Do not show Notes.

For 2: I suggest hiding the password with 1 or 2 asterisks, or display words like "password hidden", or omit Password line. This way a curious person wouldn't know anything about your password's length. (A fixed number of asterisks feature is similar to setting: View>Configure Columns>Standard Fields> "Password" box checked, (Password) Asterisks*** = "Yes" Now hidden passwords listed for all entries in groups are displayed by 8 asterisks.

For 3: If you copy/pasted security questions and answers from a secure website, and you are allowed to reset your password online (without having to speak to a representative), a malicious who saw your notes could reset your password by just answering your security questions and then log in to your website account.

If these changes were made to an unchecked "Unhide Passwords*" policy, then it make it much more difficult for a curious person to crack your password, and from seeing your notes containg security information which must be kept secret.

Thanks for considering this feature request.

-Mark377

[wellread1]

Further Discussion of the proposed feature:

While it makes sense to prevent information leakage that might be used nefariously and isn't particularly useful, the principal reason to provide the length and quality information is to aid the user to create a password of appropriate quality. This important assistance would be denied if the length and quality properties were blocked while editing an entry. I did not spot this problem with the proposal in the initial discussion thread.

While password properties are potentially useful in a password cracking attack, the value of these properties diminishes rapidly as password quality increases. Presumably a prudent user will use high quality passwords for valuable accounts. Furthermore, blocking display of these properties prevents the user from using them to identify passwords that should be strengthened.

Some users may not rely on password properties during password creation, but I suspect that is a minority. Even the minority is likely to value the ability to periodically and conveniently review password properties. Consequently, if a policy to block display of password properties were adopted at all, it should probably a separate Policy e.g. "Show Password Properties"

Hiding Notes as part of the the "Unhide Passwords*" policy would definitely be far out of the scope of this policy because Notes are not a property of a Password. Besides, there are alternate, and probably better ways, to save sensitive information such as security question answers (e.g. as protected custom string fields).

[Mark377]

Hi wellread1,

Yes I agree with what you said about the importance to show password properties in order to create a strong password, You wrote: "..if a policy to block display of password properties were adopted at all, it should probably a separate Policy e.g. "Show Password Properties" ". This works for me.

Finally, you pointed out that Notes are not a part of the password properties, so I'll look into protecting other sensitive information (I have in my Notes) with custom string fields as you suggested.

I appreciate your response.

-Mark377

[wellread1]

If you plan to use custom string fields I suggest you investigate the KPEnhancedEntryView by Alex Vallat. It increases accessibility to these fields, dramatically improving usability.

[Mark377]

I'll try out Alex Vallat's "KPEnhancedEntryView" plugin.

Thanks.