Live data from Hacker News

Apple Passkey

developer.apple.com

301–310 of 421 posts

Re: Apple Passkey

#301

Earlier quoted context omitted.

Apple’s implementation uses SMS as a backup. Thinking is probably that if you only have one device, it’s usually your phone; so you would have been able get your 2FA code via text. It’s not easily discoverable though, so easy for you to miss it.

So if I have a single device, a phone, and it gets stolen... what is the path to get my data back? And in the interum, if the theif swaps my SIM into another phone they now have my 2FA via SMS? This all seems very messy when bad things happen.

They solved this with a feature called “Recovery Contacts” in iOS 15(?). You can set them up and they’re people who cannot access your account but can help you regain access if necessary (such as your one device case).

I think you still need to know your password, but that’s pretty reasonable.

They also added a similar feature to allow you to get into a loved one’s account/phone after their death if they set it up.

Re: Apple Passkey

#302

Earlier quoted context omitted.

Passwords in iCloud Keychain are already E2EE, it seems reasonable the private passkeys would be too.

> iCloud ... backup > E2EE If you can lose all your existing devices, and can still restore your data, then that data isn't end to end encrypted. I'm taking the "end" in e2ee to mean your devices. Nothing but your devices can decrypt your e2ee prospected data. If a new device can enter the circle of trust without an existing device's corporation then there is a backdoor. I imagine icloud keychain supports synchroniza…

[deleted]

Re: Apple Passkey

#303
post #165

This is wonderful news! If anyone is interested in experimenting we built an API that makes it very simple to add WebAuthn (passkeys) to your existing web app. It’s available at https://passwordless.dev Note: We also maintain the open source fido2-net-lib, the API just lowers the friction for devs.

This is really cool! And well-timed - I have a project coming up this would be perfect for. The only thing I wonder is, if a user didn’t have biometrics on their device, how would they authenticate? Would I have to maintain a backup system for these users?

Re: Apple Passkey

#304
post #223

Earlier quoted context omitted.

>Currently you need remember to register at least 2 security keys, in case one is lost/misplaced. This is always my issue with 2FA or passwordless auth. You're forced to have 2 devices and are kind of screwed if you don't hvae two on you. I was on a trip and broke my iPhone. It had my plane tickets on it to get home. I was able to get a replacement from Apple, they just gave it to me and sent me on my way. When I tur…

> as a means to avoid locking 2FA to hardware Tying 2FA to hardware is for most of the common use cases a bad idea. Instead always use TOTP and keep the seed in a secure storage with multiple backups. If on top of that you like to keep it on your phone to generate the code that way, fine. But at that point you can destroy the phone and it doesn't matter, you'll still have access. > While I don't like passwords and un…

Any OTP can be phished. There is no automatic authentication that the OTP is being given to the correct party.

A public/private key alone would have a similar issue, but the browser for FIDO keys gives the domain it's actually talking to. The domain is authenticated with TLS or the browser on an uncompromised machine won't send that domain over. The device only signs the challenge with the private key generated for that specific domain.

Re: Apple Passkey

#305
post #159

Earlier quoted context omitted.

iCloud Backups != iCloud syncing iiuc. Passwords/Wifi/etc. syncing is a different E2EE system. You can disable iCloud Backups and still use iCloud

ahhh so they already have what they need to do iCloud E2EE, they just decide not to use it for your data....

Just imagine the outcry if you forgot your password and lost access to all of your pictures or other data?

If I lost access to my passwords (E2E encrypted), it would be an inconvenience.

Re: Apple Passkey

#306

Earlier quoted context omitted.

Try explaining a password manager to your nana, and having her use it. Then explain to her how she can install it on her phone and have it synchronised across all her devices. Password managers are awesome, but way too technical to become mainstream. You shouldn't have to install 3rd party software for something so fundamental. The password system really needs an overhaul and hopefully this will go along way towards…

Sometimes I wonder how bright nana or papa really is as a result. If you won't dig into even an iPhone's settings to learn what's available, what it can do, good luck to you. That curiosity and willingness to play around, accompanied with Google searches when they don't know what something does, is critical in making it in the world today. Or if you remain a rube, and they will, you'll get scammed someday because you…

What a ridiculous thing to say.

Nana and Papa are not locksmiths.

Nana and Papa still deserve to have a front door to their house that can't be lockpicked.

Normal people, who have other interests in life than configuring technology, should have secure devices and data from criminals. And they shouldn't have to configure 5 different obscure password managers to do so.

Society shouldn't allow criminals to take advantage of Nana and Papa.

This is one of the most embarrassing comments I've read on Hackernews.

Re: Apple Passkey

#307
post #165

This is wonderful news! If anyone is interested in experimenting we built an API that makes it very simple to add WebAuthn (passkeys) to your existing web app. It’s available at https://passwordless.dev Note: We also maintain the open source fido2-net-lib, the API just lowers the friction for devs.

This is really cool! And well-timed - I have a project coming up this would be perfect for. The only thing I wonder is, if a user didn’t have biometrics on their device, how would they authenticate? Would I have to maintain a backup system for these users?

In general they just need _something_. If Windows Hello has even a pin number, Chrome and FF webauthn prompts will use Windows Hello as a TPM provider (assuming the website is using actual Webauthn and not the older U2F-compatible standard, which some sites still use for compatibility, eg google). If they don't have anything, then they will definitely need at least a usb hardware key.

Re: Apple Passkey

#308
post #280
post #263

Earlier quoted context omitted.

There's nothing to backup/import. If you have an iPhone, you use your fingerprint or Face ID. If you sell your iPhone and buy an Android, you use your fingerprint or face recognition on that device.

I haven't dug into the docs yet, but I don't quite follow this. How does it know that the ex-iPhone owner and current Android owner are the same person (and should have access to the same account)?

If you did switch ecosystems, you'd probably need to do the whole re-enroll dance on every website that had your previous key. I don't see any sort of passkey backup/import functionality coming anytime soon simply because people don't change ecosystems that often, and those that do can simply keep both their iCloud and Android-based passkeys on services.

Re: Apple Passkey

#309
post #90

Earlier quoted context omitted.

> Also we still need ways of exporting keys and software (like 1password) needs to synchronize them, manage them securely. There's still a long ways to go on that front, which probably won't be handled until stuff like this has settled. That's the point of passkeys here: iCloud Keychain syncs them, and if you want to use your keys on a non-apple device you'll be able to scan a QR code, which initiates a new BLE conne…

I'm writing this on a non-Apple computer that doesn't have any radios. Now what?

This may help: https://chrome.google.com/webstore/detail/icloud-passwords/p...

Re: Apple Passkey

#310

Earlier quoted context omitted.

I don't consider this solution an excuse for vendor lock-in. I consider this a problem that has no known solutions without vendor lock-in. If you offer users a way to export, then you offer phishers a way to social engineer users. So either you prevent social engineering (lock-in: yes), or you allow exports (lock-in: no). Which choice has a higher precedence when serving the market of "non-technical mobile phone user…

You can offer to transfer data to another computer or phone that's plugged into yours over USB.

Your choice is to allow people to be phished for credentials, then.

Gullible people will cheerfully complete any attacker-described PC syncing process, ignoring every security warning presented to them, in order to give away the keys to their accounts. They’ll use a friend’s PC, or a library PC, or anything under the sun, if the phished promises to give them something for nothing.

Post reply on HN