[HN Gopher] YubiKey Bio Series
___________________________________________________________________
YubiKey Bio Series
Author : chris_overseas
Score : 79 points
Date : 2021-10-05 19:22 UTC (3 hours ago)
(HTM) web link (www.yubico.com)
(TXT) w3m dump (www.yubico.com)
| 1123581321 wrote:
| Is it possible for a retail user (no domain, AD, etc.) to use a
| YubiKey as a Windows Hello second factor? Forgive me if this is
| obvious; I've spent a lot of time googling and I only come up
| with references to using in context of enterprise device/user
| management.
|
| Because if YubiKeys could be used, this seems much better than
| the typical cheap USB fingerprint readers that are for sale.
| eightysixfour wrote:
| Yes, Windows can use a Yubikey for Windows Hello either to
| unlock the device (not login) or as a second factor for
| anything else supporting Hello.
| robocat wrote:
| Does anyone else find fingerprint readers mostly unusable?
|
| I love them when they work, but my fingers are very often
| unreadable due to dirt, cuts, paint, oil, swimming or bath
| wrinkles, etcetera. I've had the problem with multiple devices
| (e.g. iPad, Nokia phone).
|
| Because I have to use the secondary authentication so much of the
| time, I find little merit in using a fingerprint for security.
| staticassertion wrote:
| The one to unlock my Samsung Galaxy whatever-number-it-is works
| pretty consistently.
| jolmg wrote:
| Android supports registering multiple fingerprints to get
| around this. I wonder if that's also possible with this key.
| jcrawfordor wrote:
| I'm with you, I've fallen out of the habit of using fingerprint
| auth on any of my devices that support it (Macbook, Thinkpad,
| Motorola phone) because it's so unreliable. I have to re-enroll
| at least weekly if I want to keep it working well. I have
| eczema issues on my hands, which I think is the main issue, but
| also have found cuts and paint/glue to be common problems. I
| can enroll multiple fingers but that means I have to try four
| fingers before it unlocks... and usually I end up enrolling the
| same finger multiple times instead since the device has stopped
| recognizing it.
|
| For what it's worth I used to have a job that involved frequent
| use of an optical fingerprint reader (the type that's a camera
| behind a glass platen) and did not have these types of problems
| with it. I think it's a weakness of the capacitative type of
| reader that all devices are using now, or possibly just less
| sophisticated matching software.
| cainxinth wrote:
| Don't know if this works for others, but for Apple Touch ID you
| can solve the wet finger issue by adding another set of prints
| while the finger is wet.
| 1970-01-01 wrote:
| Something you are, protecting something you have, which is
| designed for protecting something you know. 3FA is too much. Lose
| any of the 3 and access is denied.
| bsza wrote:
| I know this analogy is not pedantic but it's fun to imagine the
| same argument with physical keys.
|
| Lose your hands and you won't be able to use your house key.
|
| Lose your house key and you'll have nothing to use.
|
| Lose your mind and you won't know how to use a key.
| syntaxing wrote:
| Off topic, but it's so frustrating how yubikey (or any non
| SMS/email 2FA as a matter of fact) is not supported for any bank.
| I think I would sign up right away to a bank that supports
| yubikey or authenticator apps.
| ssklash wrote:
| Same. I don't know of a single US-based bank that supports it.
| Redori wrote:
| Charles Schwab supports it
| syntaxing wrote:
| Can you bypass it with SMS? Or can you permanently disable
| SMS 2FA?
| dyingkneepad wrote:
| When they finally support it, I guess they will add the
| convenient option to say you don't have your yubikey with you
| at the moment and then an SMS will be sent instead.
| syntaxing wrote:
| You just described Vanguard. What's the point of yubikey
| support when you can bypass it with SMS....
| arianvanp wrote:
| My bank recently started supporting it:
|
| https://www.online-zahlen-mit-fido.de/
| zxcvbn4038 wrote:
| I don't buy into the "passwordless" designs. A fingerprint
| scanner might be better then a touch sensor but in the end it's
| still a single factor.
|
| I meet a lot of people who bought yubikey nanos and leave them
| plugged in all the time. Defeats the purpose. There should be a
| kiosk where you can exchange people's unattended yubikeys for a
| cookie or some other treat. That would take care of that problem.
| staticassertion wrote:
| Importantly though it's a _good_ single factor. Passwords aren
| 't good.
|
| 1. They get repeated.
|
| 2. They get phished.
|
| Even just as a single factor, even without a fingerprint
| reader, a yubikey is far superior to a password. Adding a
| biometric on top of that is wayyyy better than a password.
|
| Most of what MFA has done for us is actually just provide
| slightly better "A's". It's not the quantity that counts, it's
| the quality.
|
| Previously to reach a good quality we'd need multiple factors.
| We've reached a point now where we have standards for
| authentication that are strong, often "strong enough", even
| with a single factor. A password then becomes a bit of a bonus.
| arianvanp wrote:
| When Webauthn requests user verification on a non-bio yubikey
| user needs to provide a (6 digit) pin.
| ghostpepper wrote:
| Doesn't Yubikey design them to be left plugged in all the time?
| I don't see how it compromises the security at all
| packetslave wrote:
| Depends on which Yubikey. The nano series (aka the "gnubby")
| are designed to be permanently plugged in. The 5 and 5C are
| designed to live on your keyring.
| _zoltan_ wrote:
| it absolutely does not defeat the purpose: if you somehow
| manage to get my password/ssh key _remotely_, there is still
| one more obstacle you cannot get as it's _local only_. that is
| why it's a second factor.
|
| something you know with something you have.
|
| I'd say this covers the 99% of how credentials are being
| misappropriated.
| loosescrews wrote:
| The yubikeys are designed to be non-clonable, so it is two
| factors: something you have and something you are. Not all
| factors are created equal, and in the past there have been
| issues with biometrics not really being a reliable indicator of
| something you are.
| OJFord wrote:
| It doesn't defeat the purpose (if you take it, they've lost a
| Factor and you still don't have enough of them) but it will
| certainly teach them to have more than one.
|
| (Aside: I have a story for another time about how I soft-
| bricked my first when finally getting around to setting up a
| second; that I've not yet quite recovered enough to properly
| tell...)
| warp wrote:
| At $85 for the USB-C version it is surprisingly expensive (In my
| mind these Yubikeys have all been around $50).
|
| And it only supports FIDO/Webauthn/U2F -- so you cannot use this
| with the Yubikey authenticator app to store TOTP tokens.
| [deleted]
| saxonww wrote:
| I bought some Yubikey standards back in 2014 and they were $25
| apiece. The Yubikey 5 NFCs I got 4 years later were $45 apiece,
| but had NFC and did more stuff. They released some U2F-only
| yubikey security keys that I thought were $20 but I am not sure
| (they were blue, and cheap).
|
| Now these, which the site suggests can only do U2F/Webauthn
| with fingerprint, are $80. I think it's cool to have a portable
| fingerprint-secured webauthn token, but it's disappointing to
| see them so expensive. I wonder if this is the long-term price,
| or if they are more expensive temporarily due to supply chain
| issues or something like that. Or, maybe they are substantially
| cheaper in bulk.
| rPlayer6554 wrote:
| Looks cool, but sad there is no NFC support.
| luis8 wrote:
| I wonder if the limitation is power. Can a fingerprint scanner
| be powered by NFC?
|
| OTOH in my specific use case, I only use the NFC with my phone,
| the USB-C version should take care of that
| notemaker wrote:
| Yes, see e.g https://www.zwipe.com/
|
| But would of course depend on the sensor. Zwipe uses a sensor
| from the Swedish company FPC
| staticassertion wrote:
| This looks like it might be a bit of an early testing-the-
| waters, or even a one-off to satisfy a specific set of
| customers (note that they're FIPS compliant _only_ ).
|
| If there's more traction I would expect future models to
| include more features.
| jolmg wrote:
| No OpenPGP Smartcard support, I see. :(
| jordemort wrote:
| I would probably buy it if it had OpenPGP support
| jolmg wrote:
| Me too. OpenPGP is super flexible and this would've been an
| upgrade to 3FA for everything I use it for.
| rkeene2 wrote:
| Most of the YubiKeys support PIV (NIST SP 800-73) mode, which
| gets you X.509 support (and a PKCS#11 module), which has much
| broader support than PGP.
| staticassertion wrote:
| The Bio series does not support PIV/PKCS#11 at this time
| afaik
| nixpulvis wrote:
| What are the alternatives now? I never _really_ liked the
| Yubico stuff, though I have to admit that their hardware is
| well made.
| tialaramex wrote:
| If you wanted OpenPGP to protect SSH, you should consider
| upgrading clients and servers to a modern OpenSSH which can
| just speak FIDO (which this and other recent Yubikeys
| support)
| jolmg wrote:
| I haven't used FIDO. If you lose your FIDO key, do you have
| the option of buying another one and making it authenticate
| like the original without having to inform all the servers
| of the change?
|
| I think the only advantage of FIDO over OpenPGP is that
| some web services support it. Are there other advantages?
| staticassertion wrote:
| > I haven't used FIDO. If you lose your FIDO key, do you
| have the option of buying another one and making it
| authenticate like the original without having to inform
| all the servers of the change?
|
| I think this is technically possible (some keys let you
| access the seed iirc, though the FIDO counter would not
| match) but not recommended. Instead you'd just register
| two keys so that if you lose one you have a backup.
| jolmg wrote:
| I don't know of a similar product that supports tap-prompts
| and blinking lights[1] like Yubikeys do. Yubikey 4/5 still
| seem to be the best, IMO.
|
| [1] https://news.ycombinator.com/item?id=28765982
| amelius wrote:
| Can someone explain why this makes authentication more secure?
|
| If I tap the device while a malicious process is attempting to
| access another machine in the background, what good does this
| device do?
| [deleted]
| [deleted]
| jolmg wrote:
| Not with the Bio series apparently, but at least on the Yubikey
| 4, when you're setup with OpenPGP, a tap works with a single
| request and it prompts you to tap with a blinking light. If
| it's blinking when you haven't done anything to prompt a tap,
| that would be something to worry about. If you do something
| that prompts a tap and a malicious process also requests
| something from the key at the same time, you'll get 2 requests.
| You'd tap it for the request you're expecting, see it blinking
| faster to confirm your tap, and then blink slowly again to
| request the 2nd tap. That second request would be your cue for
| worrying. IOW, the blinking is an alert against your scenario.
| amelius wrote:
| Ok, thanks! How do well does this key go together with
| workflows that use automation (e.g. daily rsyncs over the
| network that run in the background)?
| jolmg wrote:
| Not sure how you want to combine automated daily rsyncs
| with hardware keys. You can use OpenPGP for ssh
| authentication, and set it up so it prompts you when rsync
| starts automatically. However, do you really want your
| automated jobs to depend on having a human to answer
| prompts or at least having a key inserted when it's
| scheduled to run? It sounds like there could be a better
| setup.
| staticassertion wrote:
| FIDO keys are really more about avoiding human errors/
| human auth. If you need to authorize a server you may want
| to just use a client certificate.
| karmakaze wrote:
| I don't even understand the threat model for this, and why it's
| better than the fingerprint sensor built into the laptop. Seems
| like it's just writing the software elsewhere. What's up with
| the micro Yubikeys always left in a usb port operable by anyone
| made even less sense, so a step up.
| yoz-y wrote:
| The threat model is that people can't ssh to your machine in
| order to elevate their access (e.g. corporate VPN), because
| they can't physically touch the key. Example: whatever
| happened when major Twitter accounts were compromised.
| g_p wrote:
| Compared with a button based yubikey, someone else can't
| trivially tap this one if it's left behind, as you say.
|
| From a threat model perspective, biometrics are far from
| perfect. This setup avoids disclosing the biometric to the
| host system though - the yubikey itself validates the
| biometric and signs (or doesn't sign) a response with an
| internal protected private key. If you had a sensor built
| into a laptop or workstation, you are trusting that sensor.
| Some old ones used to expose raw fingerprint data to the
| operating system, which is clearly bad.
|
| If the user brings their own reader, you don't need to expose
| any biometric information beyond the yubikey itself (which is
| issued per user), so a host compromise or a rogue system
| won't be able to compromise someone's biometrics. Admittedly
| in this case a lot of the threat models that make sense would
| involve shared computers etc, and those have their own
| security issues.
| cwp wrote:
| I think the point of this is that if somebody steals your
| YubiKey, they also have to steal your finger to be able to use
| it.
| jolmg wrote:
| If this had OpenPGP support (though it may also be true of
| other modes) they'd also need to know your PIN code.
| kingcharles wrote:
| If you care about your security you will not use biometrics as
| the only means to secure your data. In the USA at least some
| courts have ruled that force can be used to make you unlock
| devices protected by only biometrics. See, e.g.
| https://www.biometricupdate.com/201912/federal-state-court-r...
| eykanal wrote:
| Its pretty well known that fingerprints _by themselves_ are a
| pretty poor replacement for passwords. (a) They're public, in
| that it's pretty easy to get someone's fingerprint... just find
| something they touched recently. (b) If they're compromised its
| impossible to change them.
|
| I don't think this gets around either of those points, but I am
| curious if this somehow makes it much more difficult to either
| compromise the fingerprint hash (fingerprint fingerprint?) or
| makes the resultant hash less useful once compromised.
| 2OEH8eoCRo0 wrote:
| It's not only a fingerprint. The fingerprint tells the yubikey
| that it's you activating it.
| g_p wrote:
| In essence, you require both the Yubikey in question, and the
| information supplied by the fingerprint reader to the Yubikey,
| in order to abuse this system.
|
| From the perspective of a U2F token, which uses a regular
| button, this is an increase in security for most users -- if
| their token is lost or stolen, or left in their device, someone
| cannot use their token by tapping the button.
|
| This doesn't address the inherent problem of
| irrevocability/unchangeability of biometrics, but it presents
| an interesting usability trade-off that could help non-
| technical users to keep their systems more secure.
|
| If you capture the wire signal between the fingerprint reader
| sensor and the module, it is likely that you could replay a
| valid authentication. If not, you could delve deeper into the
| sensor until eventually you are able to inject capacitive data
| from the sensing surface itself, and do this.
|
| In this case, by combining the use of a biometric with strong
| cryptographic authentication through the token, you require
| both to compromise the user -- no biometrics are shared with a
| server, it's all local. However if you lose either the token,
| or the ability to use that fingerprint (i.e. scratch or
| damage), you will lose access to the key the Yubikey has
| protected, absent some kind of backup password. For many users,
| that backup password will be the weak link, but a Yubikey
| should at least be able to rate limit attempts and erase its
| internal state if there are too many attempts.
| tialaramex wrote:
| For the WebAuthn scenario there is no inherent backup,
| there's deliberately no way to export the keys. For a random
| web site, they're likely going to offer some way back in -
| albeit Google is content to make that quite hard if you
| choose their "Advanced Protection" scheme (and I think one of
| the free Git offerings just says too bad, you gave us no
| money, you're locked out but you lost nothing of value), but
| an employer might very reasonably issue employees a Security
| Key and say something like, look, if you lose it that sucks
| but go to Front Desk with your Line Manager, and they can
| issue you a new one, there is no bypass.
|
| As a user, it also makes sense (particularly if you know
| you're a real target, e.g. a political journalist,
| politician, activist) to just own more than one.
|
| > Yubikey should at least be able to rate limit attempts and
| erase its internal state if there are too many attempts.
|
| On the previous generation with a PIN as second factor, if
| you guess the PIN wrong repeatedly it locks you out.
| g_p wrote:
| Indeed - the lack of backups in WebAuthn is a design
| feature (although I can see credible usability issues in
| online services where users should really enrol several,
| but struggle to keep them in different locations and ensure
| they register their off-site backup key to each service
| etc.)
|
| I presume (but haven't reviewed in detail) that these bio
| keys will have a backup PIN in the same way previous models
| had the PIN available for management and WebAuthn modes of
| operation - there are some real-world failure modes where
| wet hands or a bandaged finger may be an issue, but the
| user still wants to keep using it. I do agree the best
| solution is to get several tokens, enrol them all for each
| service, and just keep them as safe as you realistically
| can.
| staticassertion wrote:
| The backup would be another hardware token, ideally. Just one
| that isn't biometric. You would guard physical access to that
| token more closely.
|
| Google's Advanced Protection Program enforces two keys, since
| they also make recovery much stricter.
| staticassertion wrote:
| Without this model the attacker needs to steal the Yubikey.
| With this model the attacker needs to steal the Yubikey and
| pull a fingerprint.
|
| It remains to be seen if that's a meaningful difference, but it
| seems reasonable that in some situations it could make the
| attack much more costly.
|
| I could see myself using this when traveling.
| wnevets wrote:
| > Its pretty well known that fingerprints _by themselves_ are a
| pretty poor replacement for passwords. (a) They're public, in
| that it's pretty easy to get someone's fingerprint... just find
| something they touched recently. (b) If they're compromised its
| impossible to change them.
|
| I'm a bit more worried about Russian ransomware operators
| getting my passwords than my fingerprint.
| executive wrote:
| even if they chop off your hand?
| staticassertion wrote:
| Time to add an embedded EKG as another factor :)
| wnevets wrote:
| If Russian ransomware operators want to even attempt to
| chop off my hand I would need to start making much more
| interesting life choices that I have been.
| pfundstein wrote:
| A fingerprint is not a password, it's a username.
| jolmg wrote:
| I haven't used any of the other modes on my Yubikey 4 than the
| OpenPGP Smartcard. I would hope that other modes also support
| PINs/passwords, so the fingerprint is just an additional
| factor. If that's the case, it's not necessarily about
| replacing passwords with fingerprints.
| yegle wrote:
| The cookie preference on the website is impressive. By default
| only necessary cookies are enabled if you just click "Accept".
| You also have to explicitly enable the "functional cookies" to
| view the embedded video.
___________________________________________________________________
(page generated 2021-10-05 23:00 UTC)