I REALLY wish it were possible to use one of these devices without using your hands. I'm quadriplegic and would love to use one of these to unlock my computer, bank passwords etc etc. But you have to touch a finger to almost all of them to trigger the OTP, or whichever authentication and they happen to be using. I would absolutely love to be able to lock and unlock my Mac without an able-bodied person helping me, because really what is the point of me having a password if I tell it to a third party?!
Obviously the vast majority of people who use these devices are able-bodied and are able to use them as designed, but if somebody solves this problem there really is a market for it. They are great products, and if it weren't for this one stumbling block I would definitely be using them in my daily life. The inside of my laptop is the only privacy I have, and being able to have complete control over the locking and unlocking of it would be amazing.
It would be great if Apple made it possible to use the accessibility software on the login screen, that way I could tap in my own password but you can't use the accessibility software until you are inside the OS. Grrr.
Anybody got any ideas about how I could solve this, or any direction I could investigate?
(Sorry for mildly hijacking the thread, but thought it was somewhat relevant)
Since it's a capacitive touch device, you really just need something conductive to touch the pad and connect it to "ground".
Maybe someone you know could take the yubikey device, attach a wire to it, then connect up a relay or something that could be controlled (using whatever interface you already have - I'm not that familiar with such medical devices) to activate the relay. When the switch contacts close, the other side of the relay could be connected to an earth-grounded point. That should activate the yubikey (I believe).
Note that the wire and relay and such will need to be shielded as well (to prevent stray capacitance - like somebody walking by or such - activating it). Coaxial cable like that used for oscilloscope leads would be great, and put the relay inside a metal box (and connect the shielding of the cable to the box).
Hmm - this is getting more complicated than I thought - but I think the basics are there. Here are some other links that might help as well:
Thanks for the links, they look really useful and it's only just occurred to me when you pointed it out that when a person such as the key they are completing a circuit. If I could do that in someway that could be unique to me, then that might just be possible to do. I just need to find somebody to do the soldering!. :-)
It depends on the device, but if it's a regular capacitance sensor, what's really needed is just some mildly conductive object touching the sensor - something akin to a human finger. Does not have to be personalized, since this is not a fingerprint sensor.
I have an older Yubikey stashed somewhere - if I can unearth it, I'll do some tests. But I suspect it could be something as simple as a wire: on one end touching the computer's ground circuit, while at the other coiled up to make a flat spiral the size of the sensor, and having that touch the sensor. The wire could probably be isolated, because the sensor is based on capacitance, so it does not require a full circuit.
A simple way to get a ground connection to the computer is via a fake USB connector. Pin #4 is ground.
Or perhaps the outer metal jacket of the USB connector would also get a ground connection.
With a Mac laptop, maybe it's enough to just touch the metallic case to get a ground connection.
TLDR: A wire, connected to computer's ground at one end, with a little metal pad (or flat coil) at the other. Bring the pad close enough to the sensor, and it should trigger.
I had a Nano. I'm like 99% sure all the GP would have to do is tie a wire to the metal tab, and then he could bump the other end of the wire with any part of his body.
We use the nanos heavily at my workplace. I've seen people make a chain out of paperclips when their nearest USB port is too far away (and they can't be bothered to grab an extension cable).
Not sure exactly what you have in mind, but it's possible that there's a misconception here about how these devices work. They don't depend on the touch being "unique to you" -- as mentioned above, it's just looking for a capacitive connection. The extra security they give is linked to the fact that an unauthorized user would be less likely to have access to the device itself.
Also, most implementations of security with yubikey-type devices I've seen use it as a secondary authentication mechanism and still require a password, so it wouldn't actually solve your original issue of hands-free access. :( There may be ways to configure it to be the sole means of authentication though.
I haven't looked into the OTP functionality of it, since I decided to go with a YubiKey myself, but a friend loves it for hands-free automatic locking and unlocking of his computer as he comes and goes.
That looks great, thank you for the link. I would love to try one of those devices, I don't have great memories of this kind of unlocking though.
I can't remember the exact name of the product, but I installed it with good faith and it completely locked up my Mac so badly I had to reformat the computer.
So colour me a little reticent to try this, although if the gatekeeper guys are reading this I'll be happy to beta test one for you. You know, purely for accessibility reasons. :-)
I can confirm this setup works quite well. Initially it was a bit hit/miss whether it would unlock, but they clearly fixed something, it's much better now.
I had very little luck trying to set this up, and it required me to switch to a different second factor authentication that ended up complicating my life for everything else. Do Not Recommend.
There are a lot of attacks one can imagine when you have physical access to hardware inside the building. Why not just boot to a thumb drive and install malware?
There have been successful attacks on locked macs via the thunderbolt port.
I'm thinking of one in particular which I can't find at the moment, but I remember seeing a really fantastic video where one guy described in detail how he reverse engineered the mac thunderbolt interface and was able to flash malware bootcode on to it even when locked. Once that malware was installed, it could do pretty much anything, including get encryption keys to your hard drive, intercept all keystrokes, etc.
If anyone has a link to that, please post it here.
If they don't have full disk encryption, booting a mac holding command and R will get you into recovery mode where you can change the root password, or change the boot device to something that simply doesn't care about the login permisions.
Pretty much any machine without full disk encryption at rest is vulnerable when you have physical access. And if they do, you can still probably do a lot of damage, without Bumping into someone at lunch with their laptop.
Not saying it's not a real vector, but it's hardly one that would keep me up at night.
Most people will just ignore it and call a fluke. Just like everyone does when their servers signatures changes. everyone just save the new key and type their passwords away ;)
Yubico has another decive the Nano. It is designed with a switch instead of a button. I am almost sure that you could tie a string around it and then you could maybe pull that somehow, connect it to something mechanical or something.
Mmmhh, why not test this ...
... I have just tried this out. I used the wires from an old headphone and tied it to the trigger. I can Trigger the single click by pulling on the wire. I even managed to trigger the long click, but that was not very practical. I tried pulling it with my mouth, but since you don't need that much force, maybe connect to headphones or something would be enough. My laptop was constantly shifting about, but maybe if you have setup where the computer is fixed, that might be less of a problem.
You can configure the static password on Slot 1 (single click) and you can still use U2F if you like (You can even login with U2F and use Slot 1 for something else as well).
I don't know what your setup is, but that's the idea that jumped to my head. Sorry if it is stupid.
IIRC, the main reason that accessibility software doesn't have access to login screens is because malicious software has historically used accessibility APIs to steal passwords (e.g. by eavesdropping on a login screen, or by presenting a fake one and then using the accessibility APIs to pass through the password to the real one).
I think you are absolutely correct, and it's a really good reason not to switch the accessibility APIs on until the OS is fully decrypted and loaded.
Yep, right there with you and agree and everything. Still, sucks balls to be disabled in this situation and I'm also fairly sure that Apple has the engineering talent to make this possible. One would hope, anyway!
Of course Apple can do it. IIRC, Microsoft has. And Apple does with their iPhones -- the keyboard is on screen! So of course it's possible. They're just ... busy? :)
I'm reminded of the brief experiences I had w/ Greg Priest Dorman and his physical computing setup, which had him attaching keyboards to his hands, and displays to his glasses.
This is a really hacky/bespoke idea, and I apologize if I'm being naive, but I wonder if you might be able to string a Yubikey Nano (https://www.yubico.com/product/yk4nano/) via a USB extension cable to someplace accessible to you around your head? Someplace you could trigger it with head motion?
You'd still have to figure out integrating the Nano with your login screen, your password manager, etc, but this seems like it might maybe be a viable first step.
I thought of this when the Yubikey first came out, but apparently it needs to be your finger that makes the connection. I'm not sure if that's still the case, because like you I just assumed I could extend the key somewhere around my chin controller and then use the tip of my nose to activate the key. I believe the tip of your nose is actually fairly unique FYI.
But yes, that would be one solution and great minds think alike. :-)
The Nano at least is not fingerprint-based; it's simply a capacitance thing - any conductive thing touching it, connected to you, will be treated as a touch. I have at least one coworker who strung paperclips from their Nano to someplace convenient, and they just touch the paperclip.
As well, I just performed a test by rubbing my nose on my Nano, and it worked as intended :)
I'm pretty sure the nano just needs a poke and then it'll spit out whatever you've configured it to do. I got one and used it for a little while to unlock my computer, by just having it spit out a static password on touch. The issue with this of course is that your password is now visible in clear text just by placing the key in a USB port, opening up a text input, and then touching the key. It was convenient, but very insecure obviously. Maybe it would be useful to you though.
In fact how about this, you can have mine – for free. I never use it anymore, and if there's a chance it'll help you I'm happy to just send it your way. It's just collecting dust at this point anyway.
Technically, this could/should have been already solved with voice authentication. Nuance and other companies have been claiming/pushing it for a few years now: http://www.nuance.com/for-business/customer-service-solution.... I'd actually expect Apple to be the first big player to incorporate that, as they've been a leader in accessibility. Maybe somebody should sue them for discrimination to accelerate the process.
Yeah, I've been using voice dictation software since I became quadriplegic over a decade ago and they were talking about it then but it's not materialised yet. I would imagine that it's going to be Apple there's going to be first in this area, but I'm not convinced they're going to do it for accessibility reasons, I think they're going to do it for payment/password reasons. Which if I get the trickle-down benefits from then, go Apple!
I assume they dropped it because it wasn't actually secure, I remember my brother getting past mine once with only a couple of tries.
Presumably we could do better today, but as far as biometrics go, I'd put my money on Windows Hello's facial recognition over voice showing up again. Apparently they've done a better job of it than the Android handsets a couple years ago managed.
Windows hello might help you. There are laptops that use depth mapping infra red cameras with the native face recognition in windows. Probably the best hands free unlock method.
My friend, if you could find me an operating system that can do that, and then once inside the OS enable me to use every single function of the operating system like an able-bodied person in the way the Apple's does I'll give you a small prize.
I would absolutely love to use free and open source software for both my operating system and everything else, but only Apple provides an experience for people with profound disabilities that even comes close to the experience normal people have with their computers.
This reply might come across as snarky, but it isn't and I really have tried to find other operating systems that would allow me to do this. Not found any yet in a decade.
Sounds like you might have tried this already, but GNOME has had a history of working on accessibility, and I think they're quite open to bugs in case something is broken. How well it works in practice, I don't know, though:
Thanks, I tried persevering with gnome for quite a while because I wanted to use Linux day-to-day. But all of the accessibility stuff at the time was a subset of all of the things that ordinary user could do, that just wasn't enough when I started working and I needed something as full featured as Apple's offering.
I mean I'm obviously going to try and change the state of accessibility and Linux by submitting bug reports and getting involved, but it's a long slow process and in the meantime I need a computer that works.
Nope. And in my not so humble opinion and speaking from long and frustrating experience, using Windows accessibility software blows really really hard.
Until these things work well with phones, I can't buy into them. I have a U2F key that I use as a shortcut for accessing things like Google's services. But I am sticking to always using either Google Authenticator or SMS, if it's available, as a primary option. When I am looking at a website in bed on my phone, and my YubiKey is in my laptop downstairs, I can't say I am happy that I can't access my account.
I think the form factor for these things is just wrong. I don't always have my keys with me. I do have my phone much more frequently. Even more frequently I have things like my Pebble. Maybe some kind of NFC interface with a wrist watch would be a better alternative.
I use the Yubikey Neo with my phone via NFC to unlock my master password database which I use KeePass for. I wear my Yubikey on my necklace, tucked under my shirt and never remove it (it's waterproof, I shower with it.) I type my master password and just tap my phone to my chest to unlock.
Huh? All Google native apps use Android's account syncing, which definitely supports using Authenticator for U2F. I'm confident it's also possible to implement it on other apps, although it's a matter of those app developers doing so.
I use the NFC Yubikey to store a PGP key, which can then be used with pass [1] + GPG on the desktop, and Password Store + OpenKeychain on Android. Works nicely. And if you choose to also keep the PGP key on the desktop, you don't need to carry the Yubikey.
it worked for everything i was using it with. but same problem as the OP mentioned, i dont always have my keys on me so it just became annoying after a while having to the thing first
U2F and HOTP (Google Authenticator style 2FA) are not mutually exclusive.
I have both enabled on the sites that support both.
I use U2F when I have the key near me, and use HOTP on my phone otherwise (like you, my phone is typically closer to me than my U2F key).
A common response at this point goes "But then doesn't introducing HOTP remove the security benefits of U2F?" No. One of the main benefits of U2F is that it is phish-proof: the U2F key cryptographically authenticates the server, rather than the user eyeballing the address bar, which is how server "authentication" works with HOTP.
I think I'm not understanding the problem. I have cloned keys (for backup + two locations), with Yubico Authenticator. Is the problem NFC on iOS or that you don't want to clone your keys?
My problem is that while I can reasonably guarantee that my YubiKey will be near my laptop when I use it, I generally can't guarantee that my YubiKey will be near my phone or tablets when I use them. I also don't really want to keep plugging in a physical key into my phone every time I want to log into, say, American Airlines to check the status of my flight, or into PapaJohns.com every time I want to order a pizza.
NFC makes this a little easier, but I still usually don't keep my keychain (that is my physical keychain with my house and car key) on my nightstand, while I do keep my phone there.
tl;dr: Laptop + 2nd Factor = YubiKey. That's OK and it works.
Makes sense. Thanks. It seems as if what I would consider "natural usage" is a bit different than yours. I don't use my phone to access anything critical -- the attack surface is too big and changes too rapidly (sometimes outside of my control) for me to keep track of -- and I wouldn't worry about safety when checking a flight.
Why would you need two factor auth on a phone? Most phones have fingerprint sensor built in. And you can set up a super secure password that needs to be entered on boot.
Now that I think of it, why is 2fa needed in a laptop with a fingerprint sensor?
> I thought the whole point of having a hardware token in the first place was that it's _not_ easily copied?
The process generally requires the person personalizing the key to intend to make two (or more) from the beginning of the process. Otherwise, the secret bits that must be entered into the other device to allow one's 2nd Yubikey to generate the same responses to the same challenges will be lost...
I decided couple of months ago to secure entire family. Bought half dozen Neos, worked out all the kinks on my computer + Android phone first, put everything in LastPass (I know, I know, I know... but you have to consider the target audience ;).... only to discover on "go-live" that my wife's iPhone 6s is bloody useless with the thing. Apparently iPhone doesn't fully grok NFC or something? Not sure... :-/
Apple decided that users cannot use the NFC chip in it except for Apple Pay (for the foreseeable future). You don't really 'own' an Iphone in that sense.
For U2F at least, Bluetooth solutions should be arriving. If Yubico does its on (they have said that they are working on it) they might additionally let you use the OTP stuff.
That said, LassPass says that when Firefox supports U2F, they will also try to support it. So maybe the OTP stuff is not that important.
Note that this isn't just a U2F key; if you're looking for a token principally to log into web services with, this isn't what you want, and the token that does that costs less than half as much (it's the U2F-only token).
You want a Y4 if:
* You SSH into sensitive machines.
* You log into a VPN that you control and can configure to use the Y4.
But it's identical functionality to a Yubikey 4, just with type-C connector, and the product page as well as myself personally can verify that Yubikey 4 supports U2F
I'm not saying the 4C doesn't do U2F. It's the same as the 4. I'm saying that if all you want to do is log into web services, you probably don't want the Y4.
Its a good thing to think about, but I don't see it as a huge problem. I had a Yubikey Nano plugged into my laptop almost constantly and I do trigger the OTP sometimes, but using that as an attack vector is pretty hard, specially for all the sticks that are not always plugged in.
Does anyone have a guide on how to store an SSH key on it? I only found PGP key guides (and I have my key on it), but not much for SSH. I also think it doesn't do ECC...
There are a number of tools you can install yubico-piv-manager/yubico-piv-tool but check the guides.
I had some problems with this, somehow I could not add the key to ssh-agent, but that was related to the ssh-agent, not sure its a general problem.
Note, this does only support 2k keys. If you use the GPG Smartcard and a Authentication Subkey you can get 4k keys. The advantage of PIV is that you can actually use ssh-agent and you don't have to use gpg-agent. Gpg-agent does not have all the features that ssh-agent does, and for me that was relevant.
Thank you, this is the best guide I've seen so far. It's much simpler to install and use. However, like you, I'm having some problems. Adding the key to the ssh-agent asks for a PKCS password and always comes back with "agent refused cooperation". I also can't log in to a host that has that SSH key, but maybe that's because I have too many keys loaded...
This is a whole post, but basically, there are multiple SSH agents. ssh-agent supports the card and ed25519 keys, but doesn't support persisting keys across reboots. Gnome keyring supports persisting keys, but no card or ed25519 (AFAIK). gpg-agent supports persisting keys and ed25519, but no card.
Unfortunately, there's no perfect solution, so I just added an alias "yubissh" to include the library in the command line :(
So I got one 4 months ago and quickly found out that I understand next to nothing about it. I really thought it was going to be a plug-n-play solution but it was far from it. It took me nearly an hour to get my google account setup to use it. For some reason the little wizard thing on Google that "syncs" your yubikey was giving me trouble. After I finally got that part working i pretty much forgot about the whole thing. I had plans to also use it with KeePass in addition to Google but after reading that you basically have to hack this thing to work with both I pretty much decided it wasn't worth the effort. It's really sad how great this little thing is and how much of a pain it is to actually get any use out of it.
I don't think that the people complaining about the price of this key appreciate all that it can do. Most of those people would probably be better off with the cheaper FIDO U2F Security Key.
I haven't found anything else that manages RSA Keys, TOTP auth and U2F in a single package. I'm going to buy this because it plugs into my pixel phone and it seems like it'd be more secure and convenient than my current Neo with NFC.
Annoying nerd pedantry: It's only sort of doing TOTP (Yubikeys don't have batteries, so need a software client to provide the clock), and on a slack with almost 300 crypto nerds in it, I don't know any of them that use the Y4 for TOTP (I'm preparing myself to be surprised in a minute when someone there reads this). TOTP is something you do on your phone.
I only do TOTP on my phone. The Yubi Authenticator app is a drop-in replacement for Google Authenticator, but it adds significant security because the keys are stored offline in the yubikey and the crypto is done in the fob. Your phone is relegated to sending the time and displaying the OTP, which greatly reduces the attack surface of a standard OTP app.
The actual usage is exactly the same as Google Authenticator with 1 more step (NFC with NEO or plugging in the yubikey 4) to get the OTP.
In addition to what the others have said, I would point out that TOTP with the Yubikey/Yubico Authenticator has one other advantage. You can move between different android devices without problem. Its even nicer then Cloud-based Authy.
I was in a pinch once and had to do TOTP, so I grabbed the phone of my friend, downloaded the app and used it to log in.
TOTP with Yubikeys is great. You just need the Yubico Authenticator app to access the TOTPs. Works fine on phone using NFC as well as on my (Linux) desktop using USB. New phone? Install YK Authenticator, tap the YK and use your TOTPs.
Until there's a YubiKey 4C nano, I'll wait. Having something of that size sticking out of my computer is not really practical. Not having it inserted defeats the whole point.
How so? I would keep this on a keychain or lanyard (it looks rugged enough to handle that sort of environment). When I need to authenticate, I plug it in, when I'm done, I unplug it. That seems a lot more secure than leaving it in the computer all the time. If someone gets my computer and the YubiKey is always installed, that sort of defeats the purpose of having a separate hardware security device. In that case, why not just use Keypass?
I've had the standard USB version on my keys for about a year at this point. They're in my back pocket and take a bunch of abuse. Still works just fine.
Direct physical access to your computer is not the only thread. Even if you have in your computer all the time it gives you better logins, easier and safer. Specially protection from phishing.
When I leave my computer out of my eyes it usually locked (unlock with password), so I don't expect somebody to quickly go in and do something. If I leave for longer, I sometimes pull the Nano out and put it somewhere I don't lose it for a while.
The advantage of your system is that you can use the U2F screen unlock instead of the password.
Why do you need to keep it in? I have the blue U2f key and it's much larger. I just keep it on my keychain and only insert it while signing into something that requires it.
This isn't something you should leave plugged in. It's a key after all used for authentication. Keep it on your keychain or in your wallet and plug in as needed.
The security is that it requires physical presence (your finger completing a circuit) to perform authentication. Leaving it plugged in doesn't detract from that.
I'm kind of wondering what the benefit is over having something like Yubikey at all instead of something that's just software when you just leave it in all the time.
Trust: a hardware token has a very limited interface where it can be attacked compared with a general purpose computer or phone.
Take the devices you use: how many exploits have there been in the last year where an attacker who could get you to click on a link, view an image, etc. could run code on the device? Maybe you have something like the iOS sandboxing between application which would stop a compromised browser from compromising your authenticator app but there are many cases where attackers have been able to bypass that.
Using a hardware token prevents almost all of those attacks and means that if you are compromised you'll have an easier time regaining control. They also have some nice benefits such as not running out of battery when you need them in an emergency.
I specifically use it to store my gpg/ssh keys on it. The keys are generated on the device and have never been in any computer's memory. The key answers challenges from an SSH server with the appropriate response. I do not want to insert something dangling off my key every time I do git push.
If your SSH private key is on the Yubikey then you will not lose your private keys. Even in the case of U2F, the attacker will not figure out your U2F private keys or even all the places you are registered.
His point, which is correct, is that you'll persistently lose access to your server anyways, because a backdoored SSH client is almost as bad as a compromised key. I use a Y4 for SSH, but it's good to be clear-eyed about the limitations.
In my opinion it's not worth the effort (and certainly not $50). It makes marginally +X harder to exploit yet marginally +X inconvenient to use = typical security through obscurity.
My bad, it's not what classic "through obscurity" means. Instead I meant something that makes exploitation more "obscure" (you need to be prepared to hijack a server vs simply leak the key).
In a lot of cases their clients are businesses who bulk buy the keys, brand them and provide them to their customers either for free or at a discounted price.
Those companies are usually financial services, online games with monthly subscriptions, and corporate IT/Security services. So they have a high customer LTV and the investment is worth it for them.
Yubico was smart to go after that market. It is costly to design, mould, manufacture, sell and support a hardware product, even something as small as this. Since you don't want your 2FA company to go out of business there is good value in knowing they have a stable business model that can actually support a company rather than just burning capital.
They do lots of stuff. A YubiKey 4 has GPG Smartcard, U2F, PIV (SSH,CA, Windows Remote Login), Static Password, Yubikey OTP, Challenge Response Mode (HMAC) and HOTP. It does a lot of stuff, I am amazed how cheap they are.
Pure U2F sticks can be done much cheaper. The Yubikey one only costs 18$, but the U2F standards was designed for cheap devices. You can get U2F sticks for less then 10$ on amazon.
For something that authenticates you for 2 factor, I'd pay a lot more. After all, this is your key you use daily for the services you live off of. The value is a no brainer.
alternative is u2fzero, available on amazon for 8$, and totally open source. the difference is that yubi uses an nxp secure coprocessor, whereas the u2fzero uses atmel. there is the possibility of side-channel attacks on the u2fzero.
but for your family, it is better than nothing and much more cost effective.
u2fzero is "Currently unavailable" on amazon. And the lack of housing makes me question how durable the device would be. The last thing I want is my u2f dying and locking me out of a ton of accounts.
The Atmel chips do not claim that they have implemented counter-measures for power analysis, etc. Power analysis on a key operation is a dangerous attack if proper counter-measures are not taken. You can literally read off the 0/1 of each bit of the key as the key operation is underway if you monitor the power/timing.
The NXP chips inside the yubikey claim to be hardened against several such attacks (although I have not confirmed).
NXP is a cagey company. For example, I am a researcher, and I wanted to get the yubi-key's unlocked to write and test new u2f protocols on their hardware. They wouldnt sell me development keys, and claimed that the restriction was placed on them by NXP. I wrote half-a-dozen requests to the NXP people, and they never replied.
I have a Yubikey, but almost never use it. I still don't get it fully, don't have a use-case where it totally works for me. Having one key is maybe part of the problem. If I lose it, what then?
Some people will tell you to buy two Yubikeys and leave one as a backup. I don't think that's necessary. No matter what, you should generate a backup software key and keep it on offline encrypted storage; if you lose the token, just use the backup key until your replacement arrives.
It's even easier for Github and Google Mail. For web services, the right stack is:
* Hardware U2F token
* Backup software TOTP (Duo or Google Authenticator or whatever)
* Backup printed (or saved on offline USB key) passcodes
* Disabled SMS.
Unlike SMS, which is devastating to security even as a fallback, having a software TOTP option is basically fine; most of what U2F buys you is unphishability. This leaves you with two levels of backup, one of which is reasonably secure indefinitely.
Isn't disabled SMS overkill for most casual thread models? As I understand it SMS would require someone to MITM the telecom network OR snoop the local antenna when you receive it on your phone. Which is a danger if you expect, like, nation-state adversaries.
But if I'm, say, protecting my GitHub account against Russian mafia hackers, that still seems perfectly fine?
The bigger problem for SMS-based 2FA are social engineering attacks on the support personnel of mobile network operators. They typically don't have fancy authentication schemes - it's fairly easy to get them to redirect messages to a different SIM or something like that.
I can't speak to current day, but in the past it's been very easy to social engineer telecoms. So especially for high value accounts this shouldn't be used.
Can you disable SMS on google? I've tried and have been unsuccessful. Phone is required to enable 2FA. Once that is enabled, I can add yubikeys. After adding yubikeys, I am unable to remove phone as a 2FA alternative.
It's possible to disable SMS-based 2FA. Perhaps you need another backup option before you're allowed to remove the SMS option. In my case, I was able to do it with two U2F keys, TOTP and backup codes enabled.
You might need to remove it as an account recovery number as well. Those can effectively downgrade your login to one factor.
>you need another backup option before you're allowed to remove the SMS option.
This was the answer. Google prompt isn't allowed with hardware tokens. Backup codes evidently don't count. So the only way is to set up Google Authenticator on a phone. Authenticator from f-droid works. After I set up Authenticator, I no longer got the "Something went wrong. Try again" toast when trying to delete the sms number.
Edit: Just realized what Yubico Authenticator is for :)
When I first got mine, I was the same way. I learned different bits in steps. First was yubikey-luks for full disk encryption. Then using my ssh key on it. Then GPG key on it. Then using GPG key for password storage with QTPass, OpenKeychain/Android Password Store. Then 2FA with gmail. I'm getting a lot more use out of mine more than a year after originally getting it.
For the ssh key, are you using your yubikey on multiple computers or just one? I just started looking at this but it seems like there is a bit of setup needed for each computer. I guess it might be worth it but would be interested to hear about others experiences.
It's very easy to setup on linux, but does require a fair bit of setup to get it to work with windows. I haven't set it up on OS X but I expect it to be about as easy as linux.
I've been SSH w/ yubikey key only for about 6 months now and haven't had any issues with it. I regularly move between multiple computers. Once I set it up on one computer I've never had it take more than 15 minutes to get up and running on any computer I've need it on (window or linux).
The only thing I'm really missing is the ability to log into my server from my phone. There was some talk of getting ConnectBot and Open-Keychain talking to each other to get this working but it appears to be stalled.
Yeah, it does require some setup on the ssh client machine. So far, I only set up my home laptop with it. It's probably not hard on the work machine, but different OS so I haven't tried.
I'm in the same boat and actually submitted an "Ask HN" awhile back to see what others were doing (https://news.ycombinator.com/item?id=13567209). I have the plain ol' yubikey and also the NFC yubikey but I haven't found a good, real world use case for them. It might be that I'm just not the target market or that I haven't put enough time/effort into it. For me the big selling point was the FIDO stuff but so few providers seem to use that...
Check out some of my last answers in this thread. I use it for:
U2F (Google, Dropbox, Facebook, Github, Bitbucket), TOTP (Slack and everybody else that does not support U2F), Yubikey OTP (LastPass), static password for luks decryption (additionally to normal password), GPG Smartcard
The only feature Im not yet using is the PIV SSH stuff.
I also just like hitting the button and printing out OTPs when Im boarded.
I was pretty paranoid about moving to 2FA for my personal account due to fears about getting locked out, but finally decided to take the plunge when I got a yubi for my work & realized I could also add my personal account to it. The nice thing about the Yubi is that decreases the chances you'll be locked out, because (if you're using it for a Google account, then) you still have a phone app, like Google Authenticator, that you can use to authenticate. And you've still got backup codes. And I also have two keys.
I've a yubikey4 but i'm not sure how/why i should use it. I get the 2FA case, where it provides the One Time Password to login in some services, sort of what the phone does with the authy app (or am I wrong?). But, what about the ssh access? Should the key be used to decrypt the ssh key when accessing a server? so that, if i grab anycomputer i can login on my server if I've the yubikey with me? if so, how should this work and how can I set it up?
You can actually store the key you use for SSH authentication on the Yubikey [1]. The main advantage is that the key never leaves the device, so even if your computer is compromised, your key is still safe.
Same thing goes for anything else involving GPG keys - email, signing git commits or tags, software releases, etc.
I don't personally use it for OTP. I do use it for services that support U2F (which is different from OTP, and has the main advantage of being immune to phishing).
Lets go threw it. Yubikey supports a number of different 2FA workflows. It supports TOTP (together with a phone), HOTP, Yubico OTP (that is there own standard based on HOTP) and of course most importantly U2F. U2F the new and improved 2FA standard that gives you interesting things like phishing protection.
It can also be used to issue a static password, and it can also be used in a ChallangeResponse mode (you send something it and it will get hashed). Both of these can be used to do decryption while booting for example.
Now lets get to the more advanced stuff. Yubikey is both a GPG Smartcard and a PIV Smartcard. Essentially this allows you plug in your Yubikey and then automatically your GPG and SSH keys will appear as if they are on the system. If your program, for example Thunderbird or SSH, tries to use the private key, it will require a PIN.
This allows you to have no key material on your computer. If you are hacked the attacker has no access to your private keys (and hopefully thanks to 2Fa not to many of your accounts). Even if you lose the keys themselfs your keys will probably not leak.
Depending on your situation and security needs you will want this stick either always plugged in your machine, or you want to carry a stick around on your keychain.
As for how to set it up, Yubico has lots of documentation.
I wrote to you via the keybase tool. I've setted up the yubikey, copy the Access Key to the yubikey but the ssh-add -L does not list the key from the yubikey
The OTP functions basically as a USB HID keyboard. So you can plug it into something that is not locked down (like a phone or tablet), and then just copy the code.
The drawback is that the code could be long. A few years ago, the codes were just 6 digits. My latest nano spits out a very long (20 char?) alpha-numeric string.
You can have it behave like a keyboard and simply 'type' the characters of the one time password in. I don't know how locked down your systems but usually keyboards are allowed.
I use a Yubikey 4 with the GnuPG smartcard applet to secure all my password, sign my emails and connect to remote computers with SSH. It's super convenient and I'd never go back.
That being said I got a bit concerned about the use of closed source components in newer yubikeys (I believe that the yubikey 4 is open source and the later ones aren't, but don't trust me on that).
For this reason I also bought a nitrokey as a backup. It's a bit slower than the yubikey (I use 4096bit keys) but it works well. I really don't like the plastic cap on the nitrokey though, I feel like I'd lose it within a week if I started using it as my main key. The Yubikey doesn't have any protection at all but it looks sturdy enough that it doesn't really matter. It's been on my keyring for months and it seems to handle the abuse just fine.
I was just looking around yesterday for a programmatic way to encrypt/decrypt a file with a USB fob. I used an Aladdin fob a while back for a similar project. The encryption was symmetric but the fob kept the key and it couldn't be exported - so it was safe enough for my application.
You could do OpenPGP encryption. It will generate a symmetric key, encrypt the data with it, and then encrypt the symmetric key for the yubikey's pubkey.
I wish you could use these with macOS's CoreStorage to unlock FileVault 2's full disk encryption in combination with a password. I wonder if it'll be possible at any point...
I've done OSX authentication (mainly adding 2FA to the login screen), and Apple doesn't provide any mechanism to interact with unlocking FileVault.
However, with the Yubikey you can type in your password, then have the Yubikey enter your static password. That way you sort of get 2FA for the unlock screen.
On the Yubikey its also possible to deactivate individual modes. If somehow U2F mode was disabled, it should not work anywhere, but if you don't use the other modes, maybe deactivate them. In earlier version there were some problems.
You're probably missing some library or other. I know I had to install something in debian unstable, but I don't remember what it was. U2F definitely works on Linux, though.
Google supports the U2F standard for logins through Chrome. It's a theoretically standardized browser API, but it's only been implemented in Chrome so far.
Sometimes they do. They did when they launched yubikeys on github. You could get a yubikey with github logo on it for $5, limit 2. They were U2F only, but I still purchased two for the novelty.
I haven't used it, but Trezor looks interesting, and there is a Trezor 2 coming soon. https://trezor.io/
The sweet spot is for Bitcoin wallets, but it does the other stuff (U2F, ssh, gpg, passwords). Hardware is interesting. Everything open source. You can add your own "apps".
The external screen add even more security and that is very cool. UAF/U2F both have support for external monitors in the protocol, so its really good security.
The ssh/gpg stuff is less advanced then that of the Yubikey, all guides suggest running some special scripts. With the Yubikey you can set it all up so this is not needed. Maybe this works with the Trezor, but I didn't find any guides for this.
I really want Trezor to support UAF as well, given that it has a PIN entry system, this should work.
If you need a Bitcoin Wallet, Trezor is cool, if you want a tool primary for login (U2F/OTP/TOTP), a Yubikey is preferable.
That reminds me of how for a long time people were saying that encryption influenced and blessed by the NSA must be secure because government agencies were using it and the NSA wouldn't weaken their encryption.
Because biometric authentication is a joke in the security industry?
Biometrics are fine to identify someone. Biometrics, being public data, is not acceptable for authentication nor authorisation.
To use another example:
You get to border control, and present your passport. The agent ensuring that the description in the passport matches the person standing in front of him/her, that is identification. The agent verifying that your passport is genuine and valid, that is authentication. The agent giving you access to a country based on the laws and arrangements between those two countries, that is authorisation.
Anything that can be copied/stolen with a good enough picture or forgotten glass/mug is not good enough for authentication/authorisation.
Why? This is the hardware factor in a two-factor authentication scheme. Someone purloining your YubiKey would still need a PIN or password to proceed in most 2FA schemes. The only thing biometrics would add is preventing someone from physically taking your YubiKey and abusing it along with the knowledge factor gleaned from you. That is a valid concern in some specialized cases, but certainly not the common use case 2FA aims to address.
And even if it was; if someone is willing to physically intervene in your security by stealing your YubiKey, chances are they are willing to 'coerce' you to cooperate with unlocking a biometric lock as well…
You should turn off your fingerprint readers. Courts the world over are starting to agree with law enforcement that they have the right to take your fingerprints, and they have the right to do whatever they want with those fingerprints short of disclosing them to the public.
Sooooo... fingerprint auth is a useless security measure even for normal citizens.
I've probably posted this a dozen times, but Dustin Kirkland (the Linux encryptfs maintainer) so eloquently put it that fingerprints (and all biometrics) make wonderful usernames, and horrible passwords:
They're used as second factor authentication, not on their own and are generally linked to a TOTP/HOTP mechanism. They (depending on which technology you use) create unique, pseudo-random codes to enter (linked to some salt+time value) along with a passphrase or another auth factor (could be a smartcard of course)
Reminder that open source projects are not provably more secure, nor is it easy (or even possible in many cases) to assert the source you see made the binary in question.
Yubikey has been around a long time and has made every effort to be a transparent company with a support for open source. Truth is, that is sometimes hard to do.
I've seen that article and it's a heap of crap. There's no reason they couldn't make the firmware read-only so you could verify it, then publish the source to audit and verify against.
>Reminder that open source projects are not provably more secure, nor is it easy (or even possible in many cases) to assert the source you see made the binary in question.
I can (and do) read the code for security-related software, and I can at least check for obvious backdoors and flaws myself. With reproducable builds it is possible to assert the source you see made the binary in question (and security related software must support reproducable builds for this reason).
If you want to convince yourself the product is secure, that's up to you, but it's not.
You obviously didn't read the article. There is no way for you to actually do that. And the secure platforms themselves have NDAs around their specs and software tooling.
So yeah, there is a reason they didn't do that. The hardware they're using specifically makes it difficult to do the verification you want to do. Which is directly related to foiling the kind of attacks they want to foil.
> If you want to convince yourself the product is secure, that's up to you, but it's not
I think we have the same goal, but you have a conviction that open source stops "obvious back doors." It in no way would help that at all in this case. The hardware is configured before it is shipped, then locked in a way designed to prevent rewriting or inspection. You have no rational basis for the belief that the source code on a website and the binary a malicious and deceptive actor would deploy to the hardware are the same thing.
Being open source only affects the way security auditing can be done. It doesn't guarantee better quality.
I have read the article, several times, thank you very much. Don't take the easy way out by dismissing the opposition as ignorant.
>So yeah, there is a reason they didn't do that. The hardware they're using specifically makes it difficult to do the verification you want to do. Which is directly related to foiling the kind of attacks they want to foil.
Then they've chosen the wrong hardware. This doesn't make it more secure, it just explains why their product is insecure.
>I think we have the same goal, but you have a conviction that open source stops "obvious back doors." It in no way would help that at all in this case. The hardware is configured before it is shipped, then locked in a way designed to prevent rewriting or inspection. You have no rational basis for the belief that the source code on a website and the binary a malicious and deceptive actor would deploy to the hardware are the same thing.
I already addressed this - reproducable builds. I don't have to take anyone's word for it.
> Then they've chosen the wrong hardware. This doesn't make it more secure, it just explains why their product is insecure.
If the hardware is more resistant to hardware and software attacks, it seems odd to then deem it less secure just because you don't get source code that isn't guaranteed to correspond to a given binary.
> reproducable builds
There's so much literature on how this methodology fails, some of it quite famous. There is no assurance that your device conforms to the build you can reproduce, unless you can arbitrarily inspect the state of the entire device at each step. Being able to do that would defeat the purpose of these devices.
>If the hardware is more resistant to hardware and software attacks, it seems odd to then deem it less secure just because you don't get source code that isn't guaranteed to correspond to a given binary.
It may be, but there's no guarantee it behaves the way it claims to. There's no guarantee it's not backdoored. There are powerful actors involved in these areas.
>There's so much literature on how this methodology fails, some of it quite famous. There is no assurance that your device conforms to the build you can reproduce, unless you can arbitrarily inspect the state of the entire device at each step. Being able to do that would defeat the purpose of these devices.
> It may be, but there's no guarantee it behaves the way it claims to. There's no guarantee it's not backdoored. There are powerful actors involved in these areas.
It renders your point about source code moot though, doesn't it. Security is ultimately the art of trust propagation.
Trust chains are their weakest link, and people often put a lot of trust in compilers without really asking what it is doing. Not unlike crypto, we're told not to roll our own.
People have proposed ways around this, but they're not very good (http://imgur.com/a/BWbnU#0). The moral of the story is that at some point, you extend trust to someone. Security is never absolute.
>It renders your point about source code moot though, doesn't it. Security is ultimately the art of trust propagation.
I don't see how that follows. If I can audit the source code and confirm that the same code is running on the device, the weak link is reduced to my ability to aduit it (combined with everyone else who's auditing it as well and might publish their findings).
>The most famous discourse here is the "untrustworthy compiler problem."
I thought this might be what you're talking about, but this is ridiculous. Do you really think that the Yubikey folks have backdoored my copy of gcc? Dude.
> the weak link is reduced to my ability to aduit it (combined with everyone else who's auditing it as well and might publish their findings).
And if the hardware itself has microcode that overrides your code?
> but this is ridiculous. Do you really think that the Yubikey folks have backdoored my copy of gcc?
Actually, I think the first and foremest threat would be, "Could someone insert a yubikey into a malicious device that changed its behavior such that it now leaks information and does not provide actual security."
Because those kinds of attacks actually exist. Ultimately, what you're arguing for is the pleasure and moral superiority of being able to do that audit. Not only does that audit not give you many guarantees, but giving you the ability to do that audit opens you up to much more sinister attacks.
>And if the hardware itself has microcode that overrides your code?
Hard to defend against this, but it can be helped by using well understood architectures and letting us confirm that the microcode being run is the same microcode that the upstream CPU vendors are publishing.
>Actually, I think the first and foremest threat would be, "Could someone insert a yubikey into a malicious device that changed its behavior such that it now leaks information and does not provide actual security."
I'm not going to keep entertaining this discussion if you keep disregarding everything I've already said. I've already said I'm only asking for read-only access. In any case, defending against physical compromise is close to impossible anyway.
You are taking what you personally consider to be a guarantee and applying it to mean what everyone else considers to be a guarantee.
Unless you physically inspect each and every device (since they could easily run multiple lots) your faith is in the fabrication of all of the ICs used in the design. Not to mention that the computer you stick these into suffers from the same problem. On the theoretical side, all of the math which this is based upon is probably taken by most people on a faith basis. There is a lot of faith to go around. It just depends where you draw the line.
Well, with that logic, open-source security-related products are a complete joke, too.
- Microprocessor can look at the binary, recognize the patterns ("oh, this is OpenSSH trying to generate a key... lets give them an easily breakable one") and do whatever it wants with it.
Remediation: build your own compilers, build you own processors, from your own schematics, in your own foundry (cost: $billions), built by yourself.
Just use a TOTP app, at the moment. Note that because there are no U2F alternatives means that you shouldn't use U2F - not that you should settle for an insecure device.
There are U2F alternatives, several of which are mentioned in this thread. Also, U2F is immune to phishing while TOTP isn't. Your advice is actively harmful.
The available data suggests there are no groups of people who are good at not being phished.
The audience here is unlikely to send a check to the Nigerian prince looking to smuggle his money to America, but if you're arguing that we shouldn't trust yubikeys against APT backdoors, we're talking about a much higher quality of phishing.
I'll take my odds with yubikeys firmware rather than try to vet every site I enter a TOTP code into
You should be vetting those sites anyway, especially since you probably were also asked for a password. And it's not exactly hard - just glance up at the address bar.
A good phish relies on triggering instinctive behaviour, e.g. scaring the crap out of you and not following best practices because you're having an adrenaline rush. That's how careful people get hit. SwiftOnSecurity sometimes posts really well done phishing attempts: https://twitter.com/search/live?q=phish+from%3Aswiftonsecuri...
Obviously the vast majority of people who use these devices are able-bodied and are able to use them as designed, but if somebody solves this problem there really is a market for it. They are great products, and if it weren't for this one stumbling block I would definitely be using them in my daily life. The inside of my laptop is the only privacy I have, and being able to have complete control over the locking and unlocking of it would be amazing.
It would be great if Apple made it possible to use the accessibility software on the login screen, that way I could tap in my own password but you can't use the accessibility software until you are inside the OS. Grrr.
Anybody got any ideas about how I could solve this, or any direction I could investigate?
(Sorry for mildly hijacking the thread, but thought it was somewhat relevant)