7 ms·

As someone who is comfortable with TOTP but hasn't tried FIDO-/Yubikey-style devices, I have a few questions: - Are drivers for this already installed as part

• lvh 6y ago
  Can't speak for this thing specifically, but FIDO2 keys in general: - Yes, you have everything you need on every major OS/browser - These devices are zeroconf; resetting it actually kills a security feature (key use increments) aiming at cloned devices - The ideal backup for this is to have a separate key, both authorized. They don't need to have the same material, in fact, cloning it would be considered a weakness (how do you know someone hasn't cloned it without your knowledge?)
  • Groxx 6y ago
    >- The ideal backup for this is to have a separate key, both authorized. This in particular is important. Security is only as strong as your weakest link, so any backup methods (e.g. "forgot password" flows) might as well be your primary method, if you actually care to strongly secure things. Adding another (or more) key gets you same-security redundancy if one fails or is lost. Nothing else will achieve this. Degrading to "forgot password" may be entirely fine for [person's] use of a security key, but you must be explicit about that decision, or it's mostly security snake-oil.
    • xur17 6y ago
      This is one thing I hate about these keys though - some services only support one key, and for ones that support multiple, I struggle to figure out a storage system for my backup key. I don't want to keep it with me (because then I am at risk of losing both), but if I keep it separate, I need to remember to add it to new accounts - there's no way to see a list of accounts a key has been associated with. I'm curious how others handle this.
      • g_p 6y ago
        This is the biggest weakness of U2F unfortunately. My approach is to keep a list (a simple text file) of what services are used for U2F, and which keys are enrolled with it. Most services ask or require you to name the token you enrol (if they support multiple tokens) - I gave the tokens names so they're consistent. Now I have 2 ways to check - logging into a site, you can see what keys are enrolled. And as fallback, I can use my underlying text file and see which keys I enrolled. You just need to make a point to check the file once every so often (at least first time you are near your backup key after having edited the text file). I've seen some interesting approaches (on modifiable tokens where keys can be exported) where they configure a backup key as a mirror of the main key, but with the counter advanced forward such that using the backup will invalidate the regular (thus alerting you to the use of the backup by an adversary, as long as the service properly validates the counter). I can't think of an easy solution to this (it is effectively the key distribution problem) without adding complexity (like manager software for tokens, and a Shamir's secret sharing style way to export a token's root key through SSS such that it can be recovered by a quorum of keys in an emergency). That breaks various aspects of the threat model though. Perhaps there's a less complex way to do it though? Like having up to N persistent public key slots on the token, where public keys of your other tokens can reside. When registering, the generated key is also encrypted "to" those tokens, and sent as supplementary key handles. You'd need to add a pairing relationship to validate authenticity of the key handles, but I suppose it could work.
      • user3939382 6y ago
        My threat model is focused on remote attacks, I consider physical access to my workstation game over. So one stays on my keys, one on my wife’s keys, and one stays plugged into my workstation. If I’m enrolling the keys with a given service I make sure to add or remove all three at the same time so I don’t have to track which is associated with different accounts.
• g_p 6y ago
  1. I'm not aware of any drivers being needed on any common platform. Support in Android apps is sometimes not perfect, but that's an app issue rather than a driver issue. 2. No software is required - far easier to use than you describe. You insert it, tap the button when prompted, and that's it. The token will decrypt an wrapped key (held by the remote service) using a hardware backed key, and sign an attestation using it. This attestation is tied to the domain name and URL scheme being accessed, so it "prevents" phishing as you can't trick users into relaying useful tokens. Note for FIDO2 there may be software to help manage more complex setups like "no username and password needed to login". If you're talking U2F (i.e. just 2FA), no software required. 3. You don't. There isn't anything to back up. You cannot export the internal key state, but services you use hold the (wrapped, encrypted and authenticated) key used for their service server-side. Your device just decrypts it, uses it, and discards it. You do need to think about backup, but you do that by enrolling 2 or more U2F/FIDO2 keys on each service you protect. That's the downside - you need to remember to enrol both keys on each service, every time you make a new account you protect with U2F. 4. Not really, beyond support at service side being limited (mostly) to big security-aware services.
  • asnelt 6y ago
    Regarding support on Android, if you are using a custom rom like LineageOS without Google Play Services then it won't work currently. Unfortunately, Google implemented FIDO2 in the play services, not in AOSP: https://bugs.chromium.org/p/chromium/issues/detail?id=997538 https://bugs.chromium.org/p/chromium/issues/detail?id=997538
    • g_p 6y ago
      Interesting and disappointingly. In this case I was testing it with play services, using the nextcloud app. I believe they are using something slightly custom from an open SDK, and suspect the outdoor was at their end. It seems strange Google put fido2 into play services, but that's certainly what they seem to "need" to do to get things shipped, given the lack of prompt Android release updates (don't even start me on longevity...) Still unfortunate every time this happens, as AOSP just loses more and more functionality.
• arianvanp 6y ago
  It uses USB HID as a transport. It should work out of the box on windows 10 and ubuntu. Microsoft is actually one of the largest forces behind the FIDO2 spec. Windows Hello implements FIDO2 too so you can use it dven without a dongle but just with your biometric reader on our laptop
• roblabla 6y ago
  I use a yubikey, but I suppose the Solo will be similar. > - Are drivers for this already installed as part of desktop Ubuntu 20.10/Windows 10? Any driver installation will absolutely make this a no-go for family members. On windows10, yes. I haven't tried it on Ubuntu 20.10 yet, but I think FIDO/WebAuthN will Just Work. (PIV will likely need custom software, but if you're using PIV, you probably know what you're doing). > - Is additional software required for anything non-techies might reasonably want to do with this device, including resetting it I mean, you rarely want to reset your key to start with, but at least for the yubikey, this requires external software last I checked. Maybe there's a button hidden in the chrome browser UI, but I've never found it. You need yubikey manager (which is yubikey's tool for doing various operations on the yubikey, like configuring what the touch button does, etc...). > adding an entry This is done entirely through your browser when setting up 2FA for a website that supports FIDO/WebAuthN. This is done entirely transparently for the user. > or checking which entries are already on the device? I don't think you even can do this. I'm not entirely sure how FIDO works, but I think the key is basically derived from some kind of "master" key combined with the domain you're connecting to. So the key doesn't actually have any memory of which servers it ever connected to. > - Is there anything else which would likely stop non-techies from using this for basically everything they care about? Well, technically, I don't think there's anything. WebAuthN is rock solid and the UX is really as good as it gets, IMO. The problem is, for many people 2FA is a hassle they don't want to go through. They don't see the need for it. And TBF, for many people, they might be right: they might not need it. So why go through the hassle?
  • g_p 6y ago
    > I don't think you even can do this. I'm not entirely sure how FIDO works, but I think the key is basically derived from some kind of "master" key combined with the domain you're connecting to. So the key doesn't actually have any memory of which servers it ever connected to. Indeed, this is one of the most elegant features of U2F - it preserves security and privacy even in relatively adversarial edge cases. Your token has a hardware-backed long term key in it (well, one for encryption and one for authentication). When you enrol on a website, the token generates a new asymmetric keypair internally, then encrypts and authenticates it with the long lived keys. The registration bundle sent to the server is called a "key handle", but is typically just the a hardware wrapped key. When you visit a site and log in, on the 2fa prompt, the site sends the encrypted wrapped key back to the browser, and it tries verifies it's a valid key, then decrypts it, and does a challenge-response authentication that's tied to the HTTP origin (domain and port) of the request. What's quite nice is that (outside of a few corner cases like looking at counter values and trying to correlate), you can safely use one u2f key with multiple accounts on multiple services, and none can be linked by the u2f key. (Of course they can be linked through other means, but the token won't be that link)
• EvangelicalPig 6y ago
  Some Linux distributions require adding udev rules for applications to have USB device access but other then that, it's pretty much plug and play. A bit more convenient than having to use the YubiKey apps for TOTP and such.
  • amluto 6y ago
    My now-defunct u2f-hidraw-policy package did this in a generic manner. The code was subsequently ported into the upstream udev code, so any up to date distro should automatically detect and handle U2F devices. If they don’t, file an issue with upstream systemd and it’ll get fixed. Feel free to file an issue on u2f-hidraw-policy too if you want my attention.
    • EvangelicalPig 6y ago
      Was not aware. Thank you!
• conorpp 6y ago
  Just wanted to add since I didn't see this covered in other comments yet -- TOTP and any sort of one time code authentication are just as phishable as passwords. Perhaps the biggest benefit for most people using U2F or FIDO2, is the large resistance to phishing. This is because of how the whole ecosystem has adopted FIDO2. When a FIDO2 key signs an assertion for a website, it includes the domain in the signature base, e.g. "example.com". The browser enforces that the request to the FIDO2 key always uses the correct name of the domain you're on. If you accidentally go to a fake website, "exaample.com", then the key will make a signature for "exaample.com", which is invalid for "example.com". Nothing can be phished to get around that, unlike OTP codes. Even if you have other 2FA options linked to your account, as long as you're using your FIDO2 key, you gain this benefit. Very strong benefit for both individuals and enterprises.
  • vlovich123 6y ago
    I look at it like nothing < SMS 2fac, app OTP, fido2. Every layer buys you a little bit (or a lot) more, raising the skill level and/or cost. Fido2 is much harder to phish but of course weaknesses may be found in the future.
  • tialaramex 6y ago
    > If you accidentally go to a fake website, "exaample.com", then the key will make a signature for "exaample.com", which is invalid for "example.com". This actually isn't true - the result is even better. When you visit fake.example instead of real.example there are two scenarios: For FIDO2 (like this product) with usernameless mode, just as with a modern iPhone or fancy Android with fingerprint reader, the authenticator knows perfectly well that you've never registered at fake.example so, you can't very well authenticate to it, you get an error. With FIDO1 (or on sites that don't use the usernameless feature anyway) the authenticator has no idea you've never visited fake.example... but the site has to hand over an opaque ID, a large binary blob. This is (either directly or in effect) actually your private key, encrypted in AEAD mode using a symmetric key known only to your authenticator. Another ingredient to this encryption is the domain name. So either fake.example hands over a random blob, which is gibberish, or they hand over a genuine real.example blob... but they're fake.example so the decryption fails. You get an error. The way I found this out was by trying it, I built a toy site with WebAuthn authentication. If I run the same code, on another site I own, it gets an error in the Javascript telling it that apparently I don't yet have a Security Key enrolled for this site, maybe it should enroll me first. If I tell it to pretend it's a different site, it gets an error saying no it isn't. [ The bad guys could enroll you, but now you're really signing into their web site. Which is cool, but, doesn't actually help them phish credentials for the other site ]
• kelnos 6y ago
  Others have answered most of your questions, but there's something I think deserves emphasizing: In general, you cannot (by design) back up these devices; if you could, that would defeat a lot of the security they provide. That means that if you lose it, you will have to find a way to get 2FA disabled for each and every account you enabled it for. Some orgs will have pretty onerous (but necessary!) processes for doing so, like having to provide government ID or physically visiting a brick-and-mortar location to prove your identity and ownership of the account. Some sites will allow you to simultaneously enroll two devices, so you can keep one as a backup, safe somewhere (though not too safe; if you were to, say, put it in a bank safe deposit box, it'd be a pain to fetch it any time you want to add a new account). But many sites only allow a single device to be enrolled. Some (like Yubico) let you purchase a "cloned" set of devices, where you can get two (or more) devices with the same keys on them, so you could actually put one of them in a safe deposit box as soon as it comes in the mail to act as a backup. That also solves the issue of some sites only supporting one device, as all of the devices in the set are effectively the same device. However, it doesn't appear that this is an option with the Solo keys (not certain of this; happy to be wrong about it; it's possible that you might be able to wipe the key material off new Solo keys and put identical copies of new self-generated material onto more than one key). On the flip side, if someone steals your backup key, it becomes harder to deal with the situation; with distinct keys, you can just revoke access to the stolen key. But with cloned keys, revoking access to the stolen key will also revoke the key you use daily. I just wanted to bring this aspect up, because people unfamiliar with these devices need to understand the consequences if they lose their key; it can be a huge pain in the ass to rectify that situation. This might be an understandably big turn-off to non-techies who are just looking to add a little extra security, but not a big maintenance burden and difficult failure modes.
  • stouset 6y ago
    > Some (like Yubico) let you purchase a "cloned" set of devices Wait, they do? How? I would love to do this, but I can't find anything relevant on their website.
    • _trampeltier 6y ago
• barkingcat 6y ago
  The general idea is not to backup these devices. To make a backup, you get 2 different keys and set them both up. The second one you keep somewhere safe, for example in a safety deposit box at a bank.
• l0b0 6y ago
  Thank you all so much for the answers! Sorry for my ignorance (or laziness, since I haven't read up on this and don't know of a disinterested guide for techies) about backups; not allowing it is a completely understandable trade-off between security and convenience. It sounds like this is a perfect solution for people at high risk of phishing, a good solution for somewhat technical laypeople with something important to protect which supports this (like a bank account), and too much hassle/risk of losing access/lack of support for most people/use cases. Does that sound fair?
  • tialaramex 6y ago
    I guess. However, I'd add that it's also definitely a sensible thing to require of people, however non-technical, where you've got some out-of-band way to issue and re-issue these authenticators to those people. Suppose you're Twitter. If every Twitter employee has a FIDO2 device and they need to tap it to begin their work day, and to confirm any important actions like "Block YetAnotherNazi" or "Validate that this Twitter account really does represent Jim's 24 hour Celery and Dog Collar Deliveries" then instantly a bunch of your security problems disappear, and all you need are your existing procedures that stop random people walking into your offices off the street and pretending to be employees, which, I'm going to guess, is already a problem you've got at Twitter. I can't see any reason a university wouldn't do this for its students for example. Or a hospital for its medical staff. Or a police force for... all the cops. These are very easy to use, with that one sharp edge of "What if I lose it?" which is not a problem if your organisation already has procedures to ensure only the right people get physical ID.
• vladvasiliu 6y ago
  As others have said, the key not being easy to clone is a feature. While I understand why this is and which threat models this addresses, I still think that this shouldn't be an all or nothing proposition. In the general case, meaning not for people with access to "secure systems" (corporate) or who are high-profile enough to have reason to believe that they themselves may be a target, I think that having "less secure" keys which can be cloned by "non-techies" might still be an improvement to the overall security of the internet. I didn't do any research, but according to the linked Kickstarter page: Solo V2 greatly reduces the risk of security breaches, as over 80% of all breaches are caused by passwords compromised through phishing email attacks. So physically stealing credentials isn't as widespread a risk as phishing, which doesn't really surprise me. Therefore I think Webauthn with "cloneable" keys would be a net positive for "regular people". This wouldn't preclude "techies" from using more secure, unclonable keys like the Yubikey & friends. But my grandma could also use a "less secure" one without the risk of having to go through resetting 100 different sites and would be able to setup a new key just by having me walk her through the process of restoring a key from a backup. I'm a "techie" and even I would like such a key for use on random "must absolutely register" websites. Of course there's the issue that if the key is lost you can't easily revoke it. But even with the proposed system of having a backup key registered or going through the recover account process, as long as you don't actively go unregister the lost key it's still registered and working. So if the authentication is based on some sort of counter, the process of effectively disabling the lost token shouldn't be any harder in this configuration.
• sammorrowdrums 6y ago
  No drivers were needed for my Ubuntu setup or phone, but to have desktop Yubi authenticator app and turn on Linux hardware auth for sudo, login, TTY, I did add a ppa. There instructions for that were good though. And when setting up any 2fa, need to have two keys and enroll them both, to give a chance of account recovery. edit I purchased one for my wife and only properly understood when it arrived that it would need to be first used for all my 2fa, and then when helping her get setup I would need to have mine handy as her backup too.
• riedel 6y ago
  A comment towards Windows10. You actually only would need HID support, but Windows takes over control over fido2 to hide it behind the Windows Hello webauthn API for non elevated users. This makes crossplatform implementations terrible. I own a solo somu and it has much less value due to this on Windows. It really discouraged me to put any more work into fido2 implementations. I started a keepassxc integration, which actually worked well based on the HMAC extension. If anyone from Microsoft reads this: please allow hackers to set a security policy to allow non elevated fido access! Otherwise the devices are great!
• meirelles 6y ago
  Trezor is great as an U2F device because it uses the same crypto seed to initialize all internal keys, including the U2F feature. So you only have to backup the seed phrase offline (paper is one of the safest medium when correctly secured, or you can buy a cryptosteel plates to really long-term storage). Crypto fan or not, those devices are amazingly secure, and certainly hold billions out there. I think it is open source too.
  • urza 6y ago
    The advantage of seed backup + hierarchical deterministic keys is greatly underapreciated.