Live data from Hacker News

Apple Passkey

developer.apple.com

291–300 of 421 posts

Re: Apple Passkey

#291
post #216

Earlier quoted context omitted.

> Apple’s implementation uses SMS as a backup. I hope they'll go away from this, or at least give the option. I won't use their password/key storage until they do. 2FA is only as good as the weakest link, and SMS is the weakest possibility.

2FA is as strong as the strongest link, not the weakest. You need both factors, not either factor. In this case, it's just that one of the factors has a weak backup option.

Until the "try another way" option is a weaker form of 2fa, like sms.

Re: Apple Passkey

#293

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.

Sim cards can have pin codes

Re: Apple Passkey

#294
post #230
post #223

Earlier quoted context omitted.

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

> always use TOTP TOTP can be phished or man-in-the-middle'd and isn't as secure.

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.

Re: Apple Passkey

#295
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've used this gem for rails apps https://github.com/cedarcode/webauthn-ruby

Re: Apple Passkey

#296
post #287

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

You should have a third in a safety deposit box at a bank or other offsite location. The issue is if you have a fire and both your keys are melted, you're f'ed.

But the entire issue is that needing to enroll all your keys every time you gain access to a new service is directly at odds with keeping one copy/key in a second, safe location.

If there were one more layer of abstraction where all N of my keys prove that I'm "me" (or proves that I'm some entity) and the "me"-ness is the principal that gains access, that would be nice, but that's directly at odds with not wanting to rely on some third party identity/authentication provider.

Authentication is hard.

Re: Apple Passkey

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

TOTP is prone to phishing. Not to mention that you still need a password so it's both insecure and hard to use. You could ague that "When used correctly, password are a fairly great solution " but as passwords are flawed they are exploited and even the "experts" happen to fall victims to "improper" use of passwords.

Re: Apple Passkey

#298

Could Passkeys ever be used for SSH? I purchased a Yubikey to use as an ed25519-sk key but found the implementation to be too drastic of a change to my workflow to be comfortable with. TouchID / FaceID for SSH would be a totally palatable solution however.

1Password supports this: https://blog.1password.com/1password-ssh-agent/

Re: Apple Passkey

#299
post #214

Earlier quoted context omitted.

Yes, having the verification done by the secure enclave itself is more secure. The TPM spec does allow for direct integration with biometric devices, but I'm not aware of any general purpose computers that ship in this configuration. > TPM tricked in giving out its secrets To be clear, the key can never leave the TPM (with how tpm-fido is implemented). The threat is an attacker can perform an online attack by getting…

> To be clear, the key can never leave the TPM (with how tpm-fido is implemented). Yep sorry you're right you wouldn't get the actual keys to use elsewhere, you can just use them as if you had them on the "compromised" device only, my bad. > But it doesn't really matter for the Webauthn threat model. An attacker with root access can steal your browser sessions directly. If you're using WebAuthn to authorize the emiss…

A compromised main UI device could also show the wrong account recipient, even if hardware key is used. The text could be changed on the screen when the user meant to send a small payment to someone else. Yubikey will be pressed like usual. Apple's standard prompt on the phone may not have the recipient shown.

Re: Apple Passkey

#300
How do I deal with this when I move from an Apple to a non-Apple device (Android, Chromebook, Linux, Windows, whatever)? With passwords it's straightforward. I just log in.
Post reply on HN