Version 1.0.6 breaks U2Fzero devices #97
Comments
nbraud
changed the title
|
Well, The U2F specification available here[0] specifies two different authentication modes; a "check-only" and a "require-user-presence" mode. What confuses me the most about this bug[1] is that it succeeds once and then fails on a second try. It's possible that this token doesn't like the check-only authentication attempt, which was what the My second hunch is that the double-authentication from @nbraud Is there a chance you could loan me a u2fzero token for testing? [0] - https://fidoalliance.org/specs/u2f-specs-1.0-bt-nfc-id-amendment/fido-u2f-raw-message-formats.html |
|
Hi, I tried many variants of configuration with the current debian packages but they all fail. See output here (Debian packages): $ LC_ALL="C" sudo su So this fails. Then i tried the current source versions (master branch with libu2f-server, libu2f-host, pam-u2f) jkur@durruti:~$ sudo su So it seems, that the "nodetect" option works with the u2fzero device. This is a Debian packaging issue then. Best regards! P.S.: is it save tp publish all the information from the debug log here? I wondered if you could find interesting information in all the keyhandle, challenge, etc information that is copied and pasted here. |
|
Ah cool, I was having a look at the log you posted on the Debian bugtracker and it seemed to me that the device was taking a long time to respond to a chunked message for no obvious reason. I also don't have a U2F Zero device so reproducing was a bit tricky. If everything works with latest things and it's just a packaging problem all is well then. Is it OK to close this issue? I don't know how U2F Zero encodes keyhandles, but it's typically safe to post those logs. The only stuff that you can get out is your user name, host name and the authentication counter. |
|
Besides, i have spare U2Fzero token around. If you (@cjoster) or someone else is located in germany, it would be possible to send a token for testing purposes. Otherwise i think it wouldn't make much sense, since a new token would be cheaper then sending it around. And yes, for me it's okay to close the issue, but maybe we could wait for @nbraud, because he is the maintainer involved. |
|
@jkur FYI, I have packaged the latest Regarding how to resolve this, I'm OK with the status quo, but it would be much better if there was a way to make the default configuration work with all devices. |
|
@jkur I have ordered a U2Fzero token and will experiment with it as you're right, by the time we ship the thing once, it's paid for. @nbraud I'm all for "make the default configuration work with all devices", which is what standards are for. Until I can prove it, I'm not going to accuse U2FZero of not following the standard, but I suspect that's what's occurring here. I'm also going to hit up U2FZero and see what they have to say about it. |
|
@jkur @cjoster Sorry for the headaches, this is likely my fault. There was some U2F Zero tokens in Europe with firmware version that had a bug with the check-only 0x07 command. The latest firmware and units sold in the U.S. should be fine. Anyone that purchased a EU token, feel free to reach out to me ([email protected]) for a refund. The EU stock listings have all been closed but unfortunately some tokens with this bug are in circulation. I appreciate it if anyone that can share this with anyone that purchased a token in europe. |
|
I can confirm that a U2FZero device purchased from Amazon US two days ago works fine against pam-u2f v1.0.7 without the |
|
Thanks for looking into this. I'll close the issue. |
I'm forwarding Debian bug #898519, where a user become unable to authenticate using their U2Fzero device after upgrading from 1.0.4 to 1.0.6.
A full debug log is included in the original bug, for both versions of
libpam-u2f, showing that the USB communication with the device times out. I was unable to confirm the bug independently, as I do not have a U2Fzero device.The text was updated successfully, but these errors were encountered: