511–520 of 684 posts
Earlier quoted context omitted.
> nobody wants to allow plaintext export of passkeys. While noble, why? 1Password exports a plaintext file that has all of the credentials in plaintext already.
Because passkeys are supposed to be a bit more secure than plaintext passwords.
Not “or”. Passcodes don’t provide availability, so they are not providing security.
This is undergrad-level stuff.
Earlier quoted context omitted.
> Very much this. Having authentication tied to hardware you don't control is a near-certain denial of service in the future. Then you can tie it to hardware you do control, or to software. Obligatory "Passkeys misconceptions" article: https://www.stavros.io/posts/clearing-up-some-passkeys-misco...
That article is about as misleading as it's possible to be while still being technically right. The "attestation" feature of passkeys exists solely to let websites refuse to let you use passkeys tied to hardware you do control, or to software. The way this article only mentions it in passing and tries to downplay it reminds me of the joke of https://what-if.xkcd.com/49/ - a very long article listing a bunch of upside…
Earlier quoted context omitted.
> made even worse by it being treated as equivalent to password+2FA. passkeys are significantly more secure than the most widely-used/most popular forms of 2FA, because the most popular forms of 2FA are TOTP and SMS, and both are subject to phishing attacks. A passkey alone is much more secure than the vast majority of password + 2FA combinations. The only thing stronger than a passkey standing alone is a Security Ke…
> passkeys are significantly more secure Blanket statements like this demonstrate a misunderstanding that "security" is just one thing in a single lineal scale. In reality you have to ask, secure against what? And to answer that meaningfully you need to a thorough threat model for the specific use case of person P and account A. The same person P will have a different threat model for every account they have. The D i…
Can we decide to band together as an industry and call this “zero factor authentication,” since you login without using something you know or something you own/control? The only way I can think of to explain this to a non-techie is “your account is now tied to your [singular] device, and neither a password nor a replacement device (like a new sim card) will let you in.” So, it really does remove both factors from 2FA…
Something you have: Your phone Something you know: Your pin Something you are: Your FaceID/Fingerprint
So, when you are holding your dead phone, you realize that there is nothing you know or have that will let you into the account (and there never was such a thing).
Earlier quoted context omitted.
All those issues were obvious from the day zero, and raised multiple times by many people. They're deliberately ignored by the stakeholders. They strongly want to lock you in to their own authentication platforms (iCloud Keychain, Windows Hello, 1Password*), that's why they don't want to address this. It's impossible they're not aware about those issues. Anyone with a brain and some technical expertise would come up…
You can recover access to your iCloud Keychain even if you've lost 100% of your devices. See the section titled "Recovery security" in this article: https://support.apple.com/en-us/102195 Relevant excerpt for those too lazy to click through: "However, it's also important that passkeys be recoverable even in the event that all associated devices are lost. Passkeys can be recovered through iCloud keychain escrow, which…
Earlier quoted context omitted.
Passkeys aren't inherently un-backup-able. I do agree though that the most common forms of it (e.g., Android/iOS/Windows secure enclave passkeys) need better ways of recovery and remediation. That said, what you describe is easily doable in other forms. For hardware tokens, you can have a spare Yubikey that's authorized on your accounts and keep that in a fire safe with its unlock PIN. For something like 1Password, y…
> Passkeys aren't inherently un-backup-able Agreed, I'm just not willing to endorse their use until there are robust recovery and remediation processes. > For something like 1Password, you can print out a recovery kit [1] with the secret key and unlock password. Yeah, this is what I want Google/Appleto provide as it is robust to both user incapacity and provider refusal-of-service.
They seem ripe for corporate use where ransomware and phishing are common threats and IT can manage account resets by walking over to their desk.
As others have pointed out, cryptographic authentication is very hard to bootstrap if you simply loose your device. Just last month my missus cracked the glass of her iPhone. Apple repaired it under AppleCare, which is great… except … that they didn’t tell her that the “glass repair” entails them replacing the guts of the phone and wiping it in the process. Apple iPhone backups don’t contain cryptographic secrets lik…
Earlier quoted context omitted.
Good news that you can’t bring someone’s face to google and ask for access to their account… Please don’t insert commentary when it’s clear you don’t know what you’re talking about
Thieves can steal a car using tech magic. That is also true about access to accounts. That contradicts your comment. Biometrics, if stolen, can be used to access any of accounts if one obtains knowledge about how to use it for hacking. Your comment violates HN guidelines, but as guideline says I assume good faith therefore I have provided details about how you're incorrect on that one.
If one wanted to use biometric data to access a Google Account secured with a passkey, one would:
1. Need to find a device with that passkey on it (or an account like iCloud Keychain or 1Password that contains the synced passkey). Biometric data could be used to unlock the iPhone, in theory. I'm not aware of this being done in practice.
2. Then unlock that passkey. On iOS, biometric data could be used to perform this step, just as accessing the iPhone in step 1.
If you hold the power/volume buttons or do a Find My lock, it disables biometric auth on an iPhone. I assume there are equivalent tools on Android.
So, if I lose my iPhone and someone also scanned my face, they could login to my Google account by generating a face accurate enough to fool Face ID, and only if they did it before I marked the phone as lost.
As others have pointed out, cryptographic authentication is very hard to bootstrap if you simply loose your device. Just last month my missus cracked the glass of her iPhone. Apple repaired it under AppleCare, which is great… except … that they didn’t tell her that the “glass repair” entails them replacing the guts of the phone and wiping it in the process. Apple iPhone backups don’t contain cryptographic secrets lik…
> Run away screaming. Don’t believe the hype. Wait until the vendors get their act together and come up with a solution for transfer and recovery. I believe all of the issues you've described, but you can usually add multiple passkeys to each service. There is nothing stopping you from adding your iPhone and a cheap android phone and having redundancy, or using 1Password and storing your passkey in there. iPhone back…
Earlier quoted context omitted.
The whole point is vendor lock-in.
How does that work if you can register multiple different keys using different devices from different vendors on an account? Edit: I took the last sentence out, it was childish on my part.
Yes, some individual implementers recognize the issue and have "log in with another device" (which is the best option you can have, although still quite clunky), so you can solve the chicken-and-egg problem of logging in on another platform's device to add your another platform's passkeys. But to best of my awareness, this is not a part of any standard or recommendation (it should've been).
And other implementers do the contrary and artificially limit your options so you can't add a portable authenticator with them without some hacking around.