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

Apple Passkey

developer.apple.com

Post reply on HN
Print view View original

371–380 of 421 posts

Re: Apple Passkey

#371

Post by native_samples »

weberer wrote: post #335

>As the authenticator, your Apple device generates a unique public-private key pair for every account it creates on a service. The authenticator retains the private key and shares its public key with the server, known as the relying party. Its about time something like this really took off. Hopefully it will get rid of dumb hacks like text message verification that a lot of companies use. Plus database leaks will no…

This was around for a long time in the form of SSL client certs, but that never took off for all sorts of reasons. Presumably Apple nailed the UX problems but the general issue of how to back up your keys, get back access if you lose them, the confusion created by not having passwords etc were real isses.

Re: Apple Passkey

#372

Post by danShumway »

altairprime wrote: post #310
howinteresting wrote: post #282

Earlier quoted context omitted.

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.

Apple is already remotely backing up passkeys off-device.

We are having a debate about an Apple policy that doesn't exist. Apple is not following the "keys never leave your device" model, so that security model has nothing to do with whether or not Apple will engage in vendor lock-in.

We're not making the choice to leave users vulnerable to phishing attacks, Apple made that choice, and we're arguing that because they made that choice they have no excuse to also engage in vendor lock-in.

Re: Apple Passkey

#373

Post by stackedinserter »

gingericha wrote: post #334

Maybe only tangentially related, but does anyone user Apple Keychain as their primary password manager? Is that even a viable option if you're completely within the Apple ecosystem?

I used it for a few years, then switched to a paid password manager. Keychain just doesn't (didn't?) have features that I need: cross-device functionality, family sharing, groups for different credentials (work/private), browser integration, etc etc. Also, its UI sucks.

Re: Apple Passkey

#374

Post by smileybarry »

microtonal wrote: post #10

Beta support for Passkey is already in the current macOS/iOS releases: https://developer.apple.com/documentation/authenticationserv... I am already using Passkeys on some websites.

It is, but annoyingly you need to enable it via Xcode, so if you only own idevices you can't turn it on. (Unless you mean just normally adding an iPhone as a security key & using Face ID to authenticate it, which is just how Apple implemented FIDO2 and isn't synced like Passkeys)

Re: Apple Passkey

#375

Post by judge2020 »

Mindwipe wrote: post #355
judge2020 wrote: post #308

Earlier quoted context omitted.

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.

I would wager the majority of iPhone users use Windows on their main machines.

Passkey works on non-Apple devices by showing a QR code on that device, having the iPhone scan it, then a BLE connection being established to allow the phone to remotely sign webauthn requests. I only mention ‘switching ecosystems’ in the sense of moving between Apple and Android mobile devices.

Re: Apple Passkey

#376

Post by spacedcowboy »

al_borland wrote: post #187
zxcvgm wrote: 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…

You don’t need to have your second device to get past 2FA in a disaster scenario. You can phone up Apple Support and as long as you know the code you use to unlock your old phone (which is a reasonable ask), you can regain access to your iCloud account, and hence to your iCloud Keychain/devices.

Apple don’t know your unlock passcode, so they can’t do it for you, but this is designed to cover the “my house burnt down with all my devices inside” type of scenario, or your own “I no longer have access to a device”.

Re: Apple Passkey

#377

Post by raxxorraxor »

psanford wrote: post #112
gsibble wrote: post #105

Earlier quoted context omitted.

How will this work on Linux?

FIDO usb devices just use the HID protocol so they work fine on linux. Chrome and Firefox both support them. I wrote a FIDO implementation that protects the signing key using the system's TPM specifically for linux: https://github.com/psanford/tpm-fido There is no reason why you couldn't implement a similar syncing strategy in a tool like this if you wanted to.

Is there a software implementation that would work without a TPM module where I can generate the keys myself?

Re: Apple Passkey

#378

Post by dividedbyzero »

drivebycomment wrote: post #336
41b696ef1113 wrote: post #294

Earlier quoted context omitted.

Fair, but I am a nobody that is unlikely to be specifically targeted. I am willing to swing the balance towards convenience/backup safety vs utmost security.

A common misconception. After credential stuffing (which 2nf factor protects you from), your biggest threat (for people with 2nd factor) is phishing and keystoke logger, which does not require any targeted attack. OTP is way less convenient than fido keys, so it's both convenience and security. The only downside is the cost, and the effort required for registering multiple keys which is easily compensated for by the…

But then I'm not aware of a FIDO key that works with random apps on an iPhone. That's where I, personally, have by far the most logins and spend money. Pretty much all of them support some sort of authenticator app nowadays though.

Re: Apple Passkey

#379

Post by fauigerzigerk »

stetrain wrote: post #97
mhoad wrote: post #77

Earlier quoted context omitted.

Except Apple are kind of notorious about avoiding cross platform compatibility which is why I ask. Find them hard to trust at this point. I can already hear them making the “we can’t because it will impact users security” argument in my head.

For normal passwords they currently seem to support third party password managers just fine, including direct integration in Safari and the iOS keyboard. You can also export everything from iCloud Keychain to use with another password manager. They could always use Passkeys as an opportunity to lock things down but it would be in direct contrast to what they have been doing with password management recently.

>You can also export everything from iCloud Keychain to use with another password manager.

I can't export anything. This menu item is always disabled for some reason.

Re: Apple Passkey

#380

Post by mrsteveman1 »

highwaylights wrote: post #342
bigiain wrote: post #235

Earlier quoted context omitted.

> Tying 2FA to hardware is for most of the common use cases a bad idea. For me, I don't consider that to be true. I have a Yubikey on my keyring, and a backup Yubikey in my safe. Losing my keys is an extremely rare thing (I've never actually lost my keys, closest I've come in the last 30 years is temporarily misplacing them or locking them inside). I'm happy enough to deal with losing my digital access (via 2FA) tea[…

Question for you about this as I've often considered it. What is the life of a yubikey? Do they degrade over time horizons? The reason I ask is that if you have a backup that you never hope to use it's likely to be accessed only very rarely - which makes me kind of wonder what if your primary yubikey fails in 15 years due to natural wear/tear/degradation due to the passage of time and your backup has succumbed to the…

> What is the life of a yubikey? Do they degrade over time horizons?

I don't think it's an issue in practice, certainly not for someone using them as they were intended, even heavily, but in theory a JavaCard implementation (like most of the smart card ecosystem, Yubikeys are still JC devices as far as I know) could "wear out" from use because of the way they work internally[1].

I've never personally seen that happen, and all of my Yubikeys still work, even the ones I bought over 10 years ago which were used far more heavily (20-30 ssh/gpg/piv operations per hour, every day, for years) than most people would use a FIDO key.

I've only managed to break other manufacturers smart cards by severely misusing them (as a USB-connected Linux HWRNG, I doubt the RNG command was designed to be called every few seconds for years).

[1] The JavaCard standard requires certain (all? I can't remember, it's been a while) objects in applet code to be written to persistent storage (meaning flash/eeprom), which has endurance limits. In practice they're not expected to be treated as permanent storage devices, if a card fails it's supposed to be replaced with another, revoke the old key pairs, register the new ones, etc.

Post reply on HN