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

381–390 of 421 posts

Re: Apple Passkey

#381

Post by fnordpiglet »

ee64a4a wrote: post #323
fnordpiglet wrote: post #242

Earlier quoted context omitted.

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.

You also have to consider the market value of their reputations jointly as well. It would have to be a huge incentive to risk their reputation, both apples with their security conscious customers and customers with high regulatory burden, and the auditor whose only asset of value is their reputation. Auditors typically poof out of existence (Anderson anyone?)

Re: Apple Passkey

#382

Post by BuckRogers »

urthor wrote: post #314
BuckRogers wrote: post #311

Earlier quoted context omitted.

Expecting people to give the minimum of a damn is embarrassing to point out? It's true either way. Sometimes a certain level of complexity can't be abstracted over. This is no longer a fun toy in life. You may have your bank account credentials stolen if you don't wake up and pay attention to what you're looking at. To avoid being lockpicked you only need two-factor. It's that simple. You need some form of password m…

I expect people to do their best, within their capabilities. Nana and Papa are not technologically literate enough to perform the kinds of configurations you suggest. In depth custom password manager configuration isn't for them. They are not at fault for that. We simply cannot expect all of humanity to be that technologically literate. There are many, many roles in life that don't involve electronic devices that are…

My view is best stated that I think people are more capable than they think they are. And I'm unsure people even attempt a try at most things. Maybe that's a negative view but I feel that's what I've observed.

I don't worry too much because most of the most important entities, such as say Social Security in the US forces 2FA on users. I just signed up on that site the other day, and they simply force you to do everything securely, or you don't get in. I found the process lengthy, but appropriate and well-done. That's a great example of how to secure something important without waiting on industry to solve everything.

I agree password management is one of the most difficult parts of the average person's digital experience. Until it's solved through a universal pact by Google/Microsoft/Apple, the built-in password manager on iOS is pretty decent for those types of users. Passkey is a good step in popularizing a solution.

Re: Apple Passkey

#383

Post by mwwaters »

oceanplexian wrote: post #368
mwwaters wrote: post #304

Earlier quoted context omitted.

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

While you're technically correct any authentication system worth it's salt would ideally see the same user trying to authenticate from two different locations, and prompt the second user for another factor of authentication (Email, etc.) And since TOTP expires it's not like they could sit on the token and use it later.

The OTP is already a second form of authentication. An email link would be a third form. I never saw that when I used Authenticator.

Anyway, the user would likely still click the link in the email since they are trying to log in.

Re: Apple Passkey

#384

Post by tedmiston »

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…

> A co-worker told me to move all my 2FA to Authy as a means to avoid locking 2FA to hardware, but I haven't sufficently looked into it yet.

I've heard this approach of cloud-based second-factor auth keys called "1.5FA". It's probably enough for most people, most of the time.

That said, in the case of a broken phone and away from your computer, you'd still need either a second device that's already logged into your vault or a backup recovery code. That's a good thing for all of us to keep in mind the next time we're traveling.

Re: Apple Passkey

#386

Post by _ea1k »

tialaramex wrote: post #207
psanford wrote: post #112

Earlier quoted context omitted.

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.

> just use the HID protocol This is literally true, and covers what was important in context, but warrants a little extra explanation. Since these devices are specifically for humans to interface with (they typically have a button or contact sensor, though some have keypads or a fingerprint reader) they are logically Human Interface Device class USB devices, but they do not speak the HID Keyboard or Pointing Device s…

Oh, thanks for the explanation. I guess this new protocol is why I don't see as many tokens randomly appearing in chat sessions these days.

Re: Apple Passkey

#387

Post by psanford »

tkanarsky wrote: post #245
psanford wrote: post #112

Earlier quoted context omitted.

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.

Oh dang, thanks for writing tpm-fido! It works really well for my use case -- avoiding mandatory and incredibly annoying Duo Mobile 2fa on my school's website -- although I tore the presence verification out of the code for my purposes :) iirc, this relies on the uhid module to mock a physical fido2 key, and I'm not sure if there's a way to present a mock fido2 key OS-wide without relying on a virtual USB device. Thi…

> there's a way to mock a fido2 key systemwide without uhid?

On Linux, Chrome and Firefox interface directly with the USB and Bluetooth interfaces. There is no OS level abstraction for FIDO devices on Linux.

Re: Apple Passkey

#388

Post by psanford »

raxxorraxor wrote: post #377
psanford wrote: post #112

Earlier quoted context omitted.

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?

Check out rust-u2f/softu2f[0].

[0]: https://github.com/danstiner/rust-u2f

Re: Apple Passkey

#389

Post by derefr »

closeparen wrote: post #197
derefr wrote: post #60

Earlier quoted context omitted.

MFA itself is absurd and nonsensical for the vast majority of users. It's security theatre unless you do it right, and if you're doing it right, it's — as you've said — too hard for most people to bother. Properly implemented, MFA is an Enterprise feature, not a personal feature. Like SAML SSO, or having audit-log APIs. The point of setting up MFA is to secure things that really need to be secure, where the person wi…

As far as I understand, the story is: casual users don’t choose unique passwords. MFA, even in its weakest forms like SMS, defends against credential stuffing. Indiscriminate credential stuffing attacks based on database dumps, etc. are common enough that this is worthwhile. FIDO/WebAuthn add protection against phishing (because the token is bound to the domain name). Phishing is also a common indiscriminate attack a…

> casual users don’t choose unique passwords

Isn't this already mostly covered by browsers (like Safari!) doing strong non-memorable password autogeneration + password sync, such that the password in the password field is already essentially acting like a token for these people?

Re: Apple Passkey

#390

Post by [deleted] »

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.

[deleted]
Post reply on HN