[go: up one dir, main page]

|
|
Log in / Subscribe / Register

Security in an error-prone world

Security in an error-prone world

Posted Nov 12, 2015 14:52 UTC (Thu) by itvirta (guest, #49997)
In reply to: Security in an error-prone world by madhatter
Parent article: Security in an error-prone world

Does the NEO authenticate the device requesting it to sign a timestamp?

Because I started thinking about someone walking past one of them and asking it to sign
a timestamp for say, tomorrow, giving plenty of time to walk away and use the codes to login later.


to post comments

Security in an error-prone world

Posted Nov 12, 2015 18:51 UTC (Thu) by flussence (guest, #85566) [Link] (2 responses)

It's not possible to siphon codes off the key inconspicuously like that. The phone only provides UI, the key outputs the codes via USB HID to the computer it's plugged into.

Security in an error-prone world

Posted Nov 12, 2015 22:05 UTC (Thu) by johill (subscriber, #25196) [Link] (1 responses)

I'm pretty sure the response goes via NFC as well - it has two modes, NFC or USB, but I don't think it combines them like that.

Security in an error-prone world

Posted Nov 16, 2015 14:00 UTC (Mon) by itvirta (guest, #49997) [Link]

At the least the video about the Android app (https://www.yubico.com/tag/android/)
shows the app displaying the otp:s on the smartphone.
Though it also mentions a possibility of password protecting the credentials.

Can't tell why I didn't find this the first time, though...

Security in an error-prone world

Posted Nov 18, 2015 21:43 UTC (Wed) by nix (subscriber, #2304) [Link] (3 responses)

It has no clock so cannot do that. What the Yubico OTP protocol does have is a counter which increments whenever a password is requested, and another counter which increments whenever power to the key is cut (how this interacts with NFC I'm not sure because I don't have any devices that can do NFC to test it with). An authentication server verifies that any password it receives has a higher session counter than the last password it saw from that key, or, if the same, a higher password-requested counter. So replay attacks are impossible, and if you want to reuse a password you acquired you'd better do it before the legitimate user logs in again even once: as soon as he does that the password you snarfed is useless.

(This is not ideal -- backward-compatibility concerns limit the session counter to 7 bits, and obviously the protocol requires it to saturate rather than wrapping, so overflows are well within the bounds of possibility. But it's not *bad*, and you can reset the session counter by resetting the underlying AES key and sending the new one to your authentication servers.)

Security in an error-prone world

Posted Nov 20, 2015 10:01 UTC (Fri) by tao (subscriber, #17563) [Link] (2 responses)

Uhm. Maybe I'm missing something here -- are you saying that you can only have 128 sessions (7 bits) before you need to generate a new AES key? I'm fairly sure I'd burn through that in no-time. Or is session defined in some other way than I imagine?

Security in an error-prone world

Posted Nov 23, 2015 23:30 UTC (Mon) by nix (subscriber, #2304) [Link] (1 responses)

No, I can't count. It's 15 bits, not 7. 32767 sessions. A 'session' is a plug/unplug with at least one key generation in between, and even with my dodgy USB hub causing several replugs a day I'm not burning through them very fast.

Security in an error-prone world

Posted Nov 24, 2015 17:38 UTC (Tue) by tao (subscriber, #17563) [Link]

Ahhh, right. That sounds more reasonable :)


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds