A problem arises when I create a password policy that includes both "use only easy-to-read characters" and "at least n" letters, the ultimate consequence of which is that all the password policies are lost, with no explicit error or warning given to the user. I suspect that this is related to bug report #1492 "Password policy - 'Use at least n' not visible with easy-to-read characters".
To reproduce the problem, using Password Safe v3.49.01 64-bit on Windows 7 SP1 64-bit and the default Password Safe configuration, ...
Create a new database with 3 arbitrary entries (A, B, C), all using the default policy.
Create 3 password policies:
policy1: length=16, at least 12 lowercase, no uppercase, at least 1 digit, no symbols, use only Easy-to-read characters.
policy2: length=12, at least 1 lowercase, at least 1 uppercase, at least 1 digit, at least 1 symbol, no other constraints
policy3: length=8, at least 0 lower case only, no other constraints
Set database entry A to use policy1, B to use policy2, C to use policy3. (There's no need to generate passwords with those policies.)
Save the database, exit Password Safe. Run Password Safe again, open the database, check the entries and password policies - everything looks OK so far, although there is a hint of the problem described in bug #1492:
- On the Manage Password Policies dialog, policy1 does not list "at least n" for policy1 (in "Selected policy details") when I select that policy ("least n" is list for some, but not all, other policies). However when I edit the policy, the "Change/View a Database Named Policy" dialog does show "at least 12".
Now edit policy1: change password length to 8 without changing anything else - in particular do not change "at least 12" lowercase letters - then click OK to return to Manage Password Policies, and OK again to return to the main window. Save the database and exit Password Safe.
Run Password Safe again and open the database. Click Manage, Password Policies and select policy1 in the Manage Password Policies dialog - the "Selected policy details" now shows password length = 0 (zero) and all other fields as "No". Click Edit - the "Change/View a Database Named Policy" dialog shows password length = 4, and all checkboxes unticked.
Cancel both dialogs to return to the main window without changing anything.
Add a fourth arbitary database entry D, using the default password policy. Save the database and exit Password Safe.
Run Password Safe again and open the database. Click Manage, Password Policies - there are no named policies! The database entries (A, B, C) that used those policies now use the default policy.
Notes:
When I edited policy1 and made the password length shorter than "at least n lowercase" there was no error message. However if I first untick "easy-to-read" I do get an error message "Password length is less than the sum of 'at least' constraints" (which is what I expected).
I found this problem when I noticed that my password policies had disappeared. I went back and checked earlier versions (Thank-you for incremented number backups!) and found that with my database (which has more and different policies) the corruption of the password policies occurred over several saves - the second policy was corrupted at one point before they all disappeared. (I didn't try to reproduce that, because it would take longer. If it really matters, let me know and I'll have a go at reconstructing that sequence.)
The fact that policies completely disappeared some time after one (small test database) or more (larger real database) policies were corrupted suggests that the code might have detected a problem with the policy list and "fixed" it by deleting the policies. It's not catastrophic, but if that were the case the program should have told me explicitly, so that I knew immediately, which makes it easier for me to manually re-enter the policies and fix the database entries that point to them.
Using File, Compare to compare two database does not report differences in the password policies, only the database entries. I only remembered that I had changed the policy because I wondered why there was a separate incremental backup with apparently no changes between it and the previous one. If it's feasible, it would be useful to have the comparision report changes to the password policies.
More information (which might be more suited to #1492) ...
When I edited the named policy1 to make the password length shorter than minimum lower case letters, with easy-to-read enabled, Password Safe allowed it without warning, and then later the policy was lost.
However if I edit a database entry's policy directly, thus ...
Create new database entry, with entry-specific policy ("Use the Policy below") of length=16, at least 12 lowercase, no uppercase, at least 1 digit, no symbols, only easy-to-read, then click OK
Edit the database entry again, click Password Policy tab. Observe length=16 but no "at least n" visible.
Change password length to 8, then click OK. Password Safe says "Password length is les than sum of 'at least' constraints" - but the "at least" constraints are no longer visible.
Hi Mitch,
Thanks for taking the time to find a reproducible sequence and to explain it in sufficient detail.
As you've surmised, the problem was that the consistency checks on an editied password policy were incomplete, and that when PasswordSafe read a database with an inconsistent password policy, it removed it.
The fix implemented in commit 712576511 oes the following:
1. Checks correctly for total length being equal or larger than the sum of "at least N" constraints.
2. Correctly display "at least N" constraints in policy edit window.
3. Internal consistency checks in debug build to help catch similar problems earlier.
I haven't dealt with smarter error recovery and reporting, nor with comparing password policies as part of databqase compares - these should be separate tickets.\
I've uploaded pre-release build with the above fixes in
https://pwsafe.org/tmp/pwsafe-3.50.0pre1.exe
https://pwsafe.org/tmp/pwsafe64-3.50.0pre1.exe
and would appreciate it if you could give this version a spin.
There are still a few problems with 3.50.0pre1 (version "3, 50, 0, heads/BR1494-0-g712576511+").
Scenario 1:
Create a new database with 3 database entries and 3 password policies (1 used by each database entry) per original report.
Edit password policy1 thus:
Untick "Use lowercase letters". The "at least" control is disabled, but still shows 12. Note that the "at least" controls for the other unticked options are not disabled, so there is an inconsistency here (see Scenario 4).
Change password length to 8.
Click OK. Policy is accepted.
Click OK on Manage Password Policies to return to main window.
Save database and exit.
Start Password Safe again and open database.
View/Edit policy1. It now says length=4, with no checkboxes ticked.
Cancel the dialogs to return to the main window.
Create a 4th dabase entry D, using the default policy.
Save and exit
Start Password Safe again and open database.
Check the password policies - they've all disappeared.
Scenario 2:
Create a new database with 3 database entries and 3 password policies (1 used by each database entry) per original report.
Edit password policy1 thus:
Set password length to 8, (leave at least 12 lowercase)
Untick "Use only Easy-to-read".
Tick "Generate Pronounceable". Message box says "can't specify a minimum number of characters with 'pronounceable' option. Specified values ignored." (as expected), then disables "at least" controls (as expected).
Click OK. Message box says "Password length is less than sum of 'at least' constraints" - but the "at least" controls are disabled. Is it using them or ignoring them?
Cancel Change/View dialog (and confirm), so no changes are saved.
Edit password policy1 again:
Untick Easy-to-read
Tick Pronounceable. Message box says "can't specify a minimum number of characters with 'pronounceable' option. Specified values ignored." (as expected), then disables "at least" controls (as expected).
Untick "Use Digits", then tick it again. "At least" control is now enabled (still with the original value of 1), contrary to the still ticked Pronounceable.
Click OK. The policy is accept without warning/error.
Manage Password Policies dialog shows in the "Selected policy details" list for policy1 "at least 12" lowercase, "at least 1" digits, as well as Pronounceable: Yes.
Edit policy1 again. Before it shows me the Change/View a Database Name Policy dialog, a message box says "can't specify a minimum number of characters with 'pronounceable' option". Fair enough, but surely it should never have accepted the policy in the first place.
Scenario 3:
Create a new database
Create a new named policy4: length=12, at least 2 lowercase, at least 2 uppercase, at least 2 digits, at least 2 symbols, Easy-to-read.
Click OK. Manage Password Policies dialog shows in the "Selected policy details" list for policy4 "at least 2" lowercase, uppercase, digits, symbols: EasyVision - but does not mention "at least 2" symbols.
Create a new named policy5: length=12, at least 2 lowercase, at least 2 uppercase, at least 2 digits, at least 2 symbols, then tick Pronouncable. Message box says "can't specify a minimum number of characters with 'pronounceable' option. Specified values ignored." (as expected), then disables "at least" controls (as expected) - but those controls still show "2".
Click OK. Manage Password Policies dialog shows in the "Selected policy details" list for policy5 "at least 2" lowercase, uppercase, digits, (but not symbols), contrary to "Pronounceable.
Scenario 4:
Create a new database
Create a new named policy, and from the initial state of the dialog box:
Untick "use lowercase letters". The corresponding "at least" control is disabled (as expected.
Tick Easy-to-read. The "at least" dialog for "lowercase" is re-enabled.
Likewise for uppercase, digits, symbols. In each case unticking "Use letters/digits/symbols" disables the "at least" control, and ticking re-enables it. But ticking or unticking Easy-to-read always re-enables the "at least" control, even when "Use letters etc" is unticked. Similarly, unticking Pronounceable always re-enables the "at least" controls.
https://sourceforge.net/p/passwordsafe/feature-requests/879/ - warn user if inconsistency detected
https://sourceforge.net/p/passwordsafe/feature-requests/880/ - compare password policies
Thanks once again for spending time on this.
I haven't touched the enable/disable logic, but I have fixed the inconsistency that caused illegal policies to be saved and then rejected upon reading in the database.
I've also fixed the details of Symbols when "at least" is specified.
Both of these are in
https://pwsafe.org/tmp/pwsafe-3.50.0pre2.exe
https://pwsafe.org/tmp/pwsafe64-3.50.0pre2.exe
Feedback would be greatly appreciated.
Is the "at least n" upper/lower etc intended to be supported now with Easy-to-read? Recent changes to 3.50.0pre1 and pre2 suggest that it is, but there are still inconsistencies with the visibility of the "at least" fields.
Examples, with 3.50.0pre2 (3, 50, 0, heads/BR1494a-0-gfaaecc6bc+):
Create a new database
Edit the default password generation policy thus:
Set "at least 2" lowercase, uppercase, digits, symbols.
Tick Easy-to-read. The "at least" fields remain visible in the Change/View dialog, including after the changes have been saved and the dialog re-opened.
Create a database entry, with the default policy. On the Password Policy tab of the Add or Edit Entry dialog the "at least" fields are not visible.
(The same applies with named policies.)
Edit the database entry to "Use the policy below", and untick Easy-to-read. The "at least" fields remain invisible, even if Apply is clicked.
Click OK to return to the main window.
Edit the entry again and select the Password Policy tab. The "at least" fields are visible again.
Select "Use Database Policy", "Default". The "at least" field become invisible.
This leads to apparent failure to save changes, eg (with 3.50.0pre2):
Create a new password policy, with at least 2 lowercase and at least 0 upper, digits symbols.
Edit that policy to untick Use Lowercase (leaving "at least 2") and save.
Edit the policy again. Change "at least 2" (lowercase, which is not ticked) to "at least 3" and save.
Edit the policy again. The "at least" control has gone back to 2. Not a problem here, because it's not being used. But the failure to save a currently unused change might have unexpected consquences, such as https://sourceforge.net/p/passwordsafe/bugs/1496/
With 3.50.0pre2 (3, 50, 0, heads/BR1494a-0-gfaaecc6bc+), and the scenarios in https://sourceforge.net/p/passwordsafe/bugs/1494/#7ec3 ...
Scenario 1 appears to be fixed now.
Scenario 2 is unchanged. Password Safe tells me that it is ignoring the "at least" values, but does not ignore them when validating the entry ("Password length is less than sum of 'at least' constraints").
Scenario 3, policy4 now shows "at least n" symbols in the Manage Password Policies dialog.
Scenario 3, policy5 is still a problem in that the Manage Password Polices dialog still shows "at least n", even though the message box told me when I ticked Pronounceable that they would be ignored. And when I edit policy5 it tells me again (before displaying the edit dialog) that it will ignore them.
The visibility/checking of the "at least" fields on database entries (with "Use the Policy below" instead of default or named policy) is still a related problem. E.g, with 3.50.0pre2
Create a new database.
Create a database entry with a password policy of length=12, at least 8 lowercase, no uppercase, at least 1 digit, no symbols, Easy-to-read. Save the entry.
Edit that entry's policy again.
Change length to 8. Messagebox says "length is less than sum of 'at least' constraints" - but I can't see the "at least" fields.
Cancel that change and return to the main window.
Create another database entry, with a password policy of length=12, at least 8 lowercase, no uppercase, at least 1 digit, no symbols, Pronounceable. Save the entry. (Ignore the messagebox about "at least" values being ignored.)
Edit this entry's policy again.
Change length to 8 and save. No error or warning is given.
Edit this entry's policy again. Password length is 0, and all checkboxes are unticked.
(Should this be a separate bug report? It's datase entries instead of named policies, but the underlying logic/code is, or probably should be, the same.)