8 ms·

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

73 points by fortran77 4y ago

JennyFacts 4y ago
hayst4ck 4y ago
> 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 4y ago
  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.
  - hayst4ck 4y ago
    I want to use my iCloud keychain as a password manager since the level of trust I've already given apple allows them to acquire most of my passwords (and 2 factor codes) anyway. Safari integrates with it, but there is no Firefox or chrome plugin to do domain based validation or to keep my clipboard sane. Apple has either failed to allow uBlock to function in safari (after which I would consider migrating to safari), failed to write the Firefox integration plugin, or failed to create an API that would allow a third party to build a plugin. While apple can certainly choose to do/not do those things, it is not a happy customer experience.
    - 4ad 4y ago
      > there is no Firefox or chrome plugin to do domain based validation or to keep my clipboard sane. That's Chrome's and Firefox' fault for not using the password autofill APIs: https://developer.apple.com/documentation/security/password_autofill/ https://developer.apple.com/documentation/security/password_... Chrome issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1170065 https://bugs.chromium.org/p/chromium/issues/detail?id=117006... Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1650212 https://bugzilla.mozilla.org/show_bug.cgi?id=1650212 Btw, Chrome used to be able to read from Apple Keychain, but they removed that functionality years ago.
      - deleted 4y ago
        [deleted]
- Grimburger 4y ago
  > 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 4y ago
  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 4y ago
    That would make it impossible to login to anything personal through a locked down device, like a corporate computer. I like the SQRL approach better where the QR code you scan is a url that the phone will connect to directly to do challenge response. That works with any existing browser and computer, whatever the OS or level of locking. [edit] reading other comments, I realised it is necessary to prevent a mitm attack, the iphone needs to have a way somehow to verify the domain from which the QR code has been served.
- cm2187 4y ago
  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?
  - WorldMaker 4y ago
    It's based on Webauthn and other FIDO standards. Private keys can't be exported (because it would defeat some of the features of a "secure enclave"), but other keys can be added to keychains. You should be able to migrate between devices/device-types across the Webauthn and FIDO standards. It's still early days that some of that isn't easy or "complete" yet, but the standards are being built and Apple and Google and Microsoft have all agreed to cooperate on them.
    - cm2187 4y ago
      I am not sure I understand the nuance between exporting a key and migrating the key between devices. Surely if you can do one you can do the other (at least technically/in term of security).
      - WorldMaker 4y ago
        I don't currently know the specifics of the standards, but often key migration means signing and publicly announcing a new device's hardware public key and optionally revoking an older device's hardware public key. The private keys themselves might never leave the hardware secure enclaves (and/or other key escrow services) to do the dance of updating a keychain of public key signatures. The big "advances" in the standards over the last few years have been about moving away from the "classic" PGP/CA style PKI assumption that a user is represented by a single strong key and a hierarchy of owned subkeys and more that a user is represented by a keychain of N keys many more roughly "peers" than hierarchical and in something of a web of trust with each other where N is at least the number of devices the user owns and regularly uses, and often much more than that with various key escrow strategies. I believe the "PassKey" approach uses an escrowed sub-key per-website in many cases so the keychain gets conceptually huge. (Escrowed here is that it is a derived key using data available to some quorum of physical device keys. You can rederive escrowed keys, but you can't export physical device keys that made the escrow data in the first place. You should be able to add new device keys that can share in a quorum to get at that data, but it's a migration dance.) To my knowledge Keybase's breakdowns of how their keychain worked, including subkey escrow and key exchanges are still some of the easiest to read on the subject of how the math works, though I don't think Keybase's "standards" entirely resemble some of the details of the final standards from FIDO, but again I also don't know enough of the specifics of FIDO's standards as I'd like.
- deleted 4y ago
  [deleted]
mort96 4y ago
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.
- charles_kaw 4y ago
- huijzer 4y ago
  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
  - hsbauauvhabzb 4y ago
    And the educated consumer hopes one of these players will push to face and trigger anticompetitive legislation.
    - deleted 4y ago
      [deleted]
  - mort96 4y ago
    Sure, but this is trying to replace passwords. As much as Apple would want it different, there's a whole lot of people who use one Apple device but has other devices from other manufacturers, and surely an industry effort like FIDO to replace passwords would take that into account?
    - JumpCrisscross 4y ago
      > there's a whole lot of people who use one Apple device but has other devices from other manufacturers, and surely an industry effort like FIDO to replace passwords would take that into account? They're not the beachhead. Once the product is tuned for core users, it can be expanded to more complex use cases. This is basic product development, and something Apple gets right.
sexy_panda 4y ago
Technically they are not. iCloud still requires a mail / pass combination to access stored data.
eyeareque 4y ago
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.
- stavros 4y ago
  How would you propose doing sessions instead?
  - eyeareque 4y ago
    This seemed promising but it doesn’t look like it had any traction https://www.rfc-editor.org/rfc/rfc8471 https://www.rfc-editor.org/rfc/rfc8471
- madjam002 4y ago
  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.
aborsy 4y ago
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.
- random42_ 4y ago
  Best Buy already supports it.
sunaurus 4y ago
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 4y ago
  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.
  - sunaurus 4y ago
    I was more worried about attacks where the attacker takes a screenshot of the QR code and sends it to the user while pretending to be a support agent. So the user never even opens any evil site in their browser.
    - thealistra 4y ago
      Scanning a qr code triggers a bluetooth bridge to continue. If a scammer or your mom scans it from someplace else, it won’t work. Good for antiphishing. Bad for oops, left phone at home.
  - 4y ago
deleted 4y ago
[deleted]
potatototoo99 4y ago
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 4y ago
  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.
webmobdev 4y ago
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 4y ago
  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.
- PartiallyTyped 4y ago
  > Do you really want to tie your digital life to a device? Already true for many people. There will be passwordless alternatives given that BitWarden is investing in the tech[1] . [1] https://bitwarden.com/blog/accelerating-value-for-bitwarden-users-bitwarden-raises-usd100-million/ https://bitwarden.com/blog/accelerating-value-for-bitwarden-...
  - webmobdev 4y ago
    > There’s no shortage of security people who will tell you that passwords are broken. It’s also not a coincidence how many of them sell products to supplement or replace passwords. (Microsoft Ruined Passwords, Now Aims for a Passwordless Future: https://puri.sm/posts/microsoft-ruined-passwords-now-aims-for-a-passwordless-future/ https://puri.sm/posts/microsoft-ruined-passwords-now-aims-fo... ).
kleiba 4y ago
Honest question since I'm not in the loop: what is the problem with passwords that passkeys are trying to solve?
- Hamcha 4y ago
  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
  - kleiba 4y ago
    Thanks. I'm still not following 100%, though. Is the problem that some providers foolishly store users' passwords in clear text, or that some providers allow passwords whose hashes are easy to reverse?
    - harperlee 4y ago
      Both, plus people reuse passwords for random websites that might be malignant, plus they share them through social attacks, plus they put them in Post-its, plus they use easily guessable or brute-forceable passwords…
- hayst4ck 4y ago
  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).
heavymark 4y ago
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.
ghusto 4y ago
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 4y ago
  > 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.
  - ghusto 4y ago
    Isn't it the case that this key is stored in your Keychain though? Keychain data lives on Apple's servers, no?
    - stavros 4y ago
      I'm not sure where this specific key is (in Apple's implementation), but WebAuthn doesn't care where the key lives. Mine is in a Yubikey, I think/hope that will work, if the implementation is "plain" WebAuthn.
      - 4y ago
catoc 4y ago
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?
Gareth321 4y ago
> 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 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.
evelynsalt 4y ago
Tyndale 4y ago
hnbad 4y ago
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
midislack 4y ago
I'm opting out of these types of schemes. I like passwords.

73 points by fortran77 4y ago

> 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 4y ago
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.
- hayst4ck 4y ago
  I want to use my iCloud keychain as a password manager since the level of trust I've already given apple allows them to acquire most of my passwords (and 2 factor codes) anyway. Safari integrates with it, but there is no Firefox or chrome plugin to do domain based validation or to keep my clipboard sane. Apple has either failed to allow uBlock to function in safari (after which I would consider migrating to safari), failed to write the Firefox integration plugin, or failed to create an API that would allow a third party to build a plugin. While apple can certainly choose to do/not do those things, it is not a happy customer experience.
  - 4ad 4y ago
    > there is no Firefox or chrome plugin to do domain based validation or to keep my clipboard sane. That's Chrome's and Firefox' fault for not using the password autofill APIs: https://developer.apple.com/documentation/security/password_autofill/ https://developer.apple.com/documentation/security/password_... Chrome issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1170065 https://bugs.chromium.org/p/chromium/issues/detail?id=117006... Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1650212 https://bugzilla.mozilla.org/show_bug.cgi?id=1650212 Btw, Chrome used to be able to read from Apple Keychain, but they removed that functionality years ago.
    - deleted 4y ago
      [deleted]
Grimburger 4y ago
> 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 4y ago
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 4y ago
  That would make it impossible to login to anything personal through a locked down device, like a corporate computer. I like the SQRL approach better where the QR code you scan is a url that the phone will connect to directly to do challenge response. That works with any existing browser and computer, whatever the OS or level of locking. [edit] reading other comments, I realised it is necessary to prevent a mitm attack, the iphone needs to have a way somehow to verify the domain from which the QR code has been served.
cm2187 4y ago
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?
- WorldMaker 4y ago
  It's based on Webauthn and other FIDO standards. Private keys can't be exported (because it would defeat some of the features of a "secure enclave"), but other keys can be added to keychains. You should be able to migrate between devices/device-types across the Webauthn and FIDO standards. It's still early days that some of that isn't easy or "complete" yet, but the standards are being built and Apple and Google and Microsoft have all agreed to cooperate on them.
  - cm2187 4y ago
    I am not sure I understand the nuance between exporting a key and migrating the key between devices. Surely if you can do one you can do the other (at least technically/in term of security).
    - WorldMaker 4y ago
      I don't currently know the specifics of the standards, but often key migration means signing and publicly announcing a new device's hardware public key and optionally revoking an older device's hardware public key. The private keys themselves might never leave the hardware secure enclaves (and/or other key escrow services) to do the dance of updating a keychain of public key signatures. The big "advances" in the standards over the last few years have been about moving away from the "classic" PGP/CA style PKI assumption that a user is represented by a single strong key and a hierarchy of owned subkeys and more that a user is represented by a keychain of N keys many more roughly "peers" than hierarchical and in something of a web of trust with each other where N is at least the number of devices the user owns and regularly uses, and often much more than that with various key escrow strategies. I believe the "PassKey" approach uses an escrowed sub-key per-website in many cases so the keychain gets conceptually huge. (Escrowed here is that it is a derived key using data available to some quorum of physical device keys. You can rederive escrowed keys, but you can't export physical device keys that made the escrow data in the first place. You should be able to add new device keys that can share in a quorum to get at that data, but it's a migration dance.) To my knowledge Keybase's breakdowns of how their keychain worked, including subkey escrow and key exchanges are still some of the easiest to read on the subject of how the math works, though I don't think Keybase's "standards" entirely resemble some of the details of the final standards from FIDO, but again I also don't know enough of the specifics of FIDO's standards as I'd like.
deleted 4y ago
[deleted]

mort96 4y ago

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.

charles_kaw 4y ago
huijzer 4y ago
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
- hsbauauvhabzb 4y ago
  And the educated consumer hopes one of these players will push to face and trigger anticompetitive legislation.
  - deleted 4y ago
    [deleted]
- mort96 4y ago
  Sure, but this is trying to replace passwords. As much as Apple would want it different, there's a whole lot of people who use one Apple device but has other devices from other manufacturers, and surely an industry effort like FIDO to replace passwords would take that into account?
  - JumpCrisscross 4y ago
    > there's a whole lot of people who use one Apple device but has other devices from other manufacturers, and surely an industry effort like FIDO to replace passwords would take that into account? They're not the beachhead. Once the product is tuned for core users, it can be expanded to more complex use cases. This is basic product development, and something Apple gets right.

sexy_panda 4y ago

Technically they are not. iCloud still requires a mail / pass combination to access stored data.

eyeareque 4y ago

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.

stavros 4y ago
How would you propose doing sessions instead?
- eyeareque 4y ago
  This seemed promising but it doesn’t look like it had any traction https://www.rfc-editor.org/rfc/rfc8471 https://www.rfc-editor.org/rfc/rfc8471
madjam002 4y ago
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.

aborsy 4y ago

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.

random42_ 4y ago
Best Buy already supports it.

sunaurus 4y ago

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 4y ago
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.
- sunaurus 4y ago
  I was more worried about attacks where the attacker takes a screenshot of the QR code and sends it to the user while pretending to be a support agent. So the user never even opens any evil site in their browser.
  - thealistra 4y ago
    Scanning a qr code triggers a bluetooth bridge to continue. If a scammer or your mom scans it from someplace else, it won’t work. Good for antiphishing. Bad for oops, left phone at home.
- 4y ago

deleted 4y ago

[deleted]

potatototoo99 4y ago

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 4y ago
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.

webmobdev 4y ago

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 4y ago
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.
PartiallyTyped 4y ago
> Do you really want to tie your digital life to a device? Already true for many people. There will be passwordless alternatives given that BitWarden is investing in the tech[1] . [1] https://bitwarden.com/blog/accelerating-value-for-bitwarden-users-bitwarden-raises-usd100-million/ https://bitwarden.com/blog/accelerating-value-for-bitwarden-...
- webmobdev 4y ago
  > There’s no shortage of security people who will tell you that passwords are broken. It’s also not a coincidence how many of them sell products to supplement or replace passwords. (Microsoft Ruined Passwords, Now Aims for a Passwordless Future: https://puri.sm/posts/microsoft-ruined-passwords-now-aims-for-a-passwordless-future/ https://puri.sm/posts/microsoft-ruined-passwords-now-aims-fo... ).

kleiba 4y ago

Honest question since I'm not in the loop: what is the problem with passwords that passkeys are trying to solve?

Hamcha 4y ago
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
- kleiba 4y ago
  Thanks. I'm still not following 100%, though. Is the problem that some providers foolishly store users' passwords in clear text, or that some providers allow passwords whose hashes are easy to reverse?
  - harperlee 4y ago
    Both, plus people reuse passwords for random websites that might be malignant, plus they share them through social attacks, plus they put them in Post-its, plus they use easily guessable or brute-forceable passwords…
hayst4ck 4y ago
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).

heavymark 4y ago

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.

ghusto 4y ago

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 4y ago
> 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.
- ghusto 4y ago
  Isn't it the case that this key is stored in your Keychain though? Keychain data lives on Apple's servers, no?
  - stavros 4y ago
    I'm not sure where this specific key is (in Apple's implementation), but WebAuthn doesn't care where the key lives. Mine is in a Yubikey, I think/hope that will work, if the implementation is "plain" WebAuthn.
    - 4y ago

catoc 4y ago

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?

Gareth321 4y ago

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

evelynsalt 4y ago

Tyndale 4y ago

hnbad 4y ago

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

midislack 4y ago

I'm opting out of these types of schemes. I like passwords.