Replies: 15 comments 2 replies
-
|
Would it not be better to implement the yubikey since they have an open API? That would be a much more universal solution for one time passwords and we would not a) have to rely on google, and b) not have to use chrome. Also, as an added bonus yubikey supports PAM so you can use it for OTPs for logging on your system as well. https://www.yubico.com/products/yubikey-hardware/yubikey-2/ (I already use my yubikey for tomb by using the second slot for a static 64 bit string that I combine with a passphrase to get something I know + something I have. And yes, I have a second yubikey with a copy of the string in slot 2 squirreled away just in case it dies. Though OTPs would be even nicer.) |
Beta Was this translation helpful? Give feedback.
-
Yubikey isn't an open API, it's a proprietary one that a single company runs. U2F doesn't rely on Google. It doesn't even require use of any central, hosted service by any vendor. Unlike Yubikey, FIDO U2F actually is an open standard. Support is also not going to be limited to Chrome; Microsoft has committed to support U2F in Internet Explorer. This is all aside from how multiple vendors sell U2F hardware for $10-20, which makes it among the cheapest secure hardware tokens. |
Beta Was this translation helpful? Give feedback.
-
|
Yubikey most certainly is an open API. You can use their own libraries published under BSD, third party libraries or even write your own for that matter. And no, you don't require the use of a central hosted server. You can run your own, based on the above mentioned libraries, use third party validation server, or based on their own BSD licensed validation server software. Or even do everything completely offline, without the need for a network or a browser (Can FIDO U2F do that? Why would I want to have to use a browser for OTP with a command-line tool?). And both the transport protocol, the OTP protocoll and the algorithms are fully documented on their developer site. |
Beta Was this translation helpful? Give feedback.
-
FOSS-licensed clients do not make something an open API. Amazon AWS has plenty of FOSS clients but is definitely proprietary. The service YubiKey provides for the keys -- configured as they ship -- is not open. It is just no-cost.
These options are available only if you don't use the YubiKeys as shipped. You have to initialize them in a custom way, generally one-by-one unless you negotiate otherwise with Yubico. Even then, your only vendor can be Yubico. Multiple vendors make FIDO U2F-compatible tokens.
Yes. FIDO U2F doesn't require any special server or network connection at all. It's based on registering the token's public key, not keeping something secret on both the key and the authentication server. The token can then sign data that is validated using the public key.
You don't. U2F is an open standard with multiple library implementations. It should work fine from CLI applications. |
Beta Was this translation helpful? Give feedback.
-
I wasn't talking about the clients talking to yubikeys cloud servers here, but the server/offline implementation, since the previous is of no interest for this case (in my opinion). Basically what you are saying here is really doesn't make any difference since a) there actually isn't a definition of an open API, and that yubikey is well within the most commonly used definitions of an open API, including for example the p2p foundation. Also note that very few definitions go as far as defining an open API in the same terms as open data. I really would have liked to find the FSFs take on this, but I didn't find anything. Anyhow, this is completely moote, since it's all down to what you or I personally want, and only by following a FSF-isc definition would one consider this service not to be an open API.
This is cool. When I saw the first press releases I looked into FIDO U2F and was under the impression that the only available implementation was in chrome. This has obviously changed, or I was mistaken, so I guess I'll get that combined yubikey+FIDO U2F device after all.
You seem to know a lot about this. How is the key actually stored (I find it strange that you can use things as voice commands instead of a dongle and I can't quite see how a voice command or fingerprint can replace a private key stored on a dongle. Perhaps I'm missing something here? Finally I'm not quite sure that this needs to be a one or the other kind of thing. Looking at the available libraries, I think implementing one will lead to a very short road to implementing the other as well, which of course is the absolute best sollution (we all want freedom of choice here I'm guessing?) |
Beta Was this translation helpful? Give feedback.
-
|
No matter how open, closed or hilarious those things are, I don't see them being supported in Tomb anytime soon (if ever). They'd add extra dependencies to tomb, while providing no real security gains. If you want to have two factor "authentication" (there is no authentication in tomb, you open the lock with a key, no matter who you are) you just have to split the key file and store the halves separately. |
Beta Was this translation helpful? Give feedback.
-
Not necessarily. Something like this would have to be added by creating an external application for it. One would have to be insane to try to implement something like this in bash, hence one could simply check if the external application is available, and if so offer two factor «auth». On the other hand, that probably means it would be better to mirror the functionality of tomb in the external application and make it standalone. So yeah, I can see this never happening.
Or as I do split the pass phrase. I currently use a manually typed passphrase in combination with a 64 byte string stored in slot 2 of a yubikey. |
Beta Was this translation helpful? Give feedback.
-
Well, yeah, it could be an optional dependency.
Bear in mind that the pass phrase doesn't protect the tomb itself, but the key file. It's like chaining a key to your pants so that nobody can pick it from your pocket; they can still use a bump-key on the lock. |
Beta Was this translation helpful? Give feedback.
-
Indeed. But in my daily life I'm fairly sure that the highest risk is losing control of the keys. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for this interesting debate! its well informative. Some of us at dyne.org have passion for yubikeys https://www.dyne.org/software/yubiswitch/ but I'm not really one of them :^P My thoughts on the matter: The idea of having keys separated from tombs is already a sort DIY yubikey/U2F setup customizable with simple scripts to retrieve the key from usb keys or phones (over bt) or remote hosts (over ssh). To implement them in Tomb would certainly mean to make an application in extras/ which can be compiled and deployed by users if they want. Tomb will always stay as a minimum viable product (MVP) with a set of extras users are free to choose, this is actually part of its security model. I'm not sure if I or anyone else will find the tools and time to implement such an extra, but rest assured I will include it as soon as its there and it has been tested, as I have nothing really against the freedom to choose from many options as long as the MVP rest untouched without any more dependencies. |
Beta Was this translation helpful? Give feedback.
-
|
just a quick level-set yubico is a founding (i believe) member of fido, and one of the key contributors to the u2f spec. the yubikey neo was one of the first u2f devices. so if you like yubikey, use a neo with u2f |
Beta Was this translation helpful? Give feedback.
-
|
Time passed... anyone has a working setup with u2f, perhaps yubikey based? Folks at yubikey donated some neo models to make this possible, I can test anything already existing, or will hack on a solution soonish. |
Beta Was this translation helpful? Give feedback.
-
|
It looks like U2F can't be used for encryption: https://crypto.stackexchange.com/questions/44717/can-an-u2f-public-private-key-pair-for-signatures-be-used-for-encryption |
Beta Was this translation helpful? Give feedback.
-
|
If U2F uses ECDSA keys there is no way to do encryption with it. However, since Tomb 2.4, you don't need to use a U2F protocol to have a two factor authentication system. You only need to use Tomb with a GPG key in a smart card (including Yubikey like card). |
Beta Was this translation helpful? Give feedback.
-
|
This is what I want to hear. Thanks for the info! |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, which Yubikey? They have multiple solutions and hardware key... https://www.yubico.com/nl/product/yubikey-5-series/yubikey-5-nfc/ |
Beta Was this translation helpful? Give feedback.
-
|
Wow in some months this discussion will become 10yrs old <3 PS. I'm here cause I just searched online "tomb, dyne, yubico, yubikey" |
Beta Was this translation helpful? Give feedback.
-
I bought myself a cheap FIDO U2F dongle http://www.amazon.com/Plug-up-International-U2F-SK-01-FIDO-Security/dp/B00OGPO3ZS/ and that can be used without any driver (still need a udev rule on Linux though) as a 2nd factor authentication device on Google services (for now) and under Chrome/Chromium 38 only. Since the device is relatively cheap, capable of generating a public/private key pair, answering to a challenge/response and that FIDO/U2F protocol is open I was wondering if it could be used on LUKS based containers as second factor in addition to password. U2F tokens are generally based upon knwon smartcard ICs therefore they offer a significant amount of protection against key extraction.
Beta Was this translation helpful? Give feedback.
All reactions