"Wrong password, please reenter" after device reconnection #175
Comments
|
Thank you for the bug report! Unfortunately, I cannot reproduce this issue with 0.4.0. Do you only use a single Nitrokey device or multiple devices? |
|
And could you please try if you can reproduce this on the @d-e-s-o Could you please publish a bug-fix release with #145? I’m not sure if it is related to this issue, but I think it would be useful anyway. I often run into this problem when switching between my demo keys and my production key. |
|
I also fail to reproduce. Hm.
Sure, will do. It sounds as if the issues with and without cache may have the same root cause. Would it be possible for you to set a different user password (e.g., the default 123456; |
Single device only. On each reinsertion it gets new usb minor number: Could this be a cause? |
Hm, it works fine with default 123456. But I can reproduce the problem with 20-chars password, e.g. "12345678901234567890". |
Interesting. I still can’t reproduce the issue even with that user PIN. |
Yeah, same here. And I am on the same firmware version. |
|
I'll try devel version of nitrocli, but it will take some time. My gnupg version is 2.2.27, though problem was present with older versions as well. |
No, it should not be a problem, and the I see the same behavior on my machine. |
|
I tried new pinentry (1.1.1) — the problem persists, it is not a cause. Looks like I found what makes difference between my and your tests. Nitrokey provides hardware TRNG, so I utilize that to feed to the system entropy using scdrand (https://incenp.org/dvlpt/scdtools.html, app-crypt/scdrand in Gentoo). I don't run it as a daemon, since reads from TRNG by scdaemon may interfere with other device operations (e.g. gnupg signing and nitrocli actions), but I use it once using udev rule which effectively runs So necessary steps to reproduce are:
First I thought scdrand somehow resets cache, but if I run it without reconnecting the device, password entered is recognized from the first try. |
|
Really strange. I’ll try to install In the mean time, could you try to run this snippet directly using #include <stdio.h>
#include <stdlib.h>
#include <libnitrokey/NK_C_API.h>
static const char *USER_PIN = "123456";
int main(void)
{
NK_set_debug(true);
if (NK_login_auto() != 1) {
fprintf(stderr, "No Nitrokey device found.\n");
return 1;
}
int result = NK_enable_password_safe(USER_PIN);
if (result) {
fprintf(stderr, "Failed to enable password safe: %d\n", result);
return 1;
}
char *slot_name = NK_get_password_safe_slot_name(1);
if (!slot_name) {
fprintf(stderr, "Failed to query PWS slot: %d\n",
NK_get_last_command_status());
return 1;
}
printf("Slot 1: '%s'\n", slot_name);
free(slot_name);
NK_logout();
return 0;
}Change the |
Should it use OTP functionality, though? Seems like we are introducing another unknown by switching over to PWS. |
|
|
Grrrr. |
|
Please disregard my comment. I was confused. |
Yes, this also happens with libnitrokey (I use version 3.6). First run fails: Second run works: |
|
Thank you. I’ve created a libnitrokey issue: https://github.com/Nitrokey/libnitrokey/issues/201 Does the problem only occur if you remove the device? Or is it sufficient to just call Unfortunately, |
Both conditions must be fullfilled. Only running scdrand is not sufficient.
You need permission to write to /dev/random under user running scdrand. Try to enable SUID bit on it. |
Thanks. I had set the SUID bit but forgot to |
|
Can we close this issue? It seems as if there is nothing that |
Most likely, yes. |
|
Then let's close this issue as there is nothing actionable on the |
Hi!
If I used device successfully, than unplugged it and reconnected later, nitrocli will fail old password if cached:
and even worse if passwords are not cached: first entered password will be always invalid, so user have to enter password twice:
Curious, but after "wrong password, please reenter" message user retry count is not changed:
I use nitrocli-0.4.0, though this bug was present in earlier versions as well (at least in 0.3.5).
While this problem is not critical, it is really irritating to enter password twice. And often disconnect the device, so it is used only per on-needed basis.
The text was updated successfully, but these errors were encountered: