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.
Apple Passkey
291–300 of 421 posts
Re: Apple Passkey
#292Re: Apple Passkey
#293Earlier 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.
Re: Apple Passkey
#294Earlier 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.
Re: Apple Passkey
#295This 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.
Re: Apple Passkey
#296Earlier 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.
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
#297Earlier 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…
Re: Apple Passkey
#298Could 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.
Re: Apple Passkey
#299Earlier 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…