Live data from Hacker News

Apple Passkey

developer.apple.com

321–330 of 421 posts

Re: Apple Passkey

#321

I don't get what it's all about this passwordless. I make my browser (Firefox) generate strong password and store them in its password manager, this is synchronized with end to end encryption to all my devices, I have only to remember a master password. It's kind of the same but it works with every website. It is not complicated, doesn't require certificates that you may loose, and that sort of things.

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…

Password managers are already pretty easy to use from a nana's perspective. The main problem is that nana does not know that password managers exit itself. Most of them just input password as 'nana1234' and store it in their browser password manager (usually chrome password manager) and use chrome's autofill.

Eg., I was telling a middle aged person (50 years) about password managers and were unable to grasp the idea of it. 'Why would you store passwords in cloud based password manager from a company I have never heard of, just type a password and write it down on your diary (OS notes app) or just store it in chrome. I trust google (chrome) to keep my passwords safe rather than with some sketchy company I have never heard of (the sketchy company if one of the most reputable cloud based password management company).

Re: Apple Passkey

#322

Earlier quoted context omitted.

I would assume that they are at least encrypted locally before being uploaded to iCloud. (But yes, Apple could always change things)

Don’t be so certain - we need more details from Apple on this. Last I checked iMessage was still (!) not encrypted when backed up to iCloud. https://www.howtogeek.com/710509/apples-imessage-is-secure.....

iMessage backups are encrypted, they are just not encrypted as much as some people would like.

In particular, Apple has HSM servers outside their hosting environment for auditable release of encrypted backups. This could be done for a support request for a lost user password or as part of a legal demand (say, family of the deceased seeking access to photo history, or requested by law enforcement with a court order).

The passkeys system uses iCloud Keychain, which is a separate mechanism and is encrypted before being sent to Apple using user-device-private keys. You should need to both get iCloud access _and_ provision a device into the "ring" before you can access passwords or passkeys.

Re: Apple Passkey

#323
post #215

Earlier quoted context omitted.

If you don't trust Apple, why would you trust a third party auditor? I can't think of any entity I would trust with securing truly sensitive information. For important stuff, do it yourself. For simple things, including bank accounts and such, I see no issue with trusting Apple.

Because you’re trusting both apple and the third party jointly, each of whom have different incentives. I don’t know I buy the “for truly sensitive stuff do it yourself” line. That’s like saying for the truly lethal substances handle them yourself. Most people aren’t more skilled than the apple security folks. You’re almost certainly going to screw up your encryption or leave some vulnerability unpatched or unknown.…

> Because you’re trusting both apple and the third party jointly, each of whom have different incentives.

The cynical view, of course, is that Apple's incentive and the Third Party's incentive can become very much aligned for the right amount of money.

Re: Apple Passkey

#324

Earlier quoted context omitted.

Don’t be so certain - we need more details from Apple on this. Last I checked iMessage was still (!) not encrypted when backed up to iCloud. https://www.howtogeek.com/710509/apples-imessage-is-secure.....

iCloud Keychain is end-to-end encrypted, Messages isn't because Apple took the tradeoff of allowing people to keep their imessage history even upon a support-initiated account reset, which otherwise will wipe your entire iCloud Keychain.

Messages is end-to-end encrypted. The key is stored in iCloud backups if they’re enabled (and if I recall correctly the messages on your device are backed up as part of an iCloud backup as well), but you can turn those backups off.

> [1]For Messages in iCloud, if you have iCloud Backup turned on, your backup includes a copy of the key protecting your messages. This ensures you can recover your messages if you lose access to your Keychain and your trusted devices. When you turn off iCloud Backup, a new key is generated on your device to protect future messages and isn't stored by Apple.

> If you forget your password or device passcode, iCloud Data Recovery Service can help you decrypt your data so you can regain access to your photos, notes, documents, device backups, and more. Data types that are protected by end-to-end encryption—such as your Keychain, Messages, Screen Time, and Health data—are not accessible via iCloud Data Recovery Service. Your device passcodes, which only you know, are required to decrypt and access them. Only you can access this information, and only on devices where you're signed in to iCloud.

[1] https://support.apple.com/en-us/HT202303

Re: Apple Passkey

#325

Earlier quoted context omitted.

The password stored in your backup via iCloud Keychain use the passcode of your devices as a secondary encryption/lock method, which doesn’t have a password recovery mechanism like the Apple ID used to secure your iCloud backup. Not sure that meets the definition of E2EE but it’s not like the passwords are recoverable by another party (or even you, if you forget the passcode) just because they’re in your iCloud backu…

So maybe I don't get it, but I always understood that 2FA means something you know and something physical you have. Now if I can get they keychain using something I know, does that not somewhat defeat the purpose of 2FA?

Typically MFA is something you have (physical possession), along with something you know (secret) or something you are (biometric).

This is more abstract than physical possession of a single device with a non-exfiltratable private key. There are synchronization processes (so its one of many physical devices, on a sync fabric which allows devices to be added).

The process for adding a device should require multiple factors as well, but I believe there ultimately is a typically a recovery mechanism like a printed recovery key which would make this considered single-factor.

However, most deployed 2FA is via SMS, email, or backed-up TOTP today. The goal is to build a much more secure system that is recoverable enough to get consumer adoption, not to try to achieve say NIST 800-63 AAL3.

One ongoing proposal is that you get an additional device-bound factor as well. Seeing a new device-bound factor would let you decide to do additional user verification checks if desired.

Re: Apple Passkey

#326
post #301

Earlier quoted context omitted.

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.

>They solved this with a feature called “Recovery Contacts” in iOS 15(?).

That doesn't solve it for me. None of my trusted contacts has an up-to-date Apple device.

Re: Apple Passkey

#327
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....

Perhaps the clearest way to see what is available is to look at https://www.apple.com/legal/privacy/law-enforcement-guidelin... to see what information is available.

There are plenty of non-LE use cases, such as people who need to recover access after a lost password, as well as families who want access to a deceased family member's information after the fact.

Apple has been (slowly) adding support for other recovery systems and for legacy contacts as first-class features. The UX for this currently lists Apple as a fixed option among a list of other options (such as personal contacts).

I expect long-term that Apple will have access to backup recovery for a number of people as a system default, but not for everyone.

Re: Apple Passkey

#328

Does anyone know if this is different to Webauthn? You can already login with touchid/faceid, with the private key stored in apples keychain. Lots of sites support it, I just added it as 2FA to Mailpace ( https://blog.mailpace.com/blog/why-we-use-webauthn-for-2fa/ ), making it passwordless login instead of 2FA is trivial and fully supported by webauthn. What’s different about this?

WebAuthn is a Web-facing Javascript API for accessing passkeys, which it calls Public Key Credentials.

Technically, a Passkey is 'just' a key pair and other authentication information, associated with a web origin. It's meant to be a broad consumer facing term that resonates similarly with 'passwords' to convey its similar usage.

Apple platforms, along with Android and Windows, are implementing a system that synchronizes passkeys within their respective ecosystems. They are adding ways you can entitle an application to work on behalf of a web domain, and thus get native access to register and authenticate with passkeys as well.

A Yubikey or other FIDO device has been doing hardware-bound passkeys for ages. They just didn't use that term, instead calling them FIDO credentials.

The above platforms are also working on processes to allow usage across ecosystems - for instance, using your iPhone to sign into a Windows desktop.

Re: Apple Passkey

#329
post #46

This is based on the open standards WebAuthn and FIDO2, where the credentials (“passkeys”) are synced via iCloud Keychain. Currently you need remember to register at least 2 security keys, in case one is lost/misplaced. The syncing of passkeys in iCloud solves this backup problem. https://fidoalliance.org/apple-google-and-microsoft-commit-t...

>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…

A password can very well be as secure as the ownership of a device. Compared to most 2FA schemes I love them because they are simple. I think if people are trained adequately it isn't an insurmountable barrier. But the industry never did develop good practices and bad ones are still around.

I don't like to have my key chain in the cloud at all. Loss or lack of access is far more likely this way. I already hate that services profile my device or location.

Re: Apple Passkey

#330
post #183
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.

i use fido2-net-lib for a personal auth site, it works great! thanks for all your work!

Hey! Happy to hear Making this tech available has been our goal since inception
Post reply on HN