Live data from Hacker News

Apple’s Killing the Password. Here’s Everything You Need to Know

wired.com

71–80 of 99 posts

Re: Apple’s Killing the Password. Here’s Everything You Need to Know

#71
post #70

I feel we're powerless to stop this, since it's an extremely easy sell to normal users. The average iPhone user wouldn't think once, let alone twice, about clicking OK on that shiny new doodad-app, and that's all the critical mass they need. Even if they _were_ to think twice, what are the feasible alternatives? A password manager where you generate passwords for each account? Sure, I do that, you probably do that, b…

> Am I freaking out unnecessarily? Is my reasoning flawed?

Yes, very much so. I don't know about Apple's thing specifically, but WebAuthn is decentralized and open.

Basically how it works is that you have a private key and use that to log in to a site, no other servers or anything else required. I don't know what Apple's implementation specifically has changed, but if it's based on WebAuthn, it can't be much.

Overall, though, if WebAuthn becomes more widespread through this, it's a huge win for everyone involved, as it's more secure than passwords, easier to use, faster, more usable, and more private.

Re: Apple’s Killing the Password. Here’s Everything You Need to Know

#73
post #26

Earlier quoted context omitted.

In words of Tim Cook on the last event: "Just buy an iPhone (or a Mac and an iPad)". Making your experience bad on non-Apple devices is part of the design, not accident.

I worked at Apple and no one is deliberately making the experience bad on non-Apple devices. They just have a million things they want to do, limited resources and so they simply don't prioritise it.

The multi-trillion dollar megacorporation does not have "limited resources" when it comes to interoperability of such a core security feature.

Re: Apple’s Killing the Password. Here’s Everything You Need to Know

#74
> Passkey synchronization provides convenience and redundancy in case of loss of a single device. However, it's also important that passkeys be recoverable even in the event that all associated devices are lost. Passkeys can be recovered through iCloud keychain escrow, which is also protected against brute-force attacks, even by Apple.

> iCloud Keychain escrows a user's keychain data with Apple without allowing Apple to read the passwords and other data it contains. The user's keychain is encrypted using a strong passcode, and the escrow service provides a copy of the keychain only if a strict set of conditions is met.

> To recover a keychain, a user must authenticate with their iCloud account and password and respond to an SMS sent to their registered phone number. After they authenticate and respond, the user must enter their device passcode. iOS, iPadOS, and macOS allow only 10 attempts to authenticate. After several failed attempts, the record is locked and the user must call Apple Support to be granted more attempts. After the tenth failed attempt, the escrow record is destroyed.

> Optionally, a user can set up an account recovery contact to make sure that they always have access to their account, even if they forget their Apple ID password or device passcode.

https://support.apple.com/en-us/HT213305

This just looks like passwords with extra steps and making it harder for customers to leave Apple's ecosystem.

Re: Apple’s Killing the Password. Here’s Everything You Need to Know

#75
post #42

Earlier quoted context omitted.

FIDO authentication, of which webauthn is the successor, works like this: your secret is a signing key for a digital signature cryptosystem. When you authenticate, it signs a message containing various things including the hostname of the site being authenticated to, and because this is under the control of the browser, a phishing site can't fake it easily (also the browser will throw a fit if you're not on https). T…

> then the authentication token they send to the real google will have the correct signature, but the wrong domain name. So a domain hijacking attack is the only possibility? (and made drastically harder for serious websites with Certificate pinning)

Well, if you can get the user to install malware on their computer ("you must update your flash plugin to continue ...") then you could potentially fiddle with their certificate store, or many other things.

Re: Apple’s Killing the Password. Here’s Everything You Need to Know

#78
post #6
post #4

One thing I never understood about this passkeys thing is: how will the passkeys database be kept in sync between your iPhone, your Windows desktop, your Linux laptop and your Android tablet? I've tried to research the topic a bit but everything I've been able to find has been about exporting and importing between ecosystems, but most people don't use only a single company's products.

Apple has a long history of working best together with Apple. For example, the iPod music players only worked with iTunes. I think that Apple hopes that such features cause people to switch more of their electronics to Apple

Uh, iPods could be used with plenty of third-party software, including WinAmp, foobar2000, MediaMonkey. I could go on for another several minutes rattling off names.

Re: Apple’s Killing the Password. Here’s Everything You Need to Know

#79

And I guess when Apple bans my account with no recourse but to shout at Twitter, I'll loose access to all the accounts. No thanks, I'll stick to passwords associated with my own email.

Yes, had this happen with Microsoft for 30+ days, Facebook for 2 months, Google, and my PlayStation Network account.

Too many digital eggs in one digital basket. Losing access to stuff because some algorithm flags you for using a VPN is fucking stupidity.

Re: Apple’s Killing the Password. Here’s Everything You Need to Know

#80
post #42

Earlier quoted context omitted.

FIDO authentication, of which webauthn is the successor, works like this: your secret is a signing key for a digital signature cryptosystem. When you authenticate, it signs a message containing various things including the hostname of the site being authenticated to, and because this is under the control of the browser, a phishing site can't fake it easily (also the browser will throw a fit if you're not on https). T…

> then the authentication token they send to the real google will have the correct signature, but the wrong domain name. So a domain hijacking attack is the only possibility? (and made drastically harder for serious websites with Certificate pinning)

There is not a solid consensus on cert pinning, and for good reason.

https://www.digicert.com/blog/certificate-pinning-what-is-ce...

Post reply on HN