On Fri, 8 Oct 2010, Dennis Gilmore wrote: > Even if you use your yubikey with yubicos servers. and auth against multiple > different providers your AES key is never exposed to to any of the places that > you auth to. That is correct if different service providers auth the OTP against yubicos servers. However when setting up your key, two places have to store the AES key. One is on your key, and one is on some backend auth server that directly or indirectly authenticates you. > to actually duplicate someones key you need to not only get the AES key. you > also need to know the session counter and keep yours higher than the real > user. which would make the real users key no longer work. and trigger warning > bells. The server validating your OTP ultimately is a server that knows everything about everyone configured yubikey. Whether that is an instance at Fedora, or an instance at yubicos. Things might be mitigated by putting openid in the middle, but ultimately the entire secret of your yubikey has to live at at least two places. This is unlike a public/private keypair solution where the private key can be only in your possession. This introduces an "all eggs in one basket" problem, and yubicos server's would be a very interesting target to attack. Again, I am not saying it makes yubikeys unsafe to use. But it is important to realise that the trust model is very different from a public/private key scheme that is usually found on token devices. You have to fully trust the endserver validating your key with all your secrets. When fedorahosted is compromised, by ssh key is not invalidated. When the yubikey backend server is compromised, everyone needs to zap their keys. There would also be a strong commercial incentive not to make such a compromise public. I am perfectly willing to trust fedora to have my AES key for purposes of logging into fedora servers. But I would not want to trust fedora infrastructure (or yubicos or another ID provider, especially located in for me questionable legal frameworks that include the US) for logging into my own infrastructure or servers or laptop. And if you share your key amonst multiple backend servers, you are reducing your key security to the least secure backend provider. > It sounds like you do not fully understand how the yubikeys work. either that > or i dont understand the attack you are describing? It all comes down to this being based on symmetric crypto, not on public key systems. The secret lives at two places, which is unlike modern crypto systems we've become used to, such as SSL/SSH, RSA/DSA or OTR. And again, I'd happilly use a yubikey with fedorahosted. I do think it is strong enough. Anf it will be useful for a lot of people especially because it is so much more affordable compared to other token based systems, and because the USB keyboard method allows for easy integration into most auth systems that deal with user/passwords. However for our own purposes, this system did not provide the security features we deemed mandatory (no coercion by third party, no sharing private key, no relaying trust to third parties, verifiable audit trail). I just wanted to relay this information so people understand the concepts, features and risks of yubikeys. Paul -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
