To a robot, the act of moving meat into physical proximity with a switch might be considered to be an equally obscure action. As a component of a 2-factor system to prove token possession, either seems quite adequate.
The use of U2F tokens as single factor auth seems to have promulgated thanks to this implicit 3rd factor keeping the situation moderately at bay. I posit that this is largely the same reason that keys and locks remain relatively secure despite that almost all of them are trivial to bypass or duplicate. The physical access bit is just so damn inconvenient for the typical modern white-collar criminal.
I used it for testing smart meters in Norway, so we did not need to run to the lab to trigger events. The best part is that the whole menu is interactive by just one physical button, a great job for a Bluetooth button pusher + Python.
It is also capacitive so it work on the phone screen, and YubiKeys (?)
I mean, for a power supply, bluetooth receiver/chipset, actuator... I don't think I cobble together something half as good for twice as much, and that's not factoring in labor.
I like the concept but the price is steep IMO. $90 for two actuators in the starter kit then $40 for each additional module.
I wonder if one could design a similar solution without requiring a bridge. Although of course given the power consumption adding WiFi on the actuators might not be a great idea.
That may be the case but it doesn't change the fact that I can't think of a use for these that is worth $40. I think the value these would add to my life would be worth closer to $5/each.
Now, if they existed for $5 each, I would be all over it and buy 10
Exactly. At one of my work places, we needed 2FA to log into a vendor portal. So we stuck the username, password, and TOPT in Vault which is protected by corporate AD password only.
I'd hazard saying that the purpose of a YubiKey is to provide two factor authentication. A YubiKey acts as an item, posession of which implies identity. When you allow for the YubiKey to be activated without human interaction, it's moved from domain of posession into the domain of knowledge - identifying party needs to know where to knock, not to possess they key. It's no better than appending the URL at the end of your password.
If you allow for a YubiKey, or any other physical artifact in that matter, to be remotely invoked it negates its utility as an authentication factor in the physical domain.
It depends on what protects the key. If the problem is being unable to duplicate it, you could protect remote access with a different YubiKey or some other second factor.
And the setup in the article isn't even remote access. If the only way it can be triggered is a local button press, you're golden.
Yeah... isn't one benefit of a yubikey that a secret must be acquired by some very physical and intentional means? If my laptop/password is compromised, then they still can't log in because they need my secret token from the yubikey. Well, if having that secret token is just one curl call away if they're on the same network then its no longer a very physical and intentional safeguard.
I know... layers of unlikelihood.. but I'd probably opt for a physical "good button" gapped from my computer as sort of a closed electrical extension of my finger.
> Congratulations, you've defeated the purpose of having a YubiKey.
Even a virtual 2fa button is useful. It prevents people using your stolen credentials to login to websites unless you click the button, even if it's just a virtual button.
Sure your computer can be compromised, but it's probably still more secure than sms 2fa.
I got into robotics and have been able to do it professionally for several years precisely because it's a useful way to automate real world end-to-end testing.
This is some cowboy engineering and i love it. totally shooting from the hip, but still finishing up with a nice long-form post.
like other comments mentioned this is super impractical but that's not the point. building a robot finger to push a button at the push of a button is a hilarious saturday afternoon project
It's one of those projects that lets you flex your problem solving muscles in a low stakes environment. Taking "I wonder if i could..." and running with it
The obvious next step is to plug this into a server and control it through USB over IP. Call it "remote, centrally controlled 2FA" and your manager will love it!
Considering many services only allow one YubiKey or only one TOTP authenticator ... I might actually need a short term solution like this to beat the 2FA on those services. Otherwise what happens if I lose my key on the road?
The 2FA services that allow >1 YubiKey are good, I can have a backup key locked up some place and use them as intended.
It would be better to use a software TOTP authenticator with backups. You could also store multiple encrypted copies of the TOTP secret encrypted with different Yubikeys. I don't know if there's any software that does this automatically and momentarily decrypts the TOTP secret into a secure memory location when you need it. That preserves... most of the benefit of 2fa.
Storing copies of a TOTP secret is as good as just having 2 high-entropy passwords and saving multiple copies of one of them in clear text, which is not more secure than having 2 high-entropy passwords and not storing them anywhere, and which is equivalent to just 1 doubly-high-entropy password not stored anywhere.
The fact that you can store copies effectively defeats the purpose of 2FA.
One of the reasons to have multiple YubiKeys is that if I lose one on the street I can just login to all my services with my backup key, disable the lost/stolen key, and buy and register a new key.
Whereas if someone got a hold of your TOTP secret, ehhh ... you might not necessarily know for a while.
One reason to have multiple copies of the TOTP secret is to not be locked out of accounts should one lose their 2FA token. For example, if one has two copies of the TOTP secret, one of which is in a secure location, and one of which is used for daily purposes, as long as the secure location is reasonably secure, it's not much different than storing backup codes in that secure location.
I do agree with you that having multiple copies of the TOTP secret that can be lost and not noticed isn't a good idea though.
"better" is a strange word to use when discussing security, everyone's situation is different™. You're making a set of trade-offs between availability (backups) and confidentiality (only using hardware tokens which are tamper evident) which absolutely do not generalize to every case.
I'm saying if your hardware token is plugged into a machine that you connect to with USB-over-IP your hardware token is basically security theater and your actual security is whatever secret you use to protect the machine the token is plugged into. So if you're worried about availability but want something like 2fa software TOTP secrets make a better tradeoff.
I’m pretty sure every site I’ve setup to do TOTP only allowed one authenticator. I got burned using Google Authenticator when I had to replace my phone, because there was no way to transfer the auth data to a new phone.
Maybe The Google app has changed now, I have no idea. I’ve had much better luck storing TOTP in 1Password and Bitwarden - which allow you to sync across multiple platforms. So now device upgrades are a non-issue.
Most sites give you some static backup codes for TOTP - definitely store those somewhere safe, they can be a lifesaver.
Holy crap. I've avoided buying a U2F/FIDO2 device (eg. YubiKey) for a few years thus far, as I'm "happy enough" with TOTP. I know the differences in terms of implementation/security, but not enough services even offer TOTP, let alone the U2F/FIDO2 protocols. It's not worth the investment right now for how generally unsupported it is.
Do most services that support such devices really only support a single key/device? Do they offer the same one-time recovery codes that are generally offered with TOTP (though the storage/security of such codes server-side is dubious), for the eventual failure of the Yubikey (not if, but when)? Surely a tiny hardware device reaching the end of its lifespan doesn't mean you lose access to your account.
I have a pair of hardware FIDO authenticators, and my phone and laptop are both platform authenticators.
I have personal accounts with Google, GitHub, GitLab, Facebook, and DropBox that use at least two of those four authenticators. I also have Login.gov (US government) and Gov.uk Verify (one of two UK government authentication systems, hooray for needless duplication)
Most of them offered one-time recovery codes which I hand wrote in a book of one-time recovery codes, but without fetching that book I can't tell you it was all of them.
At my previous job I used a physical authenticator with AWS and that was indeed restricted to just one authenticator, on the other hand there's an account "administrator" for that AWS account so if you lost your authenticator the admin can get you back in and I assume larger companies have multiple people in the administrator role.
The WebAuthn specification explicitly says that Relying Parties (ie web sites) should support multiple keys.
And yes, if you lose access to all methods of authentication in some cases you lose the account. I believe GitLab explicitly flagged their intent to act this way for accounts that don't pay them money, and I would prefer this. As I wrote back then, if it's not worth an hour of my time to somehow try to prove my identity to you after locking myself out of your service (which if I'm not paying you, it probably isn't), then I don't want it to be worth an hour of some social engineer's time to steal my account.
You could generate the key(s) on a (airgapped, if so inclined) computer, push to multiple Yubikeys (though other brands are available, let's not let it become a 'google') and then delete the private key(s) from computer.
Of course, it depends what you want to defend against with your backup - this works fine for a broken OpenPGP smart card (;)) but in the event that it's lost or stolen.. well the best that can be said is that it gives you some window to create a revocation cert, login, and change the single registered FIDO device to a (third) newly provisioned one (or your second one, the backup, provisioned with a new key after logging in).
Or you could use a different method as your backup (IME if they only allow one they do at least also have backup codes, app-based, etc.) in order to login and change the device to the backup provisioned with a different key. (So it can be generated on the device in this case.)
Those backup keys defeat the entire purpose of 2FA and are like storing passwords in plain text. It only takes 1, maybe 2 of those codes for an attacker to add another security key to your account for future unlimited access.
Supporting multiple keys is a good idea but it solves a different problem. People want peace of mind.
Backup codes are not like passwords in at least two important ways:
* The site picks them, not you, so they're random nonsense different for each code, rather than inevitably being password1234 and being the same on Instagram, Twitter and your bank account.
* You don't need them usually, so there's no reason you'll have them to hand, which then makes it harder to steal them. Even for a social engineering attack, you increase the friction because now to help the attackers a user needs to go find their backup keys which is a hassle.
I think the parent’s point is that if you’re going to allow backup codes you might as well just add “second password” as a form of 2FA and enforce some basic complexity requirements.
Some policies will disable your Yubikey/U2F key if it goes unused for N days. Usually low enough that it's annoying to keep a backup key.
We've used https://rsc.io/2fa to share TOTP keys between multiple individuals. We store the secret key in a shared password store that's also behind a separate 2FA login.
With TOTP it's very understandable to limit you to one authenticator as each additional authenticator makes it easier to attack you (meaningfully more guessed codes are now correct at any moment) and the UX is awful because there's no good way to discern one TOTP authenticator from another.
WebAuthn / U2F are explicitly designed to allow multiple authenticators. The W3C WebAuthn spec. explicitly calls out that you should allow users to register more than one authenticator, and might want to provide a nice way for your users to label them, e.g. "Yubikey", "iPhone", "Greg's key" or whatever. Every site I've used that offers WebAuthn does this correctly except AWS and you'd have to take that up with Amazon.
> ... each additional authenticator makes it easier to attack you (meaningfully more guessed codes are now correct at any moment) ...
That isn't really an issue with TOTP either (if properly implemented), as each authenticator has a unique identifier and seed.
I've got multiple authenticators set up on a PayPal account. When logging in, I simply select which of the authenticators I want to use and enter the code it gives me.
I remember a story about how our (third party) security operations center doesn’t allow phones on the floor, but most of its customers use Duo Push. So there is a table in the middle of the floor with all the 2FA phones bolted to it.
Threat is that the mobile devices could be used to 1) photograph proprietary systems, 2) exfil data over mobile networks or potentially introduce 3) malware via usb ports.
I don't really get how bolting the devices is a solution for enabling 2FA, unless the access console is also at the same location. But it would prevent 1) and 3).
As long as the table is bolted to the floor, you're replacing posession (of a phone) factor, with location (in SOC) factor. Keeps both client happy, and security architect sleeping soundly.
The threat actors are SOC employees or visitors who might (maliciously or unwittingly) use their smartphones to record sensitive data.
The risk is data exfiltration. A selfie in front of the SOCs giant screen wall; a compromised phone that keeps recording audio.
The problem is that a third-party SOC will generally need a way to connect to their customers' systems. Sometimes that gets properly implemented as a site-to-site VPN with isolated jump hosts and session recording. In other instances, the SOC gets to use normal employee VPN access, and usually a handful of VPN tokens.
And now you have a fun conflict: One customer insists that no mobile phones are carried inside the secure SOC area. Another uses a VPN solution that requires a smartphone (and, e.g. Duo Push) as the second factor. How do you satisfy both? You take a set of mobile phones, possibly add some measures to stop them from being used as recording devices, and bolt them to a table so they can't leave the secure area.
There are these RSA-brand tokens that show a new TOTP number every few minutes. Occasionally people find an unsecured webcam pointed at one of those somewhere on the internet...
Nice build but over engineered. You could achieve the same result by taping a piece of aluminum foil, or maybe even a wire to the capacitive sensor and connecting it to ground through a relay. Use the ESP8266 to toggle the relay when you want to simulate a button press.
When I was at Google around 2012, the company had a custom 2FA dongle that detected motion rather than touch. An engineer who had remotely ssh'd into their workstation needed to 2FA and realized that they could send an SMS to their phone, cause the phone to vibrate, and trigger a false 2FA event on the dongle. (Or maybe they got their computer to play a loud noise. I forgot the specific details.)
Similar to this fake finger, it was a cool hack at the time but defeated the purpose of 2FA.
More on defeating 2FA, during my internship at Amazon I created a grease monkey script that would store 'n' yubikey codes and paste them automatically whenever browser asked for a yubikey code and this worked flawlessly because afaik yubikeys code have No Expiry... they just have to be used in order of their generation... I highlighted this issue of No Expiry of yubikey codes but no one took it seriously...
Correct - just like an evildoer who had your yubikey could generate and save a bunch of yubikey key strings, they could also generate and save a bunch of time-based codes for times in the future by changing the host clock.
You can use a bidirectional challenge-response between the yubikey and a trusted server - that's what U2F does.
But honestly, if an attacker has both your password and physical possession of your 2fa token, it's already game over.
Sure you can! (For yubikey OTP key strings at least) Just have yubikey sign the current time, you're already trusting them to correctly verify the key string.
U2F is a different animal though. The question is then: does timestamping the response reduce the attack surface enough compared to the downsides? I'd argue yes since the described attack can offset a failed login and the actual attack after a MITM. Also, it is probably possible to get the time-stamp within the kernel. If your root is compromised you're also done for.
> Just have yubikey sign the current time, you're already trusting them to correctly verify the key string.
By "them" you presumably mean Yubico not the Yubikey. But these OTP strings are generated by the Yubikey, not by Yubico so there's no way for them to be "signed" in this way. The verification process takes place at authentication so that would just tell you the current time, something you already know, it's useless.
> U2F is a different animal though. The question is then: does timestamping the response reduce the attack surface enough compared to the downsides? I'd argue yes since the described attack can offset a failed login and the actual attack after a MITM. Also, it is probably possible to get the time-stamp within the kernel. If your root is compromised you're also done for.
For WebAuthn (and its predecessor U2F) none of this is correct.
The Relying Party (a web site you want to authenticate to) sends a random challenge. A correct authentication in part signs that challenge, so timestamping is irrelevant here, your answers are either fresh or they're invalid anyway.
Because a physical FIDO authenticator is independent from the computer you are not necessarily "done for" if the computer is compromised, unless you've outfitted your computer with a finger to press keys it cannot, for example, press the button on the key, so there is no way for the compromised computer to obtain signatures from the authenticator with the UP (User Present) bit set, and checking UP in the signed response is part of WebAuthn.
A little off topic: Does anyone know of a way to get the results of a yubikey press into a remote desktop session? I frequently remote desktop into laptops that are in arms reach. If I need to use the yubikey, I have to remove it and plug it into my desktop and press it, since it acts as a local keyboard.
Wouldn't a local keyboard type into a remote desktop session? If a local keyboard can't type into a remote desktop session, the remote desktop session sounds mostly useless.
I guess a ~10kohm resistor in series couldn't hurt, should something go wrong. After all your finger is not exactly super conductive in the first place...
Why not just keep the wire attached to the Yubi-key, but leave it electrically floating (high-impedance state) and have the board ground it whenever it needs to be pressed? No need for mechanical triggers...
"Why have an Applescript call a shell script? I found that when I launched the shell script directly from Karabiner Elements, it opened a new instance of Terminal.app and took focus away from the window that is prompting for the YubiKey. This causes everything to run in the background."
240 comments
[ 4.7 ms ] story [ 217 ms ] threadThe odds any malware would both locate this api, and actionably utilize a generated otp, is slim to zero.
The use of U2F tokens as single factor auth seems to have promulgated thanks to this implicit 3rd factor keeping the situation moderately at bay. I posit that this is largely the same reason that keys and locks remain relatively secure despite that almost all of them are trivial to bypass or duplicate. The physical access bit is just so damn inconvenient for the typical modern white-collar criminal.
I used it for testing smart meters in Norway, so we did not need to run to the lab to trigger events. The best part is that the whole menu is interactive by just one physical button, a great job for a Bluetooth button pusher + Python.
It is also capacitive so it work on the phone screen, and YubiKeys (?)
DNS isn't set up right.
https://www.youtube.com/watch?v=l-fcfGwepog
Now, electrifying that would be neat!
I wonder if one could design a similar solution without requiring a bridge. Although of course given the power consumption adding WiFi on the actuators might not be a great idea.
Now, if they existed for $5 each, I would be all over it and buy 10
Compliance?
If you allow for a YubiKey, or any other physical artifact in that matter, to be remotely invoked it negates its utility as an authentication factor in the physical domain.
And the setup in the article isn't even remote access. If the only way it can be triggered is a local button press, you're golden.
I know... layers of unlikelihood.. but I'd probably opt for a physical "good button" gapped from my computer as sort of a closed electrical extension of my finger.
Even a virtual 2fa button is useful. It prevents people using your stolen credentials to login to websites unless you click the button, even if it's just a virtual button.
Sure your computer can be compromised, but it's probably still more secure than sms 2fa.
Good meeting you at the FLL competition last year! -Cody
good job bert!
"Why not just press the button?" ... "Don’t you get it? This button BAD, but this button GOOD. Me want to press GOOD button."
The 2FA services that allow >1 YubiKey are good, I can have a backup key locked up some place and use them as intended.
The fact that you can store copies effectively defeats the purpose of 2FA.
One of the reasons to have multiple YubiKeys is that if I lose one on the street I can just login to all my services with my backup key, disable the lost/stolen key, and buy and register a new key.
Whereas if someone got a hold of your TOTP secret, ehhh ... you might not necessarily know for a while.
> to plug this [Yubikey] into a server and control it through USB over IP.
Obviously multiple Yubikeys is the only real solution.
One reason to have multiple copies of the TOTP secret is to not be locked out of accounts should one lose their 2FA token. For example, if one has two copies of the TOTP secret, one of which is in a secure location, and one of which is used for daily purposes, as long as the secure location is reasonably secure, it's not much different than storing backup codes in that secure location.
I do agree with you that having multiple copies of the TOTP secret that can be lost and not noticed isn't a good idea though.
They should ideally support >1 TOTP authenticator if they don't intend to support U2F.
I don't want SMS as a backup option; I have deprecated SMS, it's old tech and needs to die along with telegrams.
Maybe The Google app has changed now, I have no idea. I’ve had much better luck storing TOTP in 1Password and Bitwarden - which allow you to sync across multiple platforms. So now device upgrades are a non-issue.
Most sites give you some static backup codes for TOTP - definitely store those somewhere safe, they can be a lifesaver.
Twitter and AWs only allowing one is just awful though.
Do most services that support such devices really only support a single key/device? Do they offer the same one-time recovery codes that are generally offered with TOTP (though the storage/security of such codes server-side is dubious), for the eventual failure of the Yubikey (not if, but when)? Surely a tiny hardware device reaching the end of its lifespan doesn't mean you lose access to your account.
I have personal accounts with Google, GitHub, GitLab, Facebook, and DropBox that use at least two of those four authenticators. I also have Login.gov (US government) and Gov.uk Verify (one of two UK government authentication systems, hooray for needless duplication)
Most of them offered one-time recovery codes which I hand wrote in a book of one-time recovery codes, but without fetching that book I can't tell you it was all of them.
At my previous job I used a physical authenticator with AWS and that was indeed restricted to just one authenticator, on the other hand there's an account "administrator" for that AWS account so if you lost your authenticator the admin can get you back in and I assume larger companies have multiple people in the administrator role.
The WebAuthn specification explicitly says that Relying Parties (ie web sites) should support multiple keys.
And yes, if you lose access to all methods of authentication in some cases you lose the account. I believe GitLab explicitly flagged their intent to act this way for accounts that don't pay them money, and I would prefer this. As I wrote back then, if it's not worth an hour of my time to somehow try to prove my identity to you after locking myself out of your service (which if I'm not paying you, it probably isn't), then I don't want it to be worth an hour of some social engineer's time to steal my account.
Of course, it depends what you want to defend against with your backup - this works fine for a broken OpenPGP smart card (;)) but in the event that it's lost or stolen.. well the best that can be said is that it gives you some window to create a revocation cert, login, and change the single registered FIDO device to a (third) newly provisioned one (or your second one, the backup, provisioned with a new key after logging in).
Or you could use a different method as your backup (IME if they only allow one they do at least also have backup codes, app-based, etc.) in order to login and change the device to the backup provisioned with a different key. (So it can be generated on the device in this case.)
Supporting multiple keys is a better solution.
Backup codes are not like passwords in at least two important ways:
* The site picks them, not you, so they're random nonsense different for each code, rather than inevitably being password1234 and being the same on Instagram, Twitter and your bank account.
* You don't need them usually, so there's no reason you'll have them to hand, which then makes it harder to steal them. Even for a social engineering attack, you increase the friction because now to help the attackers a user needs to go find their backup keys which is a hassle.
We've used https://rsc.io/2fa to share TOTP keys between multiple individuals. We store the secret key in a shared password store that's also behind a separate 2FA login.
For U2F, check out https://github.com/github/SoftU2F
WebAuthn / U2F are explicitly designed to allow multiple authenticators. The W3C WebAuthn spec. explicitly calls out that you should allow users to register more than one authenticator, and might want to provide a nice way for your users to label them, e.g. "Yubikey", "iPhone", "Greg's key" or whatever. Every site I've used that offers WebAuthn does this correctly except AWS and you'd have to take that up with Amazon.
Just match the code the user entered against all registered authenticators. Limit the number of authenticators to maybe 3-4 per account.
That isn't really an issue with TOTP either (if properly implemented), as each authenticator has a unique identifier and seed.
I've got multiple authenticators set up on a PayPal account. When logging in, I simply select which of the authenticators I want to use and enter the code it gives me.
john_travolta.gif
I don't really get how bolting the devices is a solution for enabling 2FA, unless the access console is also at the same location. But it would prevent 1) and 3).
Nice solution.
The risk is data exfiltration. A selfie in front of the SOCs giant screen wall; a compromised phone that keeps recording audio.
The problem is that a third-party SOC will generally need a way to connect to their customers' systems. Sometimes that gets properly implemented as a site-to-site VPN with isolated jump hosts and session recording. In other instances, the SOC gets to use normal employee VPN access, and usually a handful of VPN tokens.
And now you have a fun conflict: One customer insists that no mobile phones are carried inside the secure SOC area. Another uses a VPN solution that requires a smartphone (and, e.g. Duo Push) as the second factor. How do you satisfy both? You take a set of mobile phones, possibly add some measures to stop them from being used as recording devices, and bolt them to a table so they can't leave the secure area.
https://www.youtube.com/watch?v=IaoDfOaYF4w
Similar to this fake finger, it was a cool hack at the time but defeated the purpose of 2FA.
Ok got it and we can't trust the host PC clock or any web based clock via host pc...
I'm not sure if a Yubikey's simplest mode as a HID device can read the device's wall clock it's attached to without additional drivers?
You can use a bidirectional challenge-response between the yubikey and a trusted server - that's what U2F does.
But honestly, if an attacker has both your password and physical possession of your 2fa token, it's already game over.
U2F is a different animal though. The question is then: does timestamping the response reduce the attack surface enough compared to the downsides? I'd argue yes since the described attack can offset a failed login and the actual attack after a MITM. Also, it is probably possible to get the time-stamp within the kernel. If your root is compromised you're also done for.
By "them" you presumably mean Yubico not the Yubikey. But these OTP strings are generated by the Yubikey, not by Yubico so there's no way for them to be "signed" in this way. The verification process takes place at authentication so that would just tell you the current time, something you already know, it's useless.
> U2F is a different animal though. The question is then: does timestamping the response reduce the attack surface enough compared to the downsides? I'd argue yes since the described attack can offset a failed login and the actual attack after a MITM. Also, it is probably possible to get the time-stamp within the kernel. If your root is compromised you're also done for.
For WebAuthn (and its predecessor U2F) none of this is correct.
The Relying Party (a web site you want to authenticate to) sends a random challenge. A correct authentication in part signs that challenge, so timestamping is irrelevant here, your answers are either fresh or they're invalid anyway.
Because a physical FIDO authenticator is independent from the computer you are not necessarily "done for" if the computer is compromised, unless you've outfitted your computer with a finger to press keys it cannot, for example, press the button on the key, so there is no way for the compromised computer to obtain signatures from the authenticator with the UP (User Present) bit set, and checking UP in the signed response is part of WebAuthn.
https://developers.yubico.com/OTP/OTPs_Explained.html
> https://developers.yubico.com/OTP/OTPs_Explained.html
Yes exactly... so script used to use them in order of their generation... FIFO basically...
https://www.google.com/search?q=webcam+rsa+token&source=lnms...
But I guess for convenient monitor sharing it could be useful to RDP into a machine within your reach.
What is likely an actual problem though is if your security key uses U2F and you have it plugged into your local machine.
Does anyone know why that is?