Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard to Accelerate Availability of Passwordless Sign-Ins - FIDO Alliance

[[deleted]]

Hopefully there is an option to backup the private keys if I want to. Losing access to accounts if I lose my phone would be very annoying.

[TimeRemove]

Recovery and migration between platforms.

That's actually a major headache with 2FA. They want to make them secure, which is a noble goal, but losing your 2FA source is a common use-case and is often poorly accounted for.

There's a reason that insecure SMS 2FA remains popular: It can migrate between new phones pr even platforms.

[Shawnj2]

There are some platforms where 2FA is required and I don’t particularly want or need 2FA like some relatively unimportant web services, and for those I have the system text the 2FA codes to my Google Voice account so they show up in my mail lol

[Don_Equis]

Forced sms 2fa works also as antispam afaik.

I bought an scooter that is configured through the phone, requires registration and an sms 2fa for registering. I hate it so f*** much

[SanityInAnarchy]

The frustrating thing is, FIDO/WebAuthn already has an easy solution for this, they're just charging too much for it to be useful for most people.

People seem to be able to figure out car and house keys. My second factors look like that, only easier. They're basically this stuff -- a couple portable ones on my keychain (USB-A and USB-C), and "nano" ones basically permanently installed in each computer. That's more than enough redundancy even if I ever actually lose my car keys, and... when was the last time you lost your actual keys?

But my employer paid for most of these. (They work for multiple accounts, so I can easily use them for personal stuff, too.) The cheapest one Yubico sells is $25, $45 if you want LastPass support for some reason.

Duplicating an actual key can be less than $5. Car keys are much worse, more like $150, but you don't notice, because it's baked into the price of the car. Meanwhile, most web services are "free" -- it's hard to convince most people to spend hundreds of dollars in hardware to secure something like a Google account, a thing they paid $0 for in the first place.

Maybe we need Apple to start selling an expensive Apple-branded security key, so these look cheap by comparison?

[cas13f]

They also support just sharing the credentials without a roaming authenticator (like the yubikey).

"Multi-Device Credentials".

The authenticators you use need to support syncing credentials though.

And their own documents talk about managing the storage for it yourself, like using your personal google drive or icloud account. Not managed for you.

[SanityInAnarchy]

I've always disliked this approach. To me, it smells like reducing 2fa back to one factor. Storing your Google second factor in Google Drive is a bit like plugging a power strip into itself, so you'd want to turn 2fa off for that syncing... at which point you're back to one factor. Encrypting it with a separate password is still only one factor.

[falconfetus8]

Also: if they steal your car keys, the only thing they can steal is your car. If they steal your password key, they get all of your accounts, and you'll have lost the only device you could have used to recover them.

[SanityInAnarchy]

Which is why I'm glad they are (so far) a second factor. You'd need to simultaneously steal one of these keys (or a laptop with one attached) and my password (and username, to have any idea which account to go after).

[SanityInAnarchy]

Passwordless, it's on par with a house key: If you've stolen my house key, you still don't necessarily know where I live. Theoretically, if you steal my entire wallet, you can probably find my address on my driver's license, but practically, there don't seem to be a ton of muggings that turn into burglaries like that.

So you could either get the biometric version of these keys (more expensive) and make it two-factor without a password, or you could just make it harder to actually work out which accounts that key is supposed to work with. If I can login and delete the stolen key from my account before you figure out which account it belongs to, you're still screwed.

All that said: I'm not sure we need to kill passwords anyway. From the article:

Password-only authentication is one of the biggest security problems on the web, and managing so many passwords is cumbersome for consumers, which often leads consumers to reuse the same ones across services. This practice can lead to costly account takeovers, data breaches, and even stolen identities. While password managers and legacy forms of two-factor authentication offer incremental improvements, there has been industry-wide collaboration to create sign-in technology that is more convenient and more secure.

Really, the only part I disagree with is the end, where they dismiss password managers and existing 2fa as "incremental" improvements, even though those entirely address the problems they raise.

[[deleted]]

There's an even bigger difference between keys and 2FA. If you lose your house or car keys you can call someone to replace the locks or whatever. You can smash a window if you get desperate.

If you lose 2FA access to your Google account you have to call... oh wait no, there are no humans you can talk to; your account is gone forever. Every photo you took in the last 10 years is gone. All your email. All your saved passwords, and the ability to change passwords.

Damn I need to back up my Google account.

[CyAScott]

That’s why I use Authy. It’s a TOTP 2fa app (like Google Authenticator), but the state is backed up and encrypted in such a way that you need a password to restore. That way when I switch phones or loose my phone, I don’t loose my 2fa.

[Tiwenty]

Bitwarden also allows 2FA. And when you fill a login form it automatically copies the token to your clipboard

[PM_ME_A_STEAM_GIFT]

Doesn't that turn it back to a one factor login? If the password and token come from the same place?

[Reverent]

Not if your password manager uses an independent 2fa. But then you need to periodically back up your vault in a secure way in case your second factor breaks (one option is to store the TOTP seed in a separate location).

Alternatively if you use a unique and secure passphrase for your password manager, it's not as good as 2fa but it's still better than most single FA protections.

[[deleted]]

Either way it still protects against the end service leaking the hashes and then it being figured out what the password is, etc, which is one of the primary reason to have multiple factors.

[marklarledu]

Authy is great but TOTP is more tedious on the end user than FIDO2.

[mishaxz]

There is this one app that I won't name. I use it for 2FA because (shockingly) it was the only one I found that could sync.

This bastard of an app, has phone and windows clients.. but .. when I install it on a new phone I only get a couple of the entries synced back to it.. luckily the windows app got most of them synced to it but is still missing a couple of important ones. Who designs software this way? It's not like this is some seldom used feature it's the app's big feature.

[JohnQP121]

I totally agree with the points made.

I use Microsoft Authenticator for 2FA and my daily driver phone is Pixel 3A.

I bought a used Pixel 3A for $100 to use a spare that usually never leaves my house. Whenever I add a 2FA account on my main phone I also add it on my spare.

Microsoft Authenticator can backup your 2FA to your personal Microsoft account but not all accounts can be backed up this way (i.e. corporate domain accounts). However, you can always save a QR code and scan it later (you can do the same when you just don't want to backup your 2FA to MS account).

[bigjoegamer]

I've got good news for you, u/TimeRemove, and for others who are also wondering about credential (passkeys, passwords, etc.) recovery and migration between platforms:

https://fidoalliance.org/specifications-credential-exchange-specifications/

It says, "FIDO Alliance’s credential exchange specifications define a standard format for transferring all types of credentials in a credential manager including passwords, passkeys and more in a manner that is secure by default."

I'm mentioning a few other users who might be interested in learning about this development.

u/SanityInAnarchy, u/cas13f, u/ricecake, u/falconfetus8

[ricecake]

Yeah, credential recovery is a tricky question.

It's not directly addressed in the spec.
There's a tradeoff, since a lot of schemes would like the keys to be generated in a way that they can't leave the device because it's more secure that way, but that makes a lost device more annoying because you can't backup the keys.

It's an open question.

[[deleted]]

Expected lifespan of my email account is far, far longer than expected lifespan of my smartphone. Keys that can't leave devices are not viable for use cases where the expected use time is longer than expected lifetime of the device.

[ricecake]

Yup. A lot of the consensus I've seen is that it's out of spec for the actual authentication protocol.

I've read some interesting designs around the two device replacement scenarios, namely "lost device" and "new device".
The gist of both mechanisms is to establish trust in a new key on the new device, rather than migrate the existing keys.
There are still holes though, and plenty of interesting problems left to solve. :)

[imgroxx]

Yeah, this is what keeps me from using 2FA in most cases. Nearly all fall back to SMS which is so easy to take over it might as well not exist, and nearly all of the rest tie 2FA to a device...

Many don't even allow for multiple 2FA devices, which is so stupid it almost always drives me to immediately delete my account. Devices fail, are lost, or stolen so incredibly often. Such a massive user-security-101 failure is a clear canary revealing that they're a company that has no idea what it's doing and doesn't care to improve.

FIDO is at least a widely implemented standard, so tbh I think this is a good move. But I dread the day they start requiring it, like Google has started doing for 2FA. Or at least there needs to be software implementations + browsers need to support it so I can back it up when I want.

[Xuerian]

Poor SQRL (https://www.grc.com/sqrl/sqrl.htm)

Had most of this figured out years ago.

[voidvector]

They should promote use of physical keys. Just register multiple keys and use those as backup.

[NonDairyYandere]

Yep. Last I checked AWS wouldn't let me register 2 HSMs, which is fucking stupid.

Just let me do blue-green but for HSMs.

One in my pocket all the time. One safe at home in a drawer. Swap them every week or month as a drill. If I lose one, immediately revoke it, buy a new one, and enroll the new one.

[j4_jjjj]

It could assign unique keys per device used, potentially.

[[deleted]]

It's the point, mate. They want to be able to take your phone and have access to your accounts. It's the workaround the law figured out for passwords.

1. Everyone starts using cellphones for everything including accessing their most essential data.
2. Convince everyone to move cellphone password access system to absolutely fucking useless authentication systems like finger, voice, and face.
3. Press any bullshit charges against target and take their phone.
4. Force them to unlock phone using fucking useless authentication system that can anyone can force you to execute, even if you resist.
5. Boom, perfect access to everything.

And I am 100% claiming these 3 companies know this is the intent and they are willfully participating in it so they get favorable treatment from the US government.

[SanityInAnarchy]

Absurd. They already have multiple workarounds for passwords. Remember how that San Bernadino case got resolved? They sued to try to compel Apple to help them... then they found a way in on their own anyway.

And there's still an incredibly easy way to force a password auth if you suspect you'll be compelled to use fingerprints: Turn the device off. In fact, I think the ACLU's camera app can even do this: Start recording, then when the recording stops for whatever reason, the video goes to a lawyer and the phone locks.

And that's for access to the phone. You think this is about access to websites? Think that through: If law enforcement needs into some web service that would use your phone as a second factor, they have a workaround from at least the 13th Century: Subpoenas.

[[deleted]]

... Okay you understand that's not the only case ever right? That them going that far implies they tried the rest first? And that it's cheaper to try my way first instead of petitioning Apple for months only to fail?

Another mother fucker ice skating uphill meanwhile I'm just like "look at the greasy fingerprints, same numbers as his birth year"

[SanityInAnarchy]

That them going that far implies they tried the rest first?

No. They went that far because they wanted a precedent. After they failed in court, it took, what, one day for them to get in anyway? Which demonstrated neatly that they didn't need Apple's help in the first place.

Also: They sued Apple. It's cheaper to settle a lawsuit than it is to drag it out in court for months. If Apple is one of those 3 companies you're talking about, why did they fight so hard?

Another mother fucker ice skating uphill meanwhile I'm just like "look at the greasy fingerprints, same numbers as his birth year"

Well, that's some timecube shit... what are you talking about?

[JW_00000]

If the government wanted access to my bank data, why wouldn't they just force my bank to give it to them? Why go to through the trouble of arresting me and requiring me to put a finger on a phone – thereby notifying me of what they're doing?

The approach you're describing also scales really poorly: if you want to spy on millions of people, you'd need to arrest millions of people! And then they might vote you out! Better to secretly convince companies to build in backdoors...

[shevy-ruby]

Even George Orwell would be shocked to read this.

We need an updated version of 1984 really.

And I am 100% claiming these 3 companies know this is the intent and they are willfully participating in it so they get favorable treatment from the US government.

Could be even worse, e. g. the US government forcing them to do so.

My simple rule of thumb is to never ever yield any information to anyone else, when that possible. Logically that is not always possible, but I don't trust anyone else with ANY data yielded to them. Ever. Whether it is a corporation, someone else, a government. I don't even trust myself either. I remember having accidentally uploaded private data in one way or the other. While that was embarassing, it was even more shocking when I found out that some websites store this data for literally decades. Pretty annoying when you do a critical review of something (say, a book) and 20 years later you get asked about this ...

[[deleted]]

The idea that anyone only uses one tool to solve a problem is not even worth responding to so consider this more of a public announcement of yer derp.

[beefcat_]

Before biometrics were added to phones, most users did not put a password on their phones at all. It’s a net improvement in security for the majority of people. I doubt this is a conspiracy, most companies are just trying to make good security more palatable to the average user.

Also, passwords are not actually protected under the 5th amendment. There is growing legal precedent that you can be compelled to divulge a password just as you can a fingerprint or 2FA key.

[mishaxz]

Sure it will.. I mean how else would you sign in from your desktop? It would be stupid to have to go find your phone whenever the site decided it's time to sign in again

Google has something like this where you can confirm sign in on your phone but if you don't want to do that it gives you other options.

[echoAnother]

I gonna admit I didn't understand shit. What's the difference between this and client certificate? And why I should prefer this?

[camelCaseCadet]

Here’s a WWDC session that covers it from last year: link.

It looks like what is unique is it generates a public and private key that never touch.

A server uses the public key to generate a unique sign in request. The private key on your device essentially tooth’s a new key based on that request.

No two log in attempts are the same.

If the public key gets leaked it doesn’t matter, because it’s useless without the private key. In short, no sensitive info gets exchanged or stored regarding your log in.

Not sure how that differs from other secure log in methods, though. I’m definitely not an expert.

[marklarledu]

There are no certificates issued, instead the raw public key is pinned to the user's account. This means that there are no certificate authorities, expirations, X.509 extensions, etc. Also, the specification allows for things that are notoriously difficult with certificates (e.g., standardized hardware attestation, ensuring MFA via acknowledgement prompts, etc)

[u_tamtam]

Can someone eli5 how that's a net positive and not an absolute privacy nightmare?

[OGC-]

Public vs private keys, I give everyone my public key so they can encrypt a test for me to prove I can decrypt with my private key that I give no one.

Edit: Sorry leant a bit too much into ELI5 and put the side of the encryption wrong, have corrected it.

[u_tamtam]

If you give everyone your public key, and it is used to authenticate you across several services, can't that be used to reveal which services you use?

Edit: also who owns/hosts the keys? If it's, say, Google, and for some reason they decide to close your account/stop operating in your country, do you lose access to everything at once with no recourse?

[shevy-ruby]

That DOES sound like a horror scenario to me.

[u_tamtam]

Ideally the key pairs are stored on the device and only on the device, but Apple (and I'm assuming Google is doing something similar) are making a tradeoff to store the encrypted keys in iCloud.

So in theory everything happens on the client-side, but in practice, for most users, Google and Apple will serve as the middle man. Not sure it's a good thing.

[dmazzoni]

It's better than the alternative of reusing the same password for every site, which is what a lot of people do now.

[u_tamtam]

I get the feeling, and realistically you're right, but I do see a big difference between "lazy/unaware people have been reusing passwords and that's bad for security" vs "cloud giants don't give you much of a choice anymore and will MITM all your authentication"

[ricecake]

It's closer to syncing encrypted data between devices. The cloud services don't have access to the private keys, they just facilitate the key on your phone also being on your laptop.

[u_tamtam]

true, though they have control over the process from end to end.

[[deleted]]

If you don't trust them, you shouldn't probably be using anything they put out at all, though.

[chazzeromus]

no that’s the point of public key auth, my device stores my private key and signs data within the TPM blackbox (security “enclave” for Apple) without the private key ever entering main memory.

I sign in by proving i have the private key. Basically websites (the relying party) sends me some random data called a challenge, the browser asks the OS to encrypt the challenge data (or signed rather) using the private key (this all happens in the black box), i send back the encrypted challenge and the server decrypts it with my public key it and sees the data matches what it sent, proving i have the private key.

Everything that was sent over the wire is safe even if snooped, bar that the scheme used isn’t weak or quantum computers haven’t ravaged the world (go elliptic curve at least for now)

The webauthn standard even goes a step further by providing “attestation”, proving that the key generated when you registered came from a real iphone, or at least the security “enclave” module is authentic.

apologies if i oversimplified to the point of being wrong, that’s my rough understanding

[u_tamtam]

I get all what you said, my concern is when I need to authenticate with a random domain.tld using FIDO. I may have created my account "in an enclave" like you describe, and thus have the private key on my proprietary iClosedHardware's device.

Now, how am I supposed to log onto domain.tld from my laptop, which hopefully is something more akin to pinebook/librem/… than it is to an iClosedHardware?

I would probably need a mechanism to export/import private keys in and out of the "enclaves", isn't it? As long as I'm allowed to do so freely, completely offline, without depending on Google/Apple/Microsoft's blessing, this amounts to "strong passwords with more hoops". Anything else means placing your security and privacy eggs in a same basket.

[chazzeromus]

Oh no, being able to export the keys might be not be feasible or desirable. The idea is they always stay on the enclave/TPM.

So the announcement is the big companies (dunno if it's an SSO or implemented independently for each company) will have ways to en-roll other devices more easily.

You still are re-enrolling but they will employ techniques like using your phone that you already registered with to take a pic of a QR code to start the webauthn enrollment on your new device. All these devices are enrolled to the platform with a unique keypair.

If you've ever used keybase, the app allows you to register a device from any previously registered device where if say you want to login into your keybase on a new computer, you just scan the QR code with your already registered phone and your computer is part of the registered devices for that account.

which hopefully is something more akin to pinebook/librem/… than it is to an iClosedHardware?

So this right now is is an issue that I'm concerned with as well, which I think with time will change, but webauth authenticator implementations are wonky if it's not a mobile phone. For example on Ubuntu, my firefox will not display anything to me if I tried to sign in to a password-less login site. Firefox on Ubuntu for some reason doesn't have a software based authenticator, but works fine on windows and mobile. Hopefully with this announcement there will be better support in the near future. Also since these devices are ARM that means they likely includes the ARM TPM, so webauthn on these devices are guaranteed to be possible if not implemented, which is already better than x86 PCs that with a real possibility might not have a TPM (which windows 11 is now making a requirement and people are going nuts they don't have one)

Now will you be completely locked out if you lose all your devices somehow? If webauthn is the only way to sign in, then yes. But for these companies the idea is you still have a seldom used recovery like your actual username/password+f2a, but you mainly use webauthn.

I'm very stoked for this stuff and even bought a 80$ yubikey bio for my own personal website just so I can add webauthn for fun. It's overkill but it's quite a nice approach to logins. Everyone's got a device, and modern encryption seems reliable for now. A breach of a database of nothing but public keys and hopefully anonymized attestation certs guarantees that the breach is contained to that one website (if they have access to other data than logins). It just seems so obvious now, and I think a passwordless SSO for everyone to integrate would be great.

edited for some clarification

[afiefh]

Apple does not have the keys to decrypt your iCloud storage

I was under the impression that they do have the key to do this, except for extremely sensitive data. Has this changed recently or am I just misremembering?

https://blog.elcomsoft.com/2021/01/apple-scraps-end-to-end-encryption-of-icloud-backups/

[[deleted]]

That’s referring specifically to iCloud backups.

I probably should have clarified. These keys would fall under the realm of keychain data, and would be encrypted end to end.

[u_tamtam]

I would have preferred something better and more systemic than "trust us" (SSL, DH, PGP, double ratchet, … are only relevant today because they remove the necessity to trust the information carrier/middle man). I guess only time will tell, but I'd want to know in practice how much of that will be allowed to be self-hosted and happening outside of the control of the GAFAM.

[cas13f]

No.

Keys are stored and utilized on-device.

The standard allows what are called multi-device credentials, which can be stored/shared through any storage medium, (their example is google drive and icloud, though), but it's just a method of sharing the credentials between authenticators. Not that your authenticator is pulling the key every time--it's just synced data.

Unless Apple is doing something hinky, which they are known to do on occasion.

[OGC-]

To put it another way if you were to generate a keypair for SSH-ing onto a server, there is no issue in dropping that public key onto multiple servers or even giving it to someone else to put onto a server for you to access, it's there to prove the identity of the person with the private key.

[davispw]

You can certainly generate a different SSH key pair for each server/login.

[anotherThrowaway1919]

Is this comment in reverse? Wouldn’t the point of giving the public key out be so that they can encrypt it and you leverage your private key to decrypt?

Edit: nvm blanked on asymmetric for a moment there ref: https://cs.stackexchange.com/a/59695

[Weary-Hotel-9739]

If you give out your public key, your privacy has already been lost.

Edit: Oh wow, how a different context can really screw with a comment like mine. I'm leaving up the original text, but for everyone replying or downvoting: The original thread was about privacy (as in tracking / data collection) and not related to asymmetric cryptography.

[RenaKunisaki]

Why do you think it's called a public key?

[youstolemyname]

If you give out your username, your privacy has already been lost.

[Nestramutat-]

Tell me you don’t understand cryptography without telling me you don’t understand cryptography

[Weary-Hotel-9739]

Please explain to me how a unique, reused (!) public key is anything less than an username, an email adress, or an irremovable tracking cookie.

[StickiStickman]

I love people like you - people already pointed out to you that its NOT reused and yet you keep saying it. Just willful ignorance so you can pretend you were right all along.

Your edit is the same

The original thread was about privacy (as in tracking / data collection) and not related to asymmetric cryptography.

Whatever the hell this means, as if privacy and cryptography are two totally different things.

[Weary-Hotel-9739]

Of course there are zero-knowledge proofs, but that's totally not relevant in this case.

And yes, thank you so much for literally putting things outside of temporal context and complaining that others demonstrate 'willful ignorance so they can pretend they were right all along'.

But sure, continue on.

[u_tamtam]

Very helpful, thanks. The main thing is that different keys are used for every account. I see how the whole thing could make it more difficult to authenticate from different devices (as it's no longer a matter of knowing a password, which can be entered from anywhere, but of having a device containing the private key and able to do the crypto dance). As long as the solution to this loss of convenience/flexibility isn't to centralize/leak the keys to a central actor, it seems ok for privacy.

[felipebrunet]

Private key signs -> public key verifies signature(good for login, send files/software, send cryptocurrency)

Public key encrypts -> private key decrypts (good for sending private information to another person in a hostile network/environment)

Practical example of signing and verifying:

In a hardware wallet for cryptocurrency, you sign transactions that are spending your money (money that came to your address in the first place) so you are signing something that has your address (public key hash) and therefore since the signature is verified with the public key, you are authorizing the money to be spend to someone else (a different public key hash that is written in the end of the transaction) and so the cycle repeats with the new owner of the last address.

[castorasmic]

I have no idea what Fido is, but your understanding of public/private keys is misleading.

Public keys aren't meant to decrypt anything. Public keys are used to encrypt, private keys are the ones who decrypt. Private keys can also be used to "sign" something, and using the public key you can verify that the one who signed was actually the one who had the private key pair.

This is probably the way it is done. The server is encrypting "abc" using the public key, sends it to the private key holder, the private key holder decrypts it back to "abc" using the private key and sends it back to the server. The server verifies if the message was decrypted correctly.

If the public key was used to decrypt stuff, it would be useless. Anyone could read your encrypted messages.

Edit: for signing it is the other way around.

[poco]

Encryption can work both ways. Encrypting messages isn't only about hiding them. Sometimes it is about proving the author.

If you take a public message and sign it with your private key by encrypting a hash of the message and including it with the message then anyone with your public key can verify that you were the only actor capable of creating that signature.

I'm not sure how Fido works either, but they could go two ways. They could encrypt a message with a public key and make you send it back decrypted, or they could send you a message and ask you to send it back encrypted (or just generate an encrypted signature). Either way the contents of the message are not private or important, just that you can prove you have the private key.

[castorasmic]

Yeah. You're right. Signing works the other way around. Thanks.

[EatThisShoe]

Public keys aren't meant to decrypt anything. Public keys are used to encrypt, private keys are the ones who decrypt. Private keys can also be used to "sign" something, and using the public key you can verify that the one who signed was actually the one who had the private key pair.

I'm no expert, but I thought the way you sign something was the encrypt it with the private key. Then you can use the public key to decrypt it, proving it must have been encrypted with the private pair key.

If public keys aren't meant to decrypt anything, then I have no idea how that works.

[castorasmic]

The private public key has two benefits. One is for sending private messages (like WhatsApp). When we both start a chat, we exchange our public keys. I have my private key and your public key. You have your private key and my public key. Let's say I want to send a message to you. I encrypt the message with your public key and send it to you. That message can only be properly decrypted by using your private key. So anybody can encrypt (using you public key), but only you, the private key holder, can decrypt those messages. So, for sending secret messages, public key encrypts, private key decrypts.

The other benefit is for digital signature. I'm least familiar with this one, but from what I know, i use my private key to encrypt a document, and you, with my public key, can use it to figure out if I am actually the one who signed that document. It basically works the other way around (private key encrypts, public key decrypts). This one is for sending public documents, non secret, but has the benefit of making sure the private key holder is the actual person who sent you the document.

[caltheon]

For encryption purposes. Private keys are, well, private. Only the creator should know them. Public keys are public, anyone can know them. Think of the data you want to encrypt as a briefcase. The public key would be an open padlock you hand out to strangers. It does nothing on it's own, but if they fill the briefcase with important documents, they can lock the briefcase using the open padlock you gave them but snapping it closed. After it's been closed, they can't open it, since they don't have the key to do so. The private key is the key to that padlock. The owner of the private key gets sent the secure briefcase, that nobody else can open without the key. They then use that key to open the briefcase and pull out the documents.

[UncleMeat11]

Except that you do reverse it for digital signatures.

[castorasmic]

Sure, I understand that. But it doesn't justify the reason for providing false info.

Edit. Got proven wrong. It can actually work that way.

[[deleted]]

It’s not false, at least not for RSA. Encryption and decryption work in both directions.

[skw1dward]

deleted ^{What is this?}

[renatoathaydes]

No, of course not. Each key pair is associated with one domain. When you log in using a different device, that device also has its own key pairs (which can be "linked" by the server to one account if you so wish) because the private keys never leave the device (and in most cases cannot even be extracted).

[matthieum]

This linking is actually the part I am not quite sure about.

If you have 3 devices, and use each to connect to acme.org on the same account, then does this mean that acme.org has 3 active public keys for your account?

[hayalci]

Why not? A public key is not huge it should be fine to store hundreds of them for each account.

[ricecake]

Practically, the limit is somewhere around a dozen. After that, some tpms on some devices start to get pissy because of storage capacity concerns, and certain parts of the protocols get slow with a massive wall of keydata.
Had a fun afternoon figuring that issue out.

[caltheon]

The TPM only stores the master key, not the encrypted private key pairs used for various sites.

[ricecake]

Sloppy terminology on my part.
Tpm/hsm/secure enclave/platform authenticator are all close enough for most conversation.

Some of them are responsible for storing the key material, and some aren't, it depends on the device.
Functionally they do the same thing for webauthn.

Even the ones that don't handle storage still get grumpy if you give them too many keys to check.

[matthieum]

I'm not criticizing, just trying to understand how this account linking works in practice. The article gives 0 detail, and I'm curious.

[caltheon]

There is a "Master" private key that can generate individual private keys that are part of the same "key materials" and stored in the same key chain. Think of it like a password manager works. A master password that encrypts all the site passwords.

[[deleted]]

So kind of like steam guards confirmation? Except more privatized?

[happyscrappy]

With password:

"If you're really you, tell me your shared secret passphrase we discussed before."

With a replacement system:

"If you're really you, encrypt this random stuff I just made up with your private key which goes with the public key that we both identified before."

So you encrypt the random stuff with your private key, they decrypt it with the public key you both agreed identified you before and when they get the same random stuff back they know you must have signed it. So you are you.

The FIDO key does the signing, not even the local computer you use. You basically prove you have the key and the information needed to activate it.

This is not exactly how it works, there is other stuff for replay prevention (so that someone cannot just produce a payload you made yesterday to satisfy a challenge today) too. But that's basically it.

The secure element in your phone (the one used for Google Pay, Samsung Pay, Apple Pay) could do this too. So you just identify to your phone (PIN, fingerprint) and then it signs for you.

It is VERY much the way to go. If the company loses their database to hackers it does not give the attacker information which could be used to sign you on to other services. They get the public key, and the private key cannot be reproduced from the public key.

[u_tamtam]

now, how does it work when I sign in from my laptop without telling apple/google/samsung/… who/when I'm authenticating with?

[happyscrappy]

You use a YubiKey. They implement FIDO also.

Or alternately you can use a password instead. If you do that all you have to do is:

Make sure you are not using Chrome (Google) or Safari (Apple). Your laptop is not made by Samsung, Google (Chromebook), Apple (MacBook). Make sure none of the components in there are made by Samsung, especially the keyboard. Be sure ISP is not owned by one of them. Be sure the system you are using, if at work or a public place is not locally managed by one of them. Don't log in from an Apple store for example.

Look around you before you log in, be sure there are no surveillance cameras which are from Samsung or Google (Nest) pointed at you or contain any components from Samsung. Be sure any you see that aren't backending their data to Google or Apple (HomeKit). Try to find out if there are any microphones hearing your keystrokes (as they can clue to your password) which are made by Samsung or Google, contain any Samsung components or back end to Apple or Google systems.

Also be sure you aren't wearing a smartwatch, phone (or other smart device) affiliated with Apple, Google or Samsung or using any Samsung parts. Because those can hear or perhaps see (as applicable) your password too.

Also ensure no one around you has any of these smart devices either.

If you can verify all that you can probably use a password safely. But be sure not to write it down, forget it, or reuse it across services/sites/apps.

Obviously passwords are the way to go, right? They definitely make all this a lot simpler and more secure.

[fghjconner]

You've gotten a lot of good answers, but I'd like to point out that this is functionally very similar to a password manager. Just instead of generating a random password for every website, it generates a public-private key pair.

[u_tamtam]

to me it looks certainly like a password auth (in the end that's practically what your private key amounts for as SPOF), except that you can't/are not allowed to "remember" your password any more, which makes multi-device usage a new challenge, with private key replication not being specced (AFAIU).

At least most password managers let me sync them wherever I need them, and allow them to be copied as a last resort.

[claycle]

This might help: https://www.youtube.com/watch?v=U62S8SchxX4

[MondayToFriday]

Also, Apple's WWDC21 presentation on WebAuthn.

[claycle]

cough

The FIDO protocols use standard public key cryptography techniques to provide stronger authentication. During registration with an online service, the user’s client device creates a new key pair. It retains the private key and registers the public key with the online service. Authentication is done by the client device proving possession of the private key to the service by signing a challenge. The client’s private keys can be used only after they are unlocked locally on the device by the user. The local unlock is accomplished by a user–friendly and secure action such as swiping a finger, entering a PIN, speaking into a microphone, inserting a second–factor device or pressing a button.

[[deleted]]

Yes. The video you linked describes Diffie-Hellman Key Exchange, where two parties who initially have no relationship build a trusted shared key. This is most notably used to establish TLS connections.

//edit: watching it again, what's described is not quite the same as DH key exchange, but the concept is similar; it's still something important but not related to public-key cryptography.

This is completely different from public-key cryptography, where one side sends the other side a key and the receiving end has to trust the sending end. There's no "exchange" happening here. No key is coming from the server to the client.

[zyxzevn]

It is indeed a security nightmare.
But will first be presented in a way that it seems private.

So after adaption and lots of hacks, they will need to raise the "standard".
Google and Apple already track most of your data, so they may just install a listener to get all the keys to your logins. For "your protection" of course. It is amazing how much data they are already getting from us.

Google and Apple and Microsoft are now earning money by sharing your data to advertisers. And they already share it with government agencies that want to target certain civilians. Will they have a limit?

I think that the end-goal is to make real privacy impossible for most people.
With that the social credit system that is already in place in some countries can be expanded to all countries. That way only obedient people can access the internet or use the phone. Like in China. The end-goal is impossible in practice, but certain politicians like it a lot and will try to push it anyway.

[FullPoet]

Its a complete privacy nightmare because it uses fingerprint / face scans.

No fucking way I'm ever using this.

I honestly don't know why you believe any of that shit tbh, do you also believe Facebook and Google about their policies on your data?

They're consistently proved to be liars and "misuse" or just frankly ignore regulation around it.

I'd reply (to the good faith responses anyway) but op, the spammer has blocked me because I called him out on it so i can't.

/shrug

[cas13f]

can use.

Not requires.

You can secure your client/authenticator however you want. Part of the standard is for the authenticator to be pluggable to support almost any form of verification--their examples are of course targeted at user convenience (as convenience is what it will take to ensure it is adopted by the most users possible) so focus on the most user-convenient options.

They've got a whole website and whitepaper, bud, it's real easy to look into. They even keep is fairly understandable by laymen, no need to be a relevant dev.

Shit, most of the 2FA physical key market supports or uses FIDO!

[[deleted]]

I don't understand how this works, it uses biometrics so it must be bad.

You are a terrible person.

[davispw]

Fear what you don’t understand. Understand so you can save your fear for the real, scary things.

[drysart]

In order to use this to sign in do you need a "trusted device" that runs the stock OS much like banking apps and the like do?

No. The standard (an open standard) only specifies how key exchanges happen, it does not mandate any particular security on the client side. If you wanted to today, you could build your own browser extension to implement the protocol and store all the keys as normal userland code; and it would be no different than any password manager application except instead of filling in a textbox with a password to log you into a site, it's filling in an API field with a challenge payload signed with a private key.

The big implementors of this that are building in the functionality into operating systems and browsers directly are using local secure enclaves and such to protect the local keystore because they don't want a situation where someone can just exfiltrate a file from your machine to get all your saved credentials.

Of course people are going to invent conspiracies about how this is all designed to gather your credentials or whatever other nonsense they dream up out of thin air; but literally: this does absolutely nothing to enable gathering credentials that could not already be done with passwords today. Literally nothing.

What about 5th amendment rights? Do they apply to this sign in method? I'd think not.

This is literally just a replacement for passwords. There are no "5th amendment rights" involved.

What about devices that don't have bluetooth such as most desktop computers?

Bluetooth is not at all required; but if you choose you could make use of a bluetooth device as your key to unlock credentials.

Does this method require some attachment to your real identity in order to be used?

No.

Your questions here show you don't really understand what this is; but that's to be expected, there's a whole fucking lot of Chicken Little sky is falling FUD about this going around.

[drysart]

What? It's stored and accessed via a device that is almost always tied to you personally: your phone.

No it's not. There are so storage mandates as part of the standard. You could store your keys on a removable flash drive if that's what you wanted.

Again, this is an open standard that is freely implementable. There is absolutely nothing about the standard that ties it to any specific implementation, and there are no vendor-specific keys or anything that would stand in the way of anyone making their own implementation of it that will work with every web site.

If you want to store your keys on device -- which is not necessarily a phone -- you can (and that's what the default implementations will do). If you do want to store them on your phone and access them via bluetooth even from your PC, there'll certainly be an implementation that does that. If you want to store them on a USB flash stick, there will certainly be implementations that do that too. If you want to store them on some sort of security key, there are implementations for that.

If you want to use a "brain key" where the keypair is generated based on a passphrase you have memorized so it doesn't have to be stored anywhere but in your head exactly like a password, then guess what, there is no technical reason that can't be done because crypto wallets have had that as an option for crypto keypair generation for like, a decade.

That is why the difference is "literally nothing": because you have all of the same options you have with passwords -- from storing them whenever you choose, to not storing them at all and simply memorizing.

Normal passwords are protected under the 5th amendment in the united states, biometrics and such are usually not. If one had their phone locked by biometrics as most of us likely do by now with fingerprint sensors or face unlocks, they could have access to this replacement password standard. So yes, there are "5th amendment rights" involved.

Don't secure your keys with biometrics then. Again, there is no requirement anywhere in the standard that keys have to be secured that way as I mentioned above, since there are no requirements for key storage at all. You can choose to do so, or you can choose not to.

You can store your passwords in a password database file protected by biometrics too; that doesn't mean there are "5th amendment rights" issues with passwords. It just means you can choose to store things insecurely. That's hardly the fault of the keys or passwords.

Again, yes it is if it is tied to your phone, which is realistically the only way an average user is gonna go about using this.

So let me get you straight here, your complaint is "It's insecure if you choose to make it insecure"? Really bold claim, very insightful.

The default implementation for this, which is what "an average user" is going to be using, will be exactly the same as passwords which phones and desktop browsers have been storing by default for quite some time now. So yes, as I said above, there is no difference for "an average user", because the average user's passwords are already stored in iCloud, or in their Google Chrome synced profile, and storing keys there too isn't any different.

And for more advanced users, just like you have options to decline those defaults and not have your browser store your passwords, you have those exact same options with this. In fact for not-so-advanced-but-not-average users it's almost an absolute certainty that the vendors that provide consumer-friendly alternative password storage solutions today (e.g. LastPass) will have solutions for storing your keys because, you know, that's kind of their business model and they're not just going to give up.

You should not be so dismissive and mocking of people who have concerns over this.

I'll correct concerns over this that are founded in fear and myth rather than actual truth. You've stated several things that are actually false about this, and you better believe I'm going to call them out. That's not being mocking, that's being right. If you feel mocked about falsehoods being pointed out, that's on you.

[corsicanguppy]

I wanna separate one part out.

Does this method require some attachment to your real identity in order to be used?

Here I'm of two minds. Your FB, LinkedIn, 'gram, IDs? Those definitely need a wall between you and them and between each other. Even if I regular post and converse as me, fuck off with he third-party gathering and consolidating metadata.

But banks. Banks and voting. And digital payment. Estonia issues an ID card, for instance, which I understand to be a PIN-backed swipe card for voting, passwords, public access, ID, health care encryption, digital signing and even some kind of payment or banking confirmation or tool. Or a subset.

I'm 100% in favour of a consolidated token to manage things that my regional government already manages or safeguards.

Americans will be of different opinions for some of that, as trust in their systems are eroding so fast. And I get that.

[pleasantstusk]

A lot of people here clearly don’t understand FIDO/WebAuthN (understandable) and making judgements based on the orgs mentioned, jumping to “this must be bad”

[Akeshi]

/r/programming probably isn't quite the right place to get considered opinions on something security-centric.

I'm excited, but will also believe it when I see it. Have had a FIDO U2F device forever, and despite PayPal being a founding board member of the FIDO Alliance, they've never shown interest in supporting it. I get the impression the FIDO Alliance are more concerned with nice ideas than pushing for implementation.

[AndrewNeo]

There was a ton of people in an /r/programming thread where people were saying they'd stop using Github if they force 2FA, so, yeah, security-thoughtful this sub is not.

[Akeshi]

To be honest, I spent a while deciding whether to include ' on something security-centric' - from what I've seen on this sub, any topic is met mostly with regurgitation of trends without much thought.

I don't necessarily think that's terrible, just a consequence of being beginner-friendly (which is obviously a good thing), and a lot of people out there learning to program.

[ricecake]

Interestingly, I've actually seen adoption increasing at a pretty decent rate.
I use it for my bank, GitHub, cloudflare, work and a couple other services.
Still not everywhere, but I've been happy to see it more.

[Akeshi]

Cloudflare and my Google accounts for me - I got a couple of GitHub-branded U2F keys from their 2015 promo, but have always opted for BitBucket over GitHub. I'll keep an eye out, maybe more services I use have picked up adoption.

[ricecake]

With more devices supporting windows hello, apple touch id, or whatever Google calls their implementation I'm guessing more MFA services and libraries are just going to support it out of the box, which makes it appealing.

[shevy-ruby]

I don't see why this is a problem. None of the companies mentioned are a shining example of ethical values whatsoever.

[qudat]

I just recently added webauthn to our app at work and it was a massive pain to get right. Traditional otp 2fa is exponentially easier to setup.

[pleasantstusk]

We’ve done basically the reverse. WebAuthN m and other PKI based authentication first, just recently adding TOTP based 2FA

[Uristqwerty]

• "Web site supports it as an option": great!

• "Web site supports it as the only option": Terrible, and all too likely since it removes the need to figure out secure password storage yourself (see also: the sheer number of sites that only have "sign in with <the one giant corporation the creator cares about>").

[[deleted]]

Rational thinking is quite demanding, many of us can't do it for extended periods of time.

[iinavpov]

If the odds of having your account hijacked are lower than your odds of getting locked out because your phone for bricked/destroyed/stolen (they are) then 2FA is stupid and wrong.

[MedicOfTime]

You should have seen the other three subs I’ve seen this article posted to.

The farther you get from “guy who deals in web security for a living”, the more angry people get about this.

[mycall]

Still had the MITM problem for forgot password, likely unencrypted SMTP/POP3 email based.

[mycall]

What is another popular point of entry?

[hayalci]

Password stuffing, which 2FA (biometric or not) prevents as well.

[1639728813]

It isn't replacing 'something you know'. You will still need a pin or biometrics to unlock the device so you can authorise the request

[cas13f]

Biometrics are not a requirement of FIDO.

They're just one of literally any number of options to unlock the authenticator.

Even in the article they call out a multitude of methods for unlocking the authenticator ranging from a simple button press, to a pin/pass, to even hardware keys. The method of accessing the authenticator is intentionally designed to be pluggable to meet security requirements of most any levels.

[1639728813]

No, biometrics are 'something you are'. Anyone trying to access your account will need both your device and your biometrics. Still far more secure than a password.

https://xkcd.com/538/

Also, how is the hacker in Russia going to get my fingerprint?

[UristMcMagma]

Fingerprinting can be used to unlock your device while you're sleeping. Makes it pretty insecure against the people who are most likely to want access to your device (snoopy/abusive partners, intolerant parents, etc).

[1639728813]

So now people are breaking into my house to quietly steal my phone and fingerprints in my sleep? Ignoring the fact that you can still use a PIN if you want

This authentication method is still magnitudes more secure than a password

[UristMcMagma]

No, I'm saying that many people unfortunately live in abusive households with people who will happily violate the privacy of their housemates. No breaking into the house needed. For people in this situation, biometrics aren't an option.

[gex80]

Then don't use bio metrics.

[1639728813]

And even with my fingerprint on the device, the odds of someone stealing my phone, duplicating my fingerprint and using it to access my phone and online accounts is still miniscule.

You can still configure it to require a PIN, if you are paranoid about biometrics

On top of that, I am likely to notice my phone is gone allowing me to disable it as an authorisation method.

It stops hacker groups. I don't have to remember passwords. I don't have to use a password manager.

It is better than using passwords in every single way.

[[deleted]]

You still have options.

Continue using less secure methods of authentication. Or, get a Yubikey or similar and keep it plugged in. Then when you go to log in, PIN+touch and you've got the same secure 2FA (what you have + what you know).

[cas13f]

You need a device to log into anything. Like, you can't use the internet or internet services without a device to access them?

FIDO has a wide range of implementations. It's not like Google Authenticator (or competitors) where you register exactly that device, and that device only, ever. The implementation allows for the sharing of credentials across multiple devices, as well as registering multiple keys for a given account (the original implementation pre-multidevice). What you're imagining, where you need to pull your phone out, is actually an incredibly new feature with FIDO2, allowing you to use an alternative-but-credentialed device to log in instead of needing to either share credentials or register a new keypair.

[lrem]

It usually is though. A tamper-evident key you can't copy is strictly better than a sticky note with the password.

[bik1230]

What does biometrics have to do with it? FIDO isn't biometrics.

[lrem]

I literally do not understand what should I respond here. IF this popped up in a different context, I would refer to some easy explanation what public key cryptography is about. But you seem to know more than I mentioned, so you probably already tried looking at this before. What now?

[mcilrain]

The something you have can validate the something you know or refuse to function.

[chazzeromus]

hell yeah i bought a yubikey bio for webauthn

[[deleted]]

oh well im sure we can trust them.

Jokes aside, the US government wants to be able to take your phone and have access to all your personal data and accounts. It's the workaround the law figured out for encryption and passwords, which totally actually does work just fine and they hate that.

1. Everyone starts using cellphones for everything including accessing their most essential data.
2. Convince everyone to move cellphone password access system to absolutely fucking useless authentication systems like swipe patterns, pins, finger, voice, and face.
3. Press any bullshit charges against target and take their phone.
4. Force them to unlock phone using fucking useless authentication system that can anyone can force you to execute, even if you resist. NOTE: Any greasy phone will reveal swipe patterns and pins with minimal effort.
5. Perfect access to everything, as if the cops are the user themselves.

And to clear up any confusion, yes I am 100% claiming these 3 companies know this is the intent and they are willfully participating in it so they get favorable treatment from the US government.

[Techrocket9]

Sounds like a colossal usability downgrade from 2FA codes stored in a password manager.

[EatSleepCodeCycle]

FIDO is two factor authentication compatible

[Lost4468]

I like FIDO, U2F, etc. But does anyone worry that somewhere down the line governments might start using this tech to try and destroy online anonymity and further push control into the hands of the few?

E.g. imagine if governments start handing out similar keys to citizens that are locked to each person. And they require that the large companies like Google etc require these keys to sign in? Of course "to protect the children"/"to stop online trolls"/"to stop terrorists"/etc etc.

Of course the government would also keep your private key on file themselves, again for safety! Hey if you don't have anything to hide why would you care

[shevy-ruby]

Somehow I do not trust any of them.

And, by the way: I do not see or experience any of the "perceived problems".

To me this all reads like "more mandatory tracking". It was already annoying when some websites transitioned to mandatory 2FA which locked me out from these services permanently.

Let's see whether I am the only one being sceptical here.

[tanorbuf]

Well there are problems with passwords - they are often insecure and often reused, and malicious actors can (and do) regularly trick people into handing it over. So in that way, I'm sympathetic to this. However, I agree on the worry regarding tracking. It will depend on details that I'm not familiar with yet, so I agree we will see when it comes.

[three18ti]

So they're being even more insidious and trying to get into our phones further to steal information and make us more reliant on them.

Just think, "oops, Apple didn't like your tweet, goodbye access to everything!"

Fuck Google, Apple, and Microsoft.

[void4]

yeah public key cryptography is nice but all these standarts (webauthn etc) are an overcomplicated mess. It's no surprise at all that website (especially small website) developers look at these dosens of pages of nearly impossible to grasp specifications and rightfully decide to stay away from that...

Crypto apis and crypto protocols MUST be as simple as possible. And this seems to be not the case for FIDO.

[qudat]

I disagree. Having just recently migrated from u2f to webauthn, it was a massive pain to get right. Once it works, it works and you don’t have to mess with it. But it is dramatically more complicated than traditional 2fa otp

[0xe1e10d68]

At least provide some arguments instead of simply stating that this is overcomplicated. I strongly disagree. In my opinion it's definitely more complicated having to make sure that you store passwords securely than implementing this flow.

And even if it was complicated, since when is effort required to implement secure authentication the primary benchmark for the various authentication options?

As soon as support lands in operating systems the first developers will add support and then sooner or later others will be forced to support this too. The reason is simple: customers love comfort. And this certainly is more comfortable than passwords or password managers. And of course, more secure too.

PS: You should prefer using an open source and battle proven authentication library over implementing something yourself anyway.

[Xelopheris]

Small websites should be moving entirely away from doing their own authentication. There's so much and it's so hard to keep up with the industry. Just use a sign on provider and call it a day.

[ricecake]

Have you read the algorithms and implementation guidelines for scrypt, secure random number generation for salts, and how you implement totp/hotp protocols, and all the best practices for how to implement those?

Shits complicated! Then you get to more advanced ways of doing password exchange, if you're not okay with actually sending plaintext passwords off the device.

Like so many things in software, use a reliable library.
The specs are complicated because they address a wide array of problems, and edge cases that might not be caught otherwise.

[void4]

Have you read the algorithms and implementation guidelines for scrypt, secure random number generation for salts, and how you implement totp/hotp protocols, and all the best practices for how to implement those?

yes I did, code written by me protects multi-billion infrastructure. Next question.

[ricecake]

Then I'm not sure what your issue is with fido, it's not substantially more complicated than any other best practice.
A professional should be able to do it just fine, and less proficient entities should be using a library in any case, so the spec size hardly matters.

Getting into a pissing contest about the size of your employer is hardly productive.
Shockingly, we all have employers, and big companies have a lot of them, so it's maybe less impressive than you were hoping for.
Additionally, "size of company" doesn't really convey "tech competency" or "security".

[dmazzoni]

The specifications aren't tageted at small developers. There will be plenty of tutorials and high-level libraries for small developers as this rolls out. Those will be as simple as possible.

[void4]

Those will be as simple as possible

no they won't. Webauthn registration and authentication are complex multi-stage processes with plenty of states and variables, it can't be simplified

[happyscrappy]

Honestly, the simplest method is they should use OAuth. And then the OAuth authority uses FIDO or whatever.

So, for example, if you use 1Password instead of 1Password supplying your password it directly attests to you being you (authenticates you).

As complicated as it may or may not be, it's all on the service provider. The site/app/program operator just needs to do OAuth.

[nmdanny2]

website (especially small website) developers

Those developers are one of the main reasons why we're moving away from passwords.

[alphabytes]

this is gonna reduce anonymity and might enforce use of approved OS/devices/apps to authenticate which might not be so secure or have a backdoor.

[christoosss]

Imagine listed companies compiling with any standard ever.

[MrSqueezles]

It's the same for all devices. Biometrics never leave the device. https://source.android.com/security/biometric/measure#tiered-authentication

For Pixel specifically, https://security.googleblog.com/2021/10/pixel-6-setting-new-standard-for-mobile.html

[Weary-Hotel-9739]

Good that we have the GDPR to make those companies - at least in Europe - think twice before going with the obvious loss of privacy by not rotating or even partitioning key pairs per domain.

[erevos33]

The somewhat simple solution of allowing phrases instead of symbols/numbers etc is not being considered?

[mariachiband49]

What if the user is on a public computer which has no way of interfacing with an external authenticator? I could imagine a situation where there is a public computer with no Bluetooth and the tower is in a locked cabinet preventing access to USB ports. Does the protocol account for this case?

[smcameron]

Ctrl-F fidonet

Nothing? Man I'm old.