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

361–370 of 421 posts

Re: Apple Passkey

#361

Post by jhugo »

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…

It's solid state electronics, if not subject to any external factor (which should not be common to both) it will just keep working on any timescale that matters here.

I've carried one in my pocket for ~10 years without a problem, now I want to replace it because it's too old to support ed25519. That's likely a fraction of its useful hardware life.

Re: Apple Passkey

#362

Post by madeofpalk »

userbinator wrote: post #243
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...

It's strange and rather unfortunate to see this constant reinvention of authentication methods. Asymmetric encryption as used in things like SSH keys and TLS client authentication have been around for decades, are very much standard, and the only changes to those have been stronger algorithms and longer keys. Smartcards as hardware secure elements have also been around for a long time. I'm not sure how much of a cons…

My understanding is that this basically the same asymmetric public/private key encryption.

WebAuthN is the standards for defining how this works on the web.

Fido is the alliance (+standards?) for multi-platform interoperability. How do I get my private keys from my iPhone into Chrome on my PC?

Re: Apple Passkey

#363

Post by jwr »

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?

Not that I could see over about 4 years. I've been using one YubiKey (USB-A) for over four years now and a second one (USB-C) for over two. Each has been carried with my keys for at least two years.

But the right approach anyway is to use this excellent tutorial: https://github.com/drduh/YubiKey-Guide and generate your keys yourself, storing a backup in a secure location. This is what I do — so even if my keys get completely destroyed, it will be possible to recreate them from backup.

Re: Apple Passkey

#364

Post by mensetmanusman »

zamalek wrote: post #132
mensetmanusman wrote: post #119

Earlier quoted context omitted.

Streamlining would be an improvement, but it opens an attack vector. Unfortunately, security and usability are always in balance.

I should have been more specific. Test how many clicks it takes to add a key to one of your "mainstream" accounts. We would hope that services which support FIDO eventually gravitate to a single UX language, that also reduces the time taken to register new keys.

Agreed

Re: Apple Passkey

#365

Post by larrybud »

i67vw3 wrote: post #321
sideshownz wrote: post #220

Earlier quoted context omitted.

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…

> I was telling a middle aged person (50 years) about password managers and were unable to grasp the idea of it.

This is more than a little ageist, don’t you think?

> Why would you store passwords in cloud based password manager from a company I have never heard of?

This is actually a very valid question; hope you didn’t just dismiss it due to “the oldie doesn’t understand.”

Re: Apple Passkey

#366

Post by dmm »

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

A lot of sites allow you to create backup codes that you can print out and use once instead of the security key.

Re: Apple Passkey

#367

Post by acka »

simplify wrote: post #188
acka wrote: post #169

Sorry for the somewhat but not quite off topic post, but can we please prevent HN from becoming yet another Apple billboard? There are more than enough of those already. Thank you. Yes I've heard that there may be some Apple manifestation going on or something but to have every little Apple tidbit hoisted directly to the front page (at least 7 articles and counting) is a bit much imho. Downvote me if you must, but I…

This post is related to a large number of developers and startups (read: HN users), many of which have at least an iOS app or support safari. I don't see what the problem is.

My reply was not directed at this post in particular, but at the worryingly large number of Apple related posts making it to the front page lately. It makes me worry that HN is becoming biased towards favouring news about Apple's activities above other interesting subjects.

Companies release new products all the time, I'm not sure that HN is the proper place to discuss them unless they are truly innovative or newsworthy.

Re: Apple Passkey

#368

Post by oceanplexian »

mwwaters wrote: post #304
jjav wrote: 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…

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.

Re: Apple Passkey

#369

Post by lathiat »

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…

Your options are here btw. Another apple device, text to phone number or account recovery which is automated but takes a few days: https://support.apple.com/en-us/HT204915

Re: Apple Passkey

#370

Post by danShumway »

altairprime wrote: post #246
danShumway wrote: post #196

Earlier quoted context omitted.

I get where you're coming from and you're not wrong, but at the same time, I don't buy this as an excuse for vendor lock-in here, because it seems like Apple is already backing up passkeys to iCloud. If Apple has decided that the risk of getting your passkeys phished out of your Apple iCloud Account is outweighed by the benefit of users being able to restore/sync login details immediately when they buy a new iOS devi…

I don't consider this solution an excuse for vendor lock-in. I consider this a problem that has no known solutions without vendor lock-in. If you offer users a way to export, then you offer phishers a way to social engineer users. So either you prevent social engineering (lock-in: yes), or you allow exports (lock-in: no). Which choice has a higher precedence when serving the market of "non-technical mobile phone user…

I think you're misunderstanding what I'm saying. Apple IS allowing users a way to export right now, we just don't know whether non-iOS devices will be supported.

I consider the binary you describe to be a justifiable reason for Apple to offer no way to export from a phone, but that's not what they're doing. And I do not consider it a justifiable reason for Apple to allow only exporting between iPhones.

Apple is syncing passkeys to iCloud, presumably so they can be synced between devices and restored if a device is lost/destroyed. That's an export option, and iCloud syncing/restoration between phones is vulnerable to phishing attacks, but Apple has decided that the user experience without iCloud backup would be so bad that they're excusing the extra risk that users have their iCloud account phished and their keys synced to an attacker's phone.

> Which choice has a higher precedence when serving the market of "non-technical mobile phone users"?

In Apple's case, they have decided that allowing users to recover accounts easily is more important for non-technical users than protecting them from export phishing attacks. They've very explicitly said here that they think that allowing export is more important than preventing phishing.

We can debate whether Apple made a good choice with that, but having made that choice, there is now no reason for them to say that Android transfers would be a unique security threat.

Post reply on HN