Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

TOTP Tweaks #607

Closed
wants to merge 2 commits into from
Closed

TOTP Tweaks #607

wants to merge 2 commits into from

Conversation

MrChromebox
Copy link
Contributor

Reduce friction when generating a new TOTP/HOTP secret by eliminating an unnecessary 'press enter to continue' prompt following QR code generation, and by attempting to use the default admin PIN set by the OEM factory reset function. Fall back to prompting the user if the default PIN fails.

Update text on TOTP error prompt to provide better guidance for users following the use of the OEM factory reset function

Also, ensure error messages are visible to users before being returned back to the GUI menu from which they came by wrapping existing calls to die()

@MrChromebox
gui-init: update TOTP error prompt
7a3e3a4 
Update text on TOTP error prompt to provide better
guidance for users following the use of the OEM
factory reset function

Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
@MrChromebox
gui-init/seal-libremkey: reduce friction when generating new secret
4475615 
Reduce friction when generating a new TOTP/HOTP secret by elimiating
an unnecessary 'press enter to continue' prompt following QR code
generation, and by attempting to use the default admin PIN set by
the OEM factory reset function. Fall back to prompting the user
if the default PIN fails.

Also, ensure error messages are visibile to users before being returned
back to the GUI menu from which they came by wrapping existing calls to die()

Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
@tlaurion
Copy link
Collaborator

tlaurion commented Aug 27, 2019 via email •
edited
Loading

@MrChromebox
Copy link
Contributor Author

Not sure about consuming one attempt out of 3 with default oem password here.

I'm not seeing any limit on the number of attempts when calling libremkey_hotp_initialize with an admin (vs user) pin. Am I missing something there?

@tlaurion
Copy link
Collaborator

tlaurion commented Aug 30, 2019 via email •
edited
Loading

@MrChromebox
Copy link
Contributor Author

I do see in gnupg's documentation that 3 successive incorrect attempts to login with an admin PIN destroys the card -- which is really, really, bad given we don't warn the user at all, and most are likely completely unaware.

@kylerankin
Copy link
Collaborator

kylerankin commented Aug 30, 2019 •
edited
Loading

There are three separate secrets on a Librem Key or Nitrokey:

  1. GPG admin PIN on the OpenPGP smart card
  2. GPG user PIN on the OpenPGP smart card
  3. HOTP admin PIN on the Librem Key/Nitrokey flash chip

3 failures on #1 apparently destroys the smart card to protect the PIN (but I think this is configurable). In this case the HOTP secret and those functions would still work though--it's independent of the smart card. It's also important to note that the user rarely if ever actually uses the admin GPG PIN--they almost always use the user GPG PIN for operations.

3 failures on #2 locks the user and you have to use the admin PIN to unlock it again to use the GPG secrets. In this case the HOTP secret and those functions would still work though--it's independent of the smart card

3 failures on #3 I believe does nothing. My understanding is that you have unlimited tries against that PIN

@tlaurion
Copy link
Collaborator

tlaurion commented Aug 30, 2019 •
edited
Loading

There are three separate secrets on a Librem Key or Nitrokey:

1. GPG admin PIN on the OpenPGP smart card

2. GPG user PIN on the OpenPGP smart card

3. HOTP admin PIN on the Librem Key/Nitrokey flash chip

3 failures on #1 apparently destroys the smart card to protect the PIN (but I think this is configurable).

Unless a reset PIN code is set see todo subpoint.

In this case the HOTP secret and those functions would still work though--it's independent of the smart card. It's also important to note that the user rarely if ever actually uses the admin GPG PIN--they almost always use the user GPG PIN for operations.
But when resealing secrets, eg. in the case the LUKS header changed when setting a Disk Unlock Key and associated passphrase to be released by the TPM since triggering the same code path.

3 failures on #2 locks the user and you have to use the admin PIN to unlock it again to use the GPG secrets. In this case the HOTP secret and those functions would still work though--it's independent of the smart card

While using the same PIN?

3 failures on #3 I believe does nothing. My understanding is that you have unlimited tries against that PIN

I can't test right now. Thanks for validating this.

@MrChromebox
Copy link
Contributor Author

@tlaurion I was able to confirm that 3 incorrect admin pin entries when calling libremkey_hotp_initialize does indeed lock out the LK and require a reset

@MrChromebox
Copy link
Contributor Author

@tlaurion I'm going to drop this PR and resubmit the first commit (to which I don't believe there was any objection) with some others. I'll keep the 2nd commit in our tree for now until I figure out a better way to handle it

@MrChromebox MrChromebox deleted the totp-tweaks branch November 19, 2019 01:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@MrChromebox @tlaurion @kylerankin