Keepassxc: Password generator should inherit the length of the current password

[droidmonkey]

Expected Behavior

When an entry exists and you open it and then open the password generator, the length setting should match the current length of the existing password.

Current Behavior

The length setting remains what was last used.

Debug Info

KeePassXC - Version 2.3.4-snapshot
Build Type: Snapshot
Revision: 161d6cd

Libraries:

• Qt 5.11.1
• libgcrypt 1.8.3

Operating system: Windows 10 (10.0)
CPU architecture: x86_64
Kernel: winnt 10.0.17134

Enabled extensions:

• Auto-Type
• Browser Integration
• Legacy Browser Integration (KeePassHTTP)
• SSH Agent
• YubiKey

[sts10]

Maybe new password should inherit the "Character Types" and other preferences as well? My thinking is that any password requirements on the existing password — not just length, but also special characters, as well as user preference on "look-alike characters" — will likely be also required of the new password.

[droidmonkey]

We should save the password settings in the custom attributes for that entry!

[TheZ3ro]

We should save the password settings in the custom attributes for that entry!

This will linearly increase the database size for every new entry, I wouldn't recommend it.
Do we want to sacrifice storage for a minimum user experience gain?

Inheriting the current length is much easier and won't affect the database size

[sts10]

Ah, I didn't think of that. Seems like a real trade-off if database size is increased.

I feel like this could be a bad/insecure idea, but would there be a way to _infer_ the Character Types settings from the existing password? Like: If special characters are present in existing password, use them in new password? My guess is this would muddle the code too much for y'all's taste, but just wanted to throw it out there.

[droidmonkey]

@TheZ3ro not necessarily true. We would only store the settings if the user actually used the password generator for that entry. This could of course be disabled in settings as well. We are also talking about a small amount of information (button states).

[TheZ3ro]

I tipically use the password generator for every password in my database and as of now I have ~100 passwords in it.

Assume that the button data can be represented with 10 char in a custom encoding, utf-8 they are 10 byte.
10 byte of data for each password in a db with 100 passwords is 1kb only of this extra data. (Imho acceptable)

But note that 10 char is a very small amount, if we use JSON or something like XML it will be much much more.

[droidmonkey]

Don't forget that the database XML is gzip compressed prior to encrypting which means duplicate data would be reduced significantly (ie, entries with the same PW settings). A good point, but we can test this to see the real impact.

[t4777sd]

I hope you rethink saving the password settings. In most cases I believe it is a bad idea.

I think "generator profiles" like KeePass has is a better use of resources. Saving PW settings could become very annoying. Imagine I am changing my password precisely _because I want it to have a different profile._ If you are saving my settings now it is causing me a bunch of work.

My passwords were previously all 8 lower case letters. Now I want them to be 12 length with mixed chars. Currently I just set this one time and go to each password and generate a new password.

With your proposed change I will have to alter the settings of every single password. How exhausting! This is a feature that can quickly turn into a nightmare.

On the other hand, Password Generator Profiles that KeepPass does has all the benefits of a "rememebred password profile" that you want to achieve with none of the downsides like I just described (when I up my security I just use 1 click to select my new ultra-high secure profile and no time wasted).

[sts10]

Dang, didn't think of @t4777sd's point. I dig the "Password Generator Profiles" route! Especially if it's only 1 or 2 clicks to apply them. Alternatively, I'd be fine with keeping things as they are in v 2.3.3.

[droidmonkey]

This ticket is mainly about inheriting just the current length of the password stored. The scenario you describe @t4777sd would be an ideal use case for the integrated password analyzer. Consider this scenario:

Open the analyzer and have it find all entries with low entropy or length less than a certain value. Select entries you want to update and then batch process them to generate new passwords with given parameters.

However, I don't know how your scenario is not a giant pain in the butt to begin with. Most services require you to enter your old password to change the password. Just changing the password in KeePassXC solves nothing and can actually lock you out of your accounts. I'm not entirely sold that your situation is common or desirable.

[t4777sd]

@droidmonkey that is why the analyzer doesn't solve the issue I just described because an analyzer that spits out passwords is of no help when I need to go to each service to change them.

I must go to each service to change each password. However, that does not matter because that is the same effort whether you remember password or settings.

So, I am focused on the effort differential on the parts of the process keepass is involved with. With remember password settings as you describe I must, in addition to going to each service to change it, re-create my desired password profile over and over and over again. Hopefully there are no mistakes! That is because the feature you describe will keep on forcing me into a bad password settings. _The very password file I am attempting to change away from!_

The current system is even better than the remember each individual password system. In the current system I just set 1 password to the profile I want. Then, as I change passwords I don't have to reconfigure it over and over again. It will remember it as the last password profile I did regardless of the entry.

Really the debate comes down to how people use passwords most. 1) Do most people have one basic password criteria and that is what they use. 2) Or, are people specifically putting in thought to have different profiles for every single service they use.

If #1 is the general use for most people, then your proposed improvement will just cause friction, wasted time, and pain-points for everyone who uses keepass. If #2 is the general use, then your proposed "remembering" feature will provide benefit.

I guarantee you that #1 is how most people use KeePass. I have seen people use keepass and how people use software in general and there is no way that people are focusing on highly varied profiles for 100 different profiles. They adopt something they are comfortable with like numbers, letters, digits and length of 10. And they use it for every single password except for those rare exceptions that a service will not accept their default profile password. If you were to think how you yourself use keepass I bet you that it is also #1 where 80% of your profiles have the exact same profile. If that is the case, then you know this new feature will be an anti-feature.

Of course, the best system is what I described and is the one KeePass went with and that is password profiles.

[t4777sd]

Btw, to clarify on why the analyzer provides little benefit is because you said it batch processes them which to me means htiting a button and all the passwords change. Which cannot actually be done in practice because people need to change them on the service side. So, no one would actually ever batch process a change.

Unless of course the analyzer is taking you through each and every password like a wizard where it presents to you the old and the new password and you confirm each and every single one when you actually updated it on the service side before it actually updates the keepass database.

I guess that would help solve the use-case I described of "updating" the entropy of passwords.

However, I am curious, why not just support password profiles which also seems to provide the same benefit as the remember password settings while at the same time providing a host of other benefits.

[droidmonkey]

I never said i wouldn't support pw profiles, there is an open issue for it. Thanks for your input.

[TheZ3ro]

We closed the issue for password generator profiles (#19) but I think it's a nice feature to have

Also I agree this issue should be fixed by inheriting the current length and not by storing every entry generator profile.

[kneitinger]

Looking to work on this issue. I'd like some feedback on proposed behavior:

• New entry and generator/Length not in keepassxc.ini -> use PasswordGenerator::DefaultLength (16 chars)
• New entry and generator/Length in keepassxc.ini -> use generator/Length (size of last generated password across all entries)
• Existing entry -> use current length

How does that sound?

[droidmonkey]

That approach is perfect.