[useryman]

Other than being a random untrusted USB device, is there any reason to not use the cheapest generic U2F device you can find?

I've been wanting to start using them for a while, but yubikeys are too expensive for me to get a bunch of.

[microtonal]

I would try to find a key that supports ed25519, since there are concerns about the NIST curves used in ecdsa:

https://git.libssh.org/projects/libssh.git/tree/doc/curve255...

[brnt]

Remember that Github U2F key 6 years ago? It just supports the ecdsa keys... I feel a tiny bit grumpy that it took 6 years for me to be actually be able to use the thing for anything important and then to discover it's already outdated.

I hope many services will support them nonetheless.

[comboy]

What problem are you trying to solve? Yes you can get one for $10 instead of yubico's $20, but yubico's have been researched the most and importantly they are very reliable. Many people successfully abuse them and while you always should add a pair of them giving you a backup, it would be a pain if it would stop working.

I'm asking because I'm curious about use case where you think you need them (even a bunch), but you think they are too expensive compared to value which you are trying to protect.

Reliability would be a good enough reason to me even ignoring all security aspects.

[michaelt]

1. Decide that USB C is a must-have feature. No $25 blue yubikey for you - prices now start at $50.

2. Decide you want two keys per user, in case they lose one.

Now you're looking at spending $100+ per person.

[Aeolun]

Is that an unreasonable expense for something like two factor SSH auth?

[selfhoster11]

Most definitely. Not all people are made of money. $100 can buy a lot of things, so if I can't justify it for professional use, there's not much of an incentive to spend that much.

[Dylan16807]

Yes.

And using a key like this isn't even two factor.

[ptman]

https://solokeys.com/ ?

[skynet-9000]

$25 USB-C: https://solokeys.com/products/solo-usb-c?variant=23528357560... For those not familiar, solokeys was an open source project that became a company via kickstarter (and now indiegogo)

[spicybright]

Assuming this is a business, you're already spending thousands per machine per user.

And a developer that's down for half a day from a failed key is way more expensive than that $10 of savings.

[selfhoster11]

If I'm getting a physical security key, I might as well pick something that has rudimentary PGP support. The cheapest Yubikeys do not, and the ones further up the range that do support it, are definitely outside the impulse/curious buy range.

[baybal2]

Smartcards cost less than a dollar, and are omnipresent.

I think you can already integrate PCSC with openssh.

A good thing about smartcards is that ones compatible with CSP are driverless, and PnP in Windows. This means they can enjoy at least some semblance of keylogger protection for key password/pin with WinCAPI.

[VortexDream]

Got any links about how to use a smartcard?

[xaduha]

If you're interested in contactless cards with an option in the future to upgrade to something like Omni ring (https://store.nfcring.com/products/omni) or to use them with your phone, then do this:

1) Buy a contactless card reader from a good source e.g. https://www.javacardsdk.com/product/acr1252u or last two from this table https://webshop.d-logic.net/nfc-rfid-device-comparison, don't buy NFC ones, you need smartcard support specifically.

Also steer clear of cheep ACR122U readers from ebay or ali, for some reason there are a lot of fakes https://www.acs.com.hk/en/press-release/2266/advanced-card-s...

2) Buy a few contactless javacards e.g. https://www.javacardsdk.com/product/j3h145/, don't buy EMV ones unless you're Europay, Mastercard or VISA.

3) Once you get them install opensc, pcsc-lite, ccid and get gp.jar from https://javacard.pro/globalplatform/ and read some pages from https://github.com/philipWendland/IsoApplet/wiki, it will get you started.

[rkeene2]

Step 1 is to buy a reader, any reader which is ISO 7816 compliant is fine.

Next, buy a smart card. The most famous brand I can think of right now is Gemalto, but there are lots of options. You can buy them in quantities of 1 extremely cheaply from AliExpress, but I'm not sure of the quality.

Smartcards are just little computers which run Java Applets (GlobalCard), and they come either blank or with software already loaded on them.

If they are blank you have to load software onto them. One open source option is CoolKey.

In either case you will need software on your computer to talk to the software on the card to ask it to do things, like sign an arbitrary piece of data. This software is called middleware (the stack looks like Application -> Middleware -> PC/SC subsystem -> smartcard reader driver (usually CCID compliant) -> smartcard software, so why it's called middleware I don't know).

For Windows, I only know for sure that PIV (US Government, NIST SP 800-73) card applets are supported, but there is a whole "minidriver" thing. I suspect you'll have to read the applet (or card, if preloaded) documentation to know for sure. macOS used to have a cryptographic layer called tokend, but it's deprecated and replaced with something else. For other things, PKCS#11 is the standard mechanism for talking to the card's application.

Feel free to reach out with further questions.

[baybal2]

Excellent write up on howto. A note from me, Windows also supports GIDS smartcards since a while too. Which means that Google titan key (Feitian ePass FIDO-NFC) will also work now (both as as smartcard, and a fido key.)

[baybal2]

https://www.rcdevs.com/docs/howtos/epass/epass/

This is a howto for USB key, a smartcard will be basically the same except you will program the card at first as the seller instructs you, or just enter the pin if they are already initialised.

[madjam002]

A lot of smartcards won’t support FIDO2 though which the web is using going forward.

[xaduha]

It will support whatever you install on it, there are some U2F applets and some stalled work on FIDO ones last I checked. All the necessary tech is there, the issue is with browser support. Google has this https://chrome.google.com/webstore/detail/smart-card-connect..., but it's Chrome OS only.

[baybal2]

It's fairer to say it's going sideways, not forward with them.

FIDO is not a replacement for smartcards, nor a complement to smartcards. Fido is "Just better than passwords" level of authentication.

The golden standard for HTTPS security, two side mutual auth with public keys on TLS level for example is only there with smartcards.

[tialaramex]

Doing mutual auth is great security but it has a horrible privacy story. Advertisers would, I'm sure, love knowing that this visitor to PornHub's custard pie fight section is the exact same person who bought the book "In Praise of the Klan" on Amazon and the one who bought take-out from a Chinese in Denver last Thursday. The clever thing about say WebAuthn is that you get an excellent privacy story to go with your security. Even if PornHub, Amazon and that Chinese place all conspire against you, with the advertisers, they don't end up learning if you're the same person even though you used the same Security Key all over the place.

[md_]

Please. We prefer it be called the Hoboken squat cobbler.

[tialaramex]

Yes, but, it's very unlikely that these reasons outweigh the benefits for you from having a Security Key.

* Cheaper devices may not support cool new features. For example FIDO 2 allows resident credentials †. The cheapest behaviour for SSH is that your laptop (or whatever) stores some data, and you need that data plus the Security Key to authenticate to GitHub but with resident credentials that extra data can live on the USB Security Key and so that's a huge benefit if you git push from random PCs. There are several features like this - for example one way to replace that boot-up password on encrypted disks uses another optional feature of Security Keys - and there may be more in the future, the cheapest devices only have the core feature. But hey, if you discover you want those features you can always buy a fancier device later.

* The cryptographic Quality of Implementation can matter. What we see today is some corner cutting maybe, some lack of polish, but nothing that seems like a plausible avenue of attack. But I haven't purchased every supposed different brand of Security Key, maybe some of them are quite awful. It seems likely that unless they're intentionally made to weaken your security they will always be much better than stuff like SMS 2FA.

Here's a rather old post by Adam Langley about the crypto problems he found in various Security Keys:

https://www.imperialviolet.org/2017/10/08/securitykeytest.ht...

* The physical QoI can really vary. If you're buying the cheapest you can find, maybe the touch sensor or button wears out much faster than expected, or the USB connector is a tighter fit than you'd like. Or maybe not. Your mileage may vary a lot. I own a device with a ludicrously bright LED when its powered up, not just when authenticating, always if it has power. Doesn't bother me, but a lot of people would hate that.

† Essentially without resident credentials the device has no "memory" of who you are. On web sites the natural back-and-forth makes this feel normal. You tell the site your email address or username, it finds one or more IDs in its database and asks your Security Key to authenticate with one of those IDs, the Security Key recognises an ID and does so. But a cheap Security Key can't remember that ID, it just knows (because of Authenticated Encryption if you care about the technical details) when it sees one it can authenticate. With SSH the protocol is designed differently, the remote site doesn't get an opportunity to store an ID and then ask your Security Key to authenticate, so that ID needs to live in a local disk file, unless you have resident credentials.

[Dylan16807]

> With SSH the protocol is designed differently, the remote site doesn't get an opportunity to store an ID and then ask your Security Key to authenticate

Why not?

Being able to work around a gap/flaw in the authentication protocol is nice but I definitely wouldn't call that "cool".

Also a yubikey being able to hold 25 of those is kind of pathetic.

[tialaramex]

Why not, as in, why was the SSH standard, finished in 2006, not prepared for the way we'd prefer to authenticate in 2021? Because of time's arrow, locally stuff happens in order.

I was actually impressed that the OpenSSH team figured out a way to make this work at all without adding an entirely new mechanism to SSH which would then have taken ages to propagate out into the world and doubtless been the source of weird problems with poorly made proprietary SSH servers for many years after that. If you go back far enough in HN there's a comment where I supposed that couldn't be done.

[lxgr]

> I was actually impressed that the OpenSSH team figured out a way to make this work at all without adding an entirely new mechanism to SSH

This is what they did, though: FIDO2 requires client and server support for the new "-sk" key types, since FIDO2 requires a very specific challenge/response format and does not just allow signing arbitrary hashes.

The older way of supporting SSH keys in security keys is through GPGs "smartcard" support, which requires using gpg-agent as an SSH agent and a security key that can speak CCID (i.e. pose as a smartcard reader with a permanently inserted smartcard over USB). That's what Yubikeys do, among others.

[tialaramex]

No, they just added a handful of new public key types, that's not even as invasive as adding a new authentication method to SSH.

For example, if your client knows some new FIDO backed credentials and is wondering if the proprietary ten year old SFTP server you're connecting to will trust them (it won't) it does exactly the same type of thing it did for other new OpenSSH key types, such as Ed25519. The server doesn't recognise these new types, just as it didn't recognise Ed25519 and no new exciting problems are discovered even though the people who wrote that server only read half of RFC 4252 while squinting and it only actually does RSA and password authentication and gets both of these wrong.

If they'd added a new method to support this, let's call it "securitykey" chances are that crappy server blows up whenever you just mention that you've heard of this "securitykey" method that was not explicitly listed in the document the programmers half-skimmed. Yes I have seen real SSH servers that behave this way, it isn't pretty and good luck getting somebody who has chosen to spend money on a bad proprietary SSH server to replace it with something that's not garbage.

And that still wouldn't enable them to sidestep the residential credential problem. To do so I think they'd need to reach down into the protocol layer and add another message, which again, it'd likely be compatible with all the competent SSH implementations on your preferred Free Software platform, but undoubtedly break the expensive half-arsed solution somebody spent $5000 on.

Also, if you do build that you run into another problem, even in a shiny Free Software environment, where do these IDs the server is now responsible for live? Is the SSH server now writing to files in the home directories of users it is authenticating? That sounds like a recipe for exciting new security bugs, not what we wanted.

[Dylan16807]

> To do so I think they'd need to reach down into the protocol layer and add another message, which again, it'd likely be compatible with all the competent SSH implementations on your preferred Free Software platform, but undoubtedly break the expensive half-arsed solution somebody spent $5000 on.

The message wouldn't show up unless the server offers this new key type, would it?

> Also, if you do build that you run into another problem, even in a shiny Free Software environment, where do these IDs the server is now responsible for live? Is the SSH server now writing to files in the home directories of users it is authenticating? That sounds like a recipe for exciting new security bugs, not what we wanted.

It's not the job of the SSH server to write to authorized_keys, so it's not the job of the SSH server to write these blobs either.

[lxgr]

So you're saying that buggy SSH servers are much more likely to blow up when encountering new methods rather than new key types? That's interesting (and I don't doubt it, although I fortunately haven't had to work with non-OpenSSH servers much).

[Dylan16807]

They could have added a new optional mechanism. I'm asking about github's servers specifically, not the long tail rest of the world.

Also, wait, if github isn't doing custom things on their end, how are they enforcing this rule that you need to tap once per connection?

[lxgr]

The touch/no-touch requirement is controlled by the server (or in FIDO2 terminology, the "relying party").

OpenSSH exposes this as a new sshd option called "no-touch-required", which Github probably just does not set.

[tialaramex]

Specifically, Security Keys sign a blob of data to authenticate. Most of that blob is nonsense to the Security Key. It might mean something to a big complicated web browser or your SSH client, but not the simple, and thus hopefully secure, Security Key.

But, there's a field of bitflags. The Security Key knows what those mean. One of those bitflags is "User Present" or UP, which means, "I promise I have some means to verify a human interacted with me and they did".

For U2F and WebAuthn UP is just mandatory. So, most devices you will find just always set UP, even if the Relying Party doesn't ask them to. However some devices you could choose not to ask for UP, and a device could in this case just skip the touch step, but it must not sign a message with that UP bitflag set in this case.

Some of the flags are currently unused, one that's also interesting for SSH in some environments is UV, "User Verified" which means the device claims to have some way to know if this is its real owner or just a toddler clicking the button. UV is typically set for fingerprint readers, facial recognition, or the cheapest option, a Yubikey with a PIN can set UV if you entered your PIN.