search

Yubico / python-yubico

Python code to talk to YubiKeys
https://developers.yubico.com/python-yubico/
BSD 2-Clause "Simplified" License
229 stars 33 forks source link

Timeout issue when issuing repeated challenge-response requests #18

Closed sdigit closed 8 years ago

sdigit commented 9 years ago

This issue (https://github.com/Yubico/yubikey-personalization/issues/38) is also present in python-yubico. When challenge_response is used too quickly, a timeout occurs which leaves the yubikey unusable until it's unplugged and plugged back in.

While doing this: yk.challenge_response('foo',slot=2) over and over, after 5 to 10 tries this happens:

Traceback (most recent call last): File "", line 1, in File "build/bdist.linux-x86_64/egg/yubico/yubikey_usb_hid.py", line 214, in challenge_response File "build/bdist.linux-x86_64/egg/yubico/yubikey_usb_hid.py", line 273, in _challenge_response File "build/bdist.linux-x86_64/egg/yubico/yubikey_usb_hid.py", line 340, in _write File "build/bdist.linux-x86_64/egg/yubico/yubikey_usb_hid.py", line 381, in _waitfor_clear File "build/bdist.linux-x86_64/egg/yubico/yubikey_usb_hid.py", line 410, in _waitfor yubico.yubikey.YubiKeyTimeout: <YubiKeyTimeout instance at 0x7fe8ac622d70: Timed out waiting for YubiKey to clear status 0x80>

This does not happen with the ykchalresp utility which uses the C library.

dainnilsson commented 9 years ago

As with the linked issue, the fix should be to introduce a slight delay, most likely by moving the sleep to the beginning of the loop instead of the end: https://github.com/Yubico/python-yubico/blob/fed99e9b0b3d3866dbbab23a36648cdd68ffe2d7/yubico/yubikey_usb_hid.py#L402

sdigit commented 9 years ago

I tried that - after 8 successful responses it starts timing out every time. Not sure why it didn't work as it did in the C code. Specifically, I put a time.sleep(sleep) before this = self._read(); it works fine for a few requests but if done quickly it timed out on the 9th try.

sdigit commented 9 years ago

I have tried this with a second yubikey; it does not exhibit the same behavior. With a script that just loops on challenge_response it works fine with the 2nd yubikey, and dies after 6 with the first.

This issue can be closed, as it seems I've got a hardware problem instead.

dainnilsson commented 8 years ago

Weird. Well, I'll leave this issue open since I think it makes sense to apply the sleep fix to the Python code as well, since it's in the C code.

klali commented 8 years ago

When dealing with this issue in yubikey-personalization (IIRC) YubiKey standard showed this behaviour while the neo didn't. So if the first key tested was a standard and the second a neo or edge that might be it..

sdigit commented 8 years ago

Both are yubikey standards -- I setup the second one for HMAC-SHA1 on both config slots and can get responses in a loop with no trouble, the one that fails is interesting in that its always after five or six, never, say, three...