The bit of the NHS I work in is gradually phasing out 2FA smartcards. Go figure…
2 Likes
Out of curiosity, since I’ve only interacted with services that are set up to use FIDO/FIDO2 devices, not(yet, working on it for my computers) configured the other side of the picture; where do the ugly gotchas live?
Are the standards fine but the authentication system side or the client/authenticator sides just deeply immature compared to stuff that has been around for a while?
Do different devices that ostensibly support a given standard have a nasty habit of…mileage variation?
Is there anything notably dysfuntional baked into the standards?
It definitely appears to be less mature on the phone side(the cheaper fobs don’t do NFC at all, since that hardware adds cost; and with the exception of USB-C fobs and newish Android devices direct connection without adapter dongles isn’t happening; and software support seems to be a bit spottier.
That said, with FIDO/FIDO2 there is explicit support for the idea that you can/will use several authenticator devices(both for convenience and to reduce the lost-key risk; since, unlike RSA-style fobs, you can use a given fob for as many services as you wish it’s a lot easier to have several registered); and it isn’t required that the fobs be separate from client devices(I know recent Intel-platform laptops have included an integrated authenticator device, I assume phones with the ability to act as an authenticator via USB or NFC or both are at least coming on the Android side, Apple’s behavior is harder to predict).
You don’t need to have a single fob support all use cases, just an authenticator device and support for it on the relevant platforms. That’s still in rough shape; but at least viable in principle; unlike having a plug-in option that covers all cases.
(Edit: anecdotal data point: I recently got around to enabling Gmail’s enhanced account security; and using the most basic NFC yubikey just worked to log in a never-getting-android-9 Nexus 5X. I was honestly pleasantly surprised.
I’m not sure if 3rd party authentication works as neatly, mostly because FIDO2 isn’t exactly uniformly supported at the moment; I’m hoping that changes. Haven’t had the chance to test in iOS; or the Bluetooth case.)
1 Like
All I want is security that’s not a part-time job to maintain and that I can be stupid and still not fuck it up. Until then, there is no such thing as security, because it’s been systemically compromised.
why stop with the phone? wallet - that’s a security key. Watch? Nope - security key. Fleshlight? (Also a security key!)
I’m sure most of my grief is from Microsoft’s ridiculously complicated way of doing things. And what isn’t from that is from staff constantly forgetting their PINs.
I did, however, manage to get Yubikey-based VPN working shortly after my original post, and I worked out how to enable the PUKs a few days back, so yay!
You mention PUK and PINs; are you doing FIDO/FIDO2/WebAuthN; or are you using the Yubikeys that also emulate a smartcard reader with one or more PIVs inserted? (as well as a variety of other things beyond what the basic blue FIDO/FIDO2 models support; Yubikey Neo or Yubikey 5 in one of its form factors)
I’m told that the software support for the smartcard case is more mature(in the US case largely because if you don’t support CACs you ruin your chances of sweet, sweet, DoD sales and the DoD has pushed that policy for some years; in some European cases because of smartcard-based ID cards and such); but not…exactly…aimed at being a trivial DIY implementation(everyone loves hierarchical PKI implementations, right?); while the FIDO2/WebAuthN stuff is still pretty sketchy in a lot of cases, especially outside of Google; but expected to have a future among consumer-facing services; unlike smartcards which sadly never seemed to have much momentum outside of specialist use cases(and SIM cards), despite having been a mature cryptographic token for ages and being amenable to size reduction through emulations like that provided by the yubikey for cases where a credit-card sized token and corresponding reader aren’t going to fly(over in CAC land there are some gloriously terrible iPhone cases aimed at bringing CAC compatibility to iOS; so hideous you can’t help but love them a little bit).
The PIV one.
You are absolutely meant to be able to duplicate it. The algorithm’s published in… uh… RFC6238, I think.
For your own security, time-based OTPs are pretty damn secure if used as a genuine 2FA measure. The weakness is actually on the server-side where to participate in the protocol the server must keep a copy of the shared secret. You can hash and salt a password to within an inch of its life, but the shared secret (the initial seed) has to be stored in a readable format. Best you can do is keep it encrypted and store the key to decrypt it in a FIPS 140-2 L3^ module bolted onto your data center, only keeping a decrypted version in-memory long enough to make use of it, as needed, and then wiping it. That’s somewhat more secure.
Of course, it’ll all be ruined when it turns out that the user has no PIN on the phone with the OTP app, the password is in a note-taking app on the same phone, and it got stolen.
This topic was automatically closed after 5 days. New replies are no longer allowed.
