UX issues during OEM factory reset PIN / Password questionnaire

[UndeadDevel]

Please identify some basic details to help process the report

A. Provide Hardware Details

1. What board are you using (see list of boards here)? NV41 2. Does your computer have a dGPU or is it iGPU-only?

• [ ] dGPU
• [x] iGPU-only

3. Who installed Heads on this computer?

• [ ] Insurgo
• [x] Nitrokey (original; internally updated to NK Heads 2.4.1 myself later)
• [ ] Purism
• [ ] Other provider
• [ ] Self-installed

4. What PGP key is being used?

• [ ] Librem Key
• [ ] Nitrokey Pro 2
• [ ] Nitrokey Storage
• [ ] Yubikey
• [x] NK3

5. Are you using the PGP key to provide HOTP verification?

• [x] Yes
• [ ] No
• [ ] I don't know

B. Identify how the board was flashed

1. Is this problem related to updating heads or flashing it for the first time?

• [ ] First-time flash
• [ ] Updating heads

2. If the problem is related to an update, how did you attempt to apply the update?

• [ ] Using the Heads GUI
• [ ] Flashrom via the Recovery Shell
• [ ] External flashing

3. How was Heads initially flashed

• [x] External flashing
• [ ] Internal-only / 1vyrain
• [ ] Don't know

4. Was the board flashed with a maximized or non-maximized/legacy rom?

• [x] Maximized
• [ ] Non-maximized / legacy
• [ ] I don't know

5. If Heads was externally flashed, was IFD unlocked?

• [x] Yes
• [ ] No
• [ ] Don't know

C. Identify the rom related to this bug report

1. Did you download or build the rom at issue in this bug report?

• [x] I downloaded it
• [ ] I built it

2. If you downloaded your rom, where did you get it from?

• [ ] Heads CircleCi
• [ ] Purism
• [x] Nitrokey
• [ ] Somewhere else (please identify)

Please provide the release number or otherwise identify the rom downloaded NK Heads 2.4.1 3. If you built your rom, which repository:branch did you use?

• [ ] Heads:Master
• [ ] Other (please identify)

4. What version of coreboot did you use in building?

• [ ] 4.8.1 (current default in heads:master)
• [ ] 4.13
• [ ] 4.14
• [ ] 4.15
• [ ] Other (please specify)
• [ ] I don't know

5. In building the rom where did you get the blobs?

• [ ] No blobs required
• [ ] Provided by the company that installed Heads on the device
• [ ] Extracted from a backup rom taken from this device
• [ ] Extracted from another backup rom taken from another device (please identify the board model)
• [ ] Extracted from the online bios using the automated tools provided in Heads
• [ ] I don't know

Please describe the problem

Describe the bug There are two UX issues with the PIN / password entry part of OEM-factory-reset:

1. The question about setting distinct PINs / passwords, which comes after the question about setting a single custom password if the user answers no to that, has the default "No", even though that will set the default passwords ("123456" etc.) for those components, which is obviously not recommended. ~2. The minimum user PIN length is set to 8, even though the NitroKey docs explain that it is 6; the NitroKey app also requires only 6, not 8 and even Heads will set "123456" as default user PIN (while "12345678" is the default admin PIN). This can be an issue for people who have already memorized a 6 character / digit PIN as their user PIN (e.g. they've been using their dongle already previously) and suddenly Heads requires that they add two more characters / digits. I think this is probably an oversight (code likely just copied from the admin PIN section).~ (Edit: implemented in #1646)

To Reproduce

1. Run an OEM-factory-reset
2. answer "n" to default
3. answer "n" to custom password
4. answer "n" or Enter to question about distinct passwords for point 1 above ~or answer "y" to see incongruent user PIN requirement~ (Edit: last part implemented in #1646)

Expected behavior For 1.: The default should be "Yes". ~For 2.: Heads behaves consistently with itself and the NitroKey app / docs.~ (Edit: implemented in #1646)

[tlaurion]

https://github.com/linuxboot/heads/discussions/1521

[UndeadDevel]

I'll add your comment from the PR here, @tlaurion:

@UndeadDevel no problem with changing the pins lengths. I have no problem changing the default to setting custom PIN as well, but that is for those enforcing OEM factory reset prior of shipping, which is oem-factory-reset main use case, otherwise should be considered under https://github.com/linuxboot/heads/discussions/1521 bigger discussions.

Interesting discussion I didn't see before; thanks for linking it; I agree that OEM factory reset should be simplified and that generating randomized secrets OEM-side is a nice feature / better than the current "PleaseChangeMe" and "123456" etc., but my issue and PR is about the current state of things; it's fine if you want to hold merging until it's clear that this issue and PR are still relevant for whatever the next iteration of OEM factory reset will look like, but if it's a less fancy "simplify-only" change, then it definitely would be and I don't know how long it will take to do the rewrite of OEM factory reset, which is why I still think that my PR should be considered / merged.

I also disagree that "OEM factory reset prior of shipping" "is oem-factory-reset main use case", because, while that may be true of the OEM, from the user perspective it doesn't matter how the OEM prepares the product, as long as it's done well. The user is the one who will be making use of the various Heads functions, including OEM factory reset, for years; in my case I have now, in less than a year of using Heads, used OEM factory reset at least 5 times for various purposes; so the better approach, IMO, is to have some OEM mechanism to do the OEM stuff, e.g. pressing 'o' early in boot triggers a special OEM-version of OEM factory reset, which takes care of OEM's needs, while the OEM factory reset accessible from whiptail should be tailored toward the user's needs, not OEM's. I suppose the best solution then, for this issue, would actually be to remove that question entirely from the "user version" of OEM factory reset and always run that code if the user doesn't choose to set a single passphrase for everything, while in the OEM version of that code (when triggered early in boot by pressing 'o') it would instead always leave whatever the default passphrases / PINs are. But, again, this is hypothetical and contingent on a rewrite of OEM factory reset, while this issue and the associated PR are about the current state of affairs.

[tlaurion]

As stated @UndeadDevel I would prefer this PR to change solely lengths of PINs and the other points being copied to the referred discussion.

As of now, without going too deep in the details, the oem provisions with either default PINs or custom ones, where the current codebase takes decisions based on hotp_verification output for PIN retry counts (wrong as of writing), public signature age to decide if HOTP can be sealed with the default PIN. This bug was filed under https://github.com/Nitrokey/nitrokey-hotp-verification/issues/30

Then based on age of public key (<1 month), the user is reminded to change those pins on first use. That should fit the general OEM use case (reduce costs) and lead to users doing proper decisions based on their use case and threat model.

If hotp_verification was providing non-bogus output, the oem use case up to user first use and re-ownership would be encouraged to do exactly what you talk about, being well aware to not select provisioning of the usb security dongle with default PINs. And to not accept the defaults.

Let's not forget that most users are thought to not be developpers or code signers as of now, and provisioning default PINs is not a security concern if devices are shipped seperately. If custom PINs are defined, then current codebase of Heads won't warn the user to change their PINs. It depends if OEM wants to provision secrets to ship the devices together and if the burden of sharing secrets is desired. The goal of the discussion is to define the proper way that fits both oem /user cases, define requirements and then start to work on it.

--

Please recap in the discussion in light of those facts to explain your user need (missing in discussion) in a way stakeholders can also understand to make this discussion go forward. Splitting the codepath between oem/user needs will happen upon agreement not impacting OEM workflow. And your input is definitely needed there.

[UndeadDevel]

Done. Unlinked the PR from this issue, which is now contingent in resolution on the discussion in #1521.

[tlaurion]

@UndeadDevel could you please modify op to reflect state of discussion for desired future needed work and ~ratify~ what was done linking to merged PR?