Skip to content

New feature: hexadecimal password generator#1248

Closed
chuinul wants to merge 3 commits intokeepassxreboot:developfrom
chuinul:feature/hexadecimal-password
Closed

New feature: hexadecimal password generator#1248
chuinul wants to merge 3 commits intokeepassxreboot:developfrom
chuinul:feature/hexadecimal-password

Conversation

@chuinul
Copy link
Copy Markdown
Contributor

@chuinul chuinul commented Dec 1, 2017

Description

This PR adds a button in the password generator to select only hexadecimal characters, upper- or lower-cased depending on the need of the user.

Motivation and context

This solves #789, which states that "There are some [ed.: absurd?] use cases where one is required to generate a password which only consists of HEX characters".
I tried to keep it as light as possible. Because in the generator each button represents a class of disjoints characters, I've chosen to add another checkbox instead of another button.

How has this been tested?

There are GUI tests, checking that buttons and checkbox are properly greyed and checked when generating a hexadecimal password, and that the generated password contains only hexadecimal characters.
I've also tested it manually on Linux Mint 18.2.

Screenshots (if appropriate):

Types of changes

  • ✅ New feature (non-breaking change which adds functionality)

Checklist:

  • ✅ I have read the CONTRIBUTING document. [REQUIRED]
  • ✅ My code follows the code style of this project. [REQUIRED]
  • ✅ All new and existing tests passed. [REQUIRED]
  • ✅ I have compiled and verified my code with -DWITH_ASAN=ON. [REQUIRED]
  • ✅ I have added tests to cover my changes.

@droidmonkey
Copy link
Copy Markdown
Member

I believe there was a suggestion to use the existing A-Z and a-z buttons to delineate upper and lower case hex.

@chuinul
Copy link
Copy Markdown
Contributor Author

chuinul commented Dec 1, 2017

Yes there was. I don't know which solution is better. I began with this one because I felt using the existing buttons was a little confusing since it is not their original purpose. Besides, in my opinion, those two extra radio buttons are acceptable since they are on the same line. There is no waste of space.

But, yes, using the existing buttons is probably good as well. Only the other class of characters will be left grey. You tell me what you prefer.

@droidmonkey
Copy link
Copy Markdown
Member

Eh just keep it the way it is

Copy link
Copy Markdown
Member

@droidmonkey droidmonkey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor code style

m_ui->checkBoxUpper->setChecked(true);
m_ui->checkBoxLower->setChecked(false);
}
else {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No newline break

m_ui->checkBoxExcludeAlike->setChecked(false);
m_ui->checkBoxEnsureEvery->setChecked(false);
}
else {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No newline break

@mstarke
Copy link
Copy Markdown
Contributor

mstarke commented Dec 4, 2017

Might i suggest to include a custom character text field instead of a dedicated checkbox? I chose this method as well in MacPass to enable unexpected character sets

@droidmonkey
Copy link
Copy Markdown
Member

Would this work by putting in 0-9,A-F? Or do you have to put in every acceptable character?

@mstarke
Copy link
Copy Markdown
Contributor

mstarke commented Dec 5, 2017

Currently you would have to put in 0123456789abcdefABCDEF since I did not add any parsing mechanism. But I guess this is not that hard to add. It's flexible but not very comfortable.

@TheZ3ro
Copy link
Copy Markdown
Contributor

TheZ3ro commented Dec 5, 2017

What about adding A-F and a-f buttons?
We already have 0-9, users can press 0-9 a-f for hex lowercase and 0-9 A-F for hex uppercase
(the same as selecting mixed-case in the current UI, you click A-F and a-f, the user is already trained to do this)

What do you think?

@chuinul
Copy link
Copy Markdown
Contributor Author

chuinul commented Dec 5, 2017

@TheZ3ro I find those partially redundant buttons A-F and A-Z would be slightly confusing because their original purpose would only be implicit (and not obvious for the average Joe, hopefully one day a regular user of KeePassXC...). I really prefer to keep the paradigm of distinct character classes which may be combined as in the other keepass flavours.

From my point of view, the root of our problems is summarized in #820. Granted the password generator of KeePass is way too complicated. But the more features we will be asked to add, the more we will need some kind of (predefined and user defined) profiles. I have no solution to implement a flexible enough and easy to use password generator. But probably once done, that hexadecimal feature will be integrated to it rendering that workaround PR obsolete.

@TheZ3ro
Copy link
Copy Markdown
Contributor

TheZ3ro commented Dec 5, 2017

I think using the A-F buttons will simplify a lot the code, will require to only store 2 entry in the config file (instead of 3) and will better fit the UI.

How many times average Joe will need hex passwords?
The default is mixed-case alphanumeric and it's fine most of the time

Anyway, It's fine having the checkbox

@droidmonkey
Copy link
Copy Markdown
Member

This has become overcome by #1841

@droidmonkey droidmonkey removed this from the v2.4.0 milestone Aug 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants