top | item 32775063

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

73 points| fortran77 | 3 years ago |wired.com | reply

89 comments

order
[+] Gareth321|3 years ago|reply
> 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.

[+] mort96|3 years ago|reply
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.
[+] izacus|3 years ago|reply
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.

[+] zxcvgm|3 years ago|reply
The passkeys are only synced across Apple devices, via iCloud keychain. Trying to sign in on another device (e.g. Windows laptop, Android phone) will require scanning a QR code. The devices then establish a secure channel using FIDO caBLE v2 (introduced by Google/Chrome, I believe) to perform the authentication. This ensures the passkeys never leave your Apple device, but can still be used on other devices.

You can see the sign-in user experience here, when they use a non-Apple device: https://developer.apple.com/videos/play/wwdc2022/10092/

[+] huijzer|3 years ago|reply
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
[+] cm2187|3 years ago|reply
What does the passkey database contain? Only the master private key? Or does a private key or token gets generated for every new account I sign up to?
[+] potatototoo99|3 years ago|reply
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.

[+] hammyhavoc|3 years ago|reply
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.

[+] sunaurus|3 years ago|reply
Does anybody understand how passkeys protect against phishing more than OTP codes do? With OTP codes, an attacker can just ask the user to share their code ("please share your 2fa code to authenticate yourself"), surely with passkeys the same attacker could just ask the user to scan the login QR code ("please scan this QR code to authenticate yourself").

Edit: I looked into it a bit more, it seems like it only works if the browser and scanning phone are in bluetooth range. That's definitely pretty good in terms of phishing protection, but a hard dependency on bluetooth would mean this will not work at all on many desktop computers...

[+] red_admiral|3 years ago|reply
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).

The result is that if you are tricked into entering your credentials into google.com.totallynotaphishingsiteipromise.evilsite.com which is doing a man-in-the-middle attack against the real site - maybe with a let's encrypt cert so they can do https on their own domain name - then the authentication token they send to the real google will have the correct signature, but the wrong domain name.

[+] aborsy|3 years ago|reply
Which websites support passwordless authentication (FIDO2 WebAuth)?

Microsoft and eBay, AFAIK. The rest may use U2F as a second factor not the only one.

Also, for recovery you need multiple phones, and you need the websites to support that. It will probably take a while for websites to support this, and even then people are not going to buy and register several phones.

[+] ghusto|3 years ago|reply
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, but good luck getting your grandma to do that.

This is all super-bad because once it becomes unavoidable, Apple controls _your_ access to everything digital. Apple. Let that sink in. This is the company that backed down on encryption when the FBI asked them to. The company that has stronger device lock-in than any you could imagine.

Am I freaking out unnecessarily? Is my reasoning flawed? Genuine question!

[+] stavros|3 years ago|reply
> 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.

[+] illiac786|3 years ago|reply
I agree we won't be able to stop it, but on the up side I think that it will reach a critical mass and apple will get forced to make it interoperable with other platforms.

But between introduction of this feature anf it becoming Cross-Platform, years will go by...

[+] webmobdev|3 years ago|reply
Passkeys are designed to take away further control from you and that is why BigTech are promoting it. Do you really want to tie your digital life to a device?
[+] zorrolovsky|3 years ago|reply
I share that view.

From a usability perspective, Apple's approach is great. From a privacy rights perspective... it's very bad.

It has been proven that big tech firms are in bed with govs, and allow them to violate citizen's rights at their convenience. Is it a good idea to trust them with all your data, accounts, etc? Hell, no.

[+] heavymark|3 years ago|reply
We went from having one password used on most all sites to having unique random passwords for each site saved in a password manager. But of course those are all accessible then via a single , traditional memorable easy to type ‘single’ password. Yes requires access to one’s devices and helps avoid phishing and all other benefits but just interesting. With passkeys assuming one still uses a password manager to manage the keys (since otherwise if your devices were lost or stolen you’d be screwed) then all your passkeys are stil behind a regular memorable easy to type password and a computer password that is also by nature a memorable password, etc. There are again still lots of benefits for the new method and help avoid the most common issues for people currently so none of this is bad but more good to realize you still have a password in general just one to manage them all.
[+] hnbad|3 years ago|reply
Oh, cool, Apple developed a new technology it calls "passkeys". I wonder how they work.

> Under the hood, Apple’s passkeys are based on the Web Authentication API (WebAuthn), which was developed by the FIDO Alliance and World Wide Web Consortium (WC3).

Okay, so Apple didn't develop it.

It's good to see Apple getting on board with web standards like WebAuthn considering how much they are dragging their heels on web standards on iOS but I just wish we could stop reporting on them without framing everything they do as groundbreaking innovation just because a man in a turtleneck sweater would have said so.

Alternative headline:

Apple brings WebAuthn support to iOS 16 and macOS Ventura

[+] catoc|3 years ago|reply
So it's a public- private keypair.

And Apple syncs your private keys between your devices via iCloud?

Or for each account creates a new key pair for each device... based on your iCloud ID?

[+] kleiba|3 years ago|reply
Honest question since I'm not in the loop: what is the problem with passwords that passkeys are trying to solve?
[+] hayst4ck|3 years ago|reply
The idea of authenticating is the presentation of your id, something only you know (a password), and potentially something only you have (2fac).

Passwords have a significant number of problems, the largest one is password re-use, so if your LinkedIn password gets stolen, it might be tried on your e-mail or bank account. The second is that they are hard to generate and then remember or store. This results in short passwords, easy to remember and therefore non random passwords, or written down passwords. Passwords can often be guessed. Passwords are easily forgotten, requiring complex, vulnerable password reset flows or interactions with fallible customer service reps. There are often policies that require inconvenient password resets where the old one is no longer valid. Passwords do not have attached metadata, so you might enter in a password on a website that looks like paypal, but isn't paypal. It's much easier to phish a password. Passwords can also sit on your clipboard after ctrl+c, which might be vulnerable. Passwords less than 9 characters can be brute forced and even passwords less than 12 characters might be vulnerable to state actors, especially if they aren't completely random.

There is an additional nuance between signing something compared to copying something that results in where data that can compromise you exists in memory. Sending a string to a root owned process and getting a signed string back is a bit different than asking a root owned process for a privileged piece of information (a password) and having that copied into your processes memory.

Pass keys mainly attempt to remove a significant amount of the human factor above (remembering, re-use, reset flows, etc.) while increasing overall convenience without sacrificing security.

Rather than providing the current tuple(id, something only you know, something only you have), the idea is you provide (id, something only you are or something only you know, something only you have). Something you are is face or finger id, and the fallback is something you know, which is your pin. Because keys are more or less universally unique and they can be stored in apples secure enclave or in privileged memory they can also work as something you have. If you run something that turns a QR code into raw text, you will find that 2 factor codes are more or less a private key that is saved into an authentication app on a particular device (iirc).

[+] Hamcha|3 years ago|reply
Passwords can be reused and stored on remote servers, if one is compromised, those password are now out there. Passkeys are asymmetric so the actual key is only stored in your keychain and the UX basically prevents reuse
[+] midislack|3 years ago|reply
I'm opting out of these types of schemes. I like passwords.
[+] eyeareque|3 years ago|reply
Does this passwordless future still involve getting a cookie in your browser that can be stolen and used from an attackers machine? If so, we still have a problem to fix.
[+] madjam002|3 years ago|reply
AFAIK Token binding was designed to solve this problem, but was removed from Google Chrome for being too complicated for the benefits it brought.

Not sure if there is anything else in the works.

[+] stavros|3 years ago|reply
How would you propose doing sessions instead?
[+] hayst4ck|3 years ago|reply
> Passkeys work in Apple’s Safari web browser as well as on its devices.

I sure wish apple would be a little bit better of a citizen when it comes to interoperability. Safari only features (which is what I'm assuming this will be based on apples history and the quote) are upsetting. uBlock is the single most important piece of software on my computer and my devotion to it exceeds any and all possible other features.

I would very much like to stop moving from password manager to password manager after they take VC money to corrupt their trust model so they can make money.

From the article:

> Because Apple developed its passkeys based on the FIDO Alliance standards, the passkeys can work across devices and on the web. If you try to log in to one of your accounts on a Windows machine, you’ll have to use a slightly different method since your passkeys won’t be stored on that machine. (If they are saved in an external password manager, you would need to log in to that first).

> Instead, when you log in to a website in Google Chrome, for example, you will have to use a QR code and your iPhone to help you sign in. The QR code contains a URL that includes single-use encryption keys. Once scanned, your phone and the computer are able to communicate using an end-to-end encrypted network via Bluetooth and share information.

I suppose that's not the worst workaround, and the local exchange is pretty clever, but it sure would be nice if this would work with Firefox out of the box.

[+] asplake|3 years ago|reply
What is Apple doing wrong here? Surely it’s a case of Apple being first to implement a standard where other vendors – Firefox included – are expected to follow?

I don’t know what it means for the password managers, but I don't see that it stops you using those either.

[+] Grimburger|3 years ago|reply
> I would very much like to stop moving from password manager to password manager after they take VC money to corrupt their trust model so they can make money.

Use the free and open source one?

[+] herbst|3 years ago|reply
Google recently asked me to connect via Bluetooth to authorize my laptop with my phone. Just that Bluetooth was completely disabled from my laptop and it did not offer any other option.

For some reason the login on Gmail still offered the 'press ok on your phone' method. No idea what I should have done otherwise.

[+] cm2187|3 years ago|reply
But can the private key be exported or can I login only with the help from my Apple™ iPhone? What they describe isn't interoperability, it is 2FA using a phone. Interoperability means they implement a standard and I could migrate my key to an android phone. Is it the case?
[+] sexy_panda|3 years ago|reply
Technically they are not.

iCloud still requires a mail / pass combination to access stored data.