Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

fidoalliance.org

Post reply on HN
Print view View original

451–460 of 525 posts

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#451

Post by judge2020 »

DCKing wrote: post #448
mjevans wrote: post #310

Earlier quoted context omitted.

I do NOT want to use my phone. It cannot be considered to be a secure device given the 'network' baseband control chipset will never be owned by the phone's buyer and has full access to the device.

This is an urban legend. It ticks all the boxes of people who are inclined to be paranoid about these sort of things (I realize saying that may come across as a value judgment: it isn't), so it remains a popular meme. But the "baseband controls the main phone" is a meme that was maybe true for mid 00s dumbphones but not modern smartphones. That's not to say that you should trust modern smartphones. That's up to you.…

While I can't find the reference, I remember reading about how Apple set up their connection to the modem in a very particular way to where it has its own co-processor for any code it needs to run, and the bridge between it and the main SOC is just IO for rpc and network access.

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#452

Post by im3w1l »

michaelt wrote: post #65
vngzs wrote: post #38

Earlier quoted context omitted.

You just register 2-3 keys. It's not so bad.

Eh, retrieving a key from off-site storage every time you open a new account is a pretty big inconvenience, even for a security enthusiast.

Would be neat if the devices had a public key you could keep onsite and use to enroll.

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#453

Post by judge2020 »

throwaway52022 wrote: post #199
zozbot234 wrote: post #188

Earlier quoted context omitted.

Software ("virtual") implementations are already possible in WebAuthn. It's up to the service whether to allow enrollment via a software authenticator; most services will want to allow this, seeing as it's still way more secure than ordinary username/password.

For web apps/services, the browser needs to be involved here too, right? (And maybe the OS?) How can I tell Chrome on my desktop to use my "software token" instead of Chrome looking for a hardware token over USB or finding it via NFC, so the remote service can ultimately interact with my (virtual) token? (I don't even want to think about how to tell Mobile Safari on my iPhone how to find my key) EDIT: My ideal setup,…

https://news.ycombinator.com/item?id=31275560

Yes, either the Browser or the OS will need to be involved. For example, for Webauthn on Chrome on Windows: chrome receives the request, then it calls the Windows Hello APIs. Then, that Windows Hello API shows a popup to read a physical security key or authenticate a virtual security key via face/PIN (this is protected by a TPM, but it's "virtual" since Windows generates it via the TPM but stores it encrypted on-disk).

To support a syncing fido keyvault, Chrome could very well redirect the calls to its own popup for choosing to 'use Chrome', or 'use another key', which would then call the Windows Hello API. In fact, Chrome already supports this[0], with 'Add a new Android phone' is simply how they're presenting Webauthn over BLE, and it works with iOS when passkeys are enabled in the iOS developer menu[1].

0: https://i.judge.sh/Qq93C/v_GG5R7LyM.png

1: https://developer.apple.com/documentation/authenticationserv...

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#454

Post by astrange »

judge2020 wrote: post #451
DCKing wrote: post #448

Earlier quoted context omitted.

This is an urban legend. It ticks all the boxes of people who are inclined to be paranoid about these sort of things (I realize saying that may come across as a value judgment: it isn't), so it remains a popular meme. But the "baseband controls the main phone" is a meme that was maybe true for mid 00s dumbphones but not modern smartphones. That's not to say that you should trust modern smartphones. That's up to you.…

While I can't find the reference, I remember reading about how Apple set up their connection to the modem in a very particular way to where it has its own co-processor for any code it needs to run, and the bridge between it and the main SOC is just IO for rpc and network access.

Well, the baseband always was its own processor - that's why it's a separate thing called a baseband. What you're thinking of is an IOMMU, it's like a firewall that prevents coprocessors from reading all of RAM.

If there are vulnerabilities on the AP (main processor) then you can hack it from the baseband, but also from the bluetooth or WiFi chips.

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#455

Post by astrange »

mjevans wrote: post #310
throwaway52022 wrote: post #199

Earlier quoted context omitted.

For web apps/services, the browser needs to be involved here too, right? (And maybe the OS?) How can I tell Chrome on my desktop to use my "software token" instead of Chrome looking for a hardware token over USB or finding it via NFC, so the remote service can ultimately interact with my (virtual) token? (I don't even want to think about how to tell Mobile Safari on my iPhone how to find my key) EDIT: My ideal setup,…

I do NOT want to use my phone. It cannot be considered to be a secure device given the 'network' baseband control chipset will never be owned by the phone's buyer and has full access to the device.

Your phone is a whole lot more secure than your PC. It has to be, because you carry it around with you all day and it's easier to steal, so it has to be resistant to a lot more things.

Caveat emptor on cheaper/older phones or ones you enabled developer modes on.

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#456

Post by judge2020 »

Sahbak wrote: post #222
teeray wrote: post #213

Earlier quoted context omitted.

Is that how most credentials are stolen these days?

Most attacks are social engineering. Everything else, to the best of my knowledge, does not target passwords

The biggest attack is persistent login tokens that are stored on a device, eg. Discord has an issue with malware (disguised as DMs from random people asking "do you want to try out a beta for my game") that steals the login token from appdata, using it to purchase a bunch of gifted nitro and perpetuate the scam via that user's account.

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#457

Post by judge2020 »

stjohnswarts wrote: post #146
anthony_r wrote: post #81

Earlier quoted context omitted.

It's literally the opposite. You "must" have a cryptographic device (a dongle) that is only doing that one thing, authentication. Doesn't have a built in radio (unless for NFC, if you want it), doesn't have any microphone or camera, doesn't store any data beyond what's needed to authenticate, doesn't communicate except to authenticate - bi-directionally, so phishing is no longer a thing, or at least it's a lot harder…

The primary case for FIDO is a company like google or apple revoking your access and they have no/limited ways of recovering your account.

No. Google's power to lock people out of their website is already here with the prevalence of 'Sign in with Google'.

FIDO is unrelated; it works by having the browser/device itself sync the virtual security keys[0], much in the same way they sync passwords currently. That's the only thing changing here, giving people the choice (and encouraging them) to sign in via "what you have" instead of "what you know".

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#458

Post by judge2020 »

eMGm4D0zgUAVXc7 wrote: post #91
anthony_r wrote: post #81

Earlier quoted context omitted.

It's literally the opposite. You "must" have a cryptographic device (a dongle) that is only doing that one thing, authentication. Doesn't have a built in radio (unless for NFC, if you want it), doesn't have any microphone or camera, doesn't store any data beyond what's needed to authenticate, doesn't communicate except to authenticate - bi-directionally, so phishing is no longer a thing, or at least it's a lot harder…

> It's very hard to make a privacy case against FIDO. With username and password, I have full control over my privacy in a very easy to understand fashion: If I randomly generate them I know I cannot be tracked (as long as I ensure my browser doesn't allow it by other means). With those keys I have a opaque piece of hardware which transfers an opaque set of data to each website I use and I have NO idea what data that…

> I need to trust the hardware.

With your password manager, you're trusting a lot more: the software of the OS and kernel, the software of the browser and its dependencies, the software of your password generator and your password storage. You also have to hope the developers and administrators of the website you're signing in to aren't storing your passwords in plain text (and I don't just mean in the database - overly-aggressive APM/logging might be storing POST request data in a log stream somewhere).

The only attack that's an issue for both passwords and security key-based sign-in is targeted attacks against a website, where they use your browser to execute malicious API calls to the website after you've signed in regularly.

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#459

Post by judge2020 »

nybble41 wrote: post #419
jeroenhd wrote: post #263

Earlier quoted context omitted.

TPMs allow for arbitrary key storage by the operating system. They're not necessary for DRM. In fact, I've wiped my TPM several times to upgrade the firmware and I've had no trouble playing DRM content whatsoever. Technologies like Intel's management engine and SGX or their AMD/Qualcom/Apple counterparts are definitely problematic for user freedom in the way they're implemented. However, the TPM system itself is quit…

The user-hostile part of the TPM is the built-in key signed by the manufacturer which shows that it's an "approved" TPM which won't—for example—release any of the keys stored inside to the device's owner. This is what allows the TPM to be used as part of a DRM scheme. If it weren't for that small detail then I would agree that TPMs can be useful for secure key storage and the like, working for the device's owner and…

It enables it, but that's just because both you, the device user, and M$ and the rest of the media industry, need to ensure the TPM inside the processor is genuinely from the manufacturer. You wouldn't want to use a TPM if an attack vector is one where China (who is a large part of the supply chain) can poison a large amount of TPM shipments with their own key that can be used to export or otherwise access internally-stored keys.

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#460

Post by greggyb »

andrey_utkin wrote: post #237
traceroute66 wrote: post #158

Earlier quoted context omitted.

> Are there any FIDO security keys that explicitly support backing up and restoring their master secrets? Why would you need that ? On most services that I use that support FIDO, you can register as many keys as you like. Seems to me that is a much more secure option than to provide a potentially exploitable option of allowing key extraction.

You cannot register more than one security key with *AWS*. Which a lot of devs beg for, for years. Can't find that support ticket URL now.

AWS employees are issued two Yubikeys, which are registered for all internal auth use cases. For me, but not for thee, it seems.
Post reply on HN