[HN Gopher] Passkeys now support external providers
___________________________________________________________________
Passkeys now support external providers
Author : jsmith99
Score : 246 points
Date : 2023-06-06 07:29 UTC (15 hours ago)
(HTM) web link (developer.apple.com)
(TXT) w3m dump (developer.apple.com)
| garganzol wrote:
| I'm totally in if passkeys come without middle men, especially
| like Google and Apple. Otherwise I'm totally out. No trust in
| these guys, they are as capricious as Roman emperors and will
| eventually do their usual stuff: lock in and collusion.
| yomlica8 wrote:
| I've got a big problem with the attestation feature even
| existing in the spec. I know Apple plans to "zero it out" but
| if that changed sites could lock out non approved devices. I'd
| vastly prefer it wasn't part of the spec at all rather than
| relying upon the whims of a single megacorporation. If they
| ever drop that cover things will gradually become defacto
| locked to middlemen anyway.
| garganzol wrote:
| Exactly. Middle men are not needed. Passkeys can and should
| be handled by an open specification. In this way, passkeys
| will be decentralized and can be supported by anyone and
| everywhere.
|
| Users should decide by themselves where they want to store
| the authenticator: be it a separate device or a password
| manager running on their computer. Authenticator is just an
| algorithm that uses key material from elsewhere (biometrics,
| master password, whatever user prefers) to perform the
| authentication.
|
| Tying the whole thing to a couple of corps is cringy and
| creepy at the same time. There must be an open standard where
| everyone can participate.
| danShumway wrote:
| This is a great point. I'm really happy about Apple's plans,
| but I have a hard time taking it at face value that there's
| nothing to worry about here if there's resistance to putting
| that plan into the spec itself.
|
| Because I start to get suspicious any time a company says,
| "we're not going to do X, but we absolutely refuse to commit
| in any meaningful way to not doing X."
|
| There's an implication there. I feel the same way about
| syncing, honestly:
|
| "Everyone is going to support 3rd-pary sync."
|
| "Can we put it in the spec that they have to?"
|
| "Well, that would be overreaching..."
|
| I think there are a lot of people who have genuinely good
| intentions, but it still makes me pretty nervous. If we could
| just trust every company to magically work things out and be
| compatible with everyone, we wouldn't need industry
| specifications in the first place. I think it's appropriate
| to try and standardize the baseline mechanisms users should
| have to control their keys and preserve their privacy.
| dethos wrote:
| Good news. Lock-in was one of the biggest issues with passkeys. I
| think we will see a bunch of well known password managers adding
| passkey support soon.
|
| Is there any standard for this integration/interoperability? What
| about moving from one provider/app to another?
| ndjdhdidve wrote:
| you fell for it.
|
| the article says nothing to that end. still full locked in.
|
| the UI will allow implementations... via app stores approved
| apps using their OS apis. for sure.
| jsmith99 wrote:
| Originally seen via
| https://reddit.com/r/Bitwarden/comments/141uxz1/iosipados_17...
|
| This is big news as vendor lock in and inability to use our own
| sync was one of the biggest issues bought up whenever Passkeys
| are discussed. Apple are now allowing external sync fabrics such
| as password managers.
| Ajedi32 wrote:
| Yeah, this is awesome. The devil's in the details though, do we
| know anything about exactly _how_ they plan to support external
| providers? I 'm cautiously optimistic; at least on the surface
| this sounds like exactly what I was hoping for.
| ezfe wrote:
| > Password manager apps can save and offer passkeys on iOS,
| iPadOS, and macOS.
|
| No reason to believe this would work differently than the
| existing affordances for 3rd party apps to offer passwords,
| which works well today
| awinter-py wrote:
| I mean apple has a tried and true playbook for supporting
| external providers, I'm not worried
|
| charge them random % of revenue, force them to funnel all
| transactions through apple, let random junior employees
| disable the 3rd party's bugfixes for reasons(tm), and
| eventually refuse to license new entrants because there are
| too many flashlight apps
|
| I'm not worried
| danShumway wrote:
| I'm very eager to see what Bitwarden does here, they're the
| first big[0] name that's actually Open Source that's on board.
| It's hard to take passkeys seriously when the vast majority of
| implementations are completely proprietary.
|
| Seeing what Bitwarden comes up with and seeing whether or not
| the process for self-hosted Bitwarden accounts is actually
| seamless and works on platforms like desktop Linux -- to me,
| that's going to be a really big test of whether passkeys can
| credibly be claimed to be actually cross-platform.
|
| [0]: I do think there have been some smaller proof-of-concepts,
| but... there's a difference of scale here.
| devsda wrote:
| > Apple are *now* allowing external sync
|
| There is no guarantee that this will be permanent. It can be
| revoked citing x number of reasons.
|
| Also, lets wait until the implementation details are available.
| If it requires providers having a native app on the device
| where Apple has control on who and what to allow, there's only
| an illusion of choice.
| cassianoleal wrote:
| Pretty sure "now" in this context means "starting now".
|
| Once people start relying on this, it will take a lot more
| than just citing reasons to revoke it without causing massive
| blowback.
| devsda wrote:
| I don't mean revoking 3rd party support entirely.
|
| We don't know the implementation details yet but if this
| requires Apple vetting and whitelisting the providers then
| it can always be revoked for technical, business, political
| or any other reasons.
| cassianoleal wrote:
| I would expect this to be modelled after the API for
| password managers, in which case there's no vetting or
| whitelisting. Or if there is, it's pretty open as a lot
| of software uses it, both closed and open source.
| jiggawatts wrote:
| My method for judging the quality of software: Read the latest
| release notes, negate every statement, and think to yourself:
| "They were fine with it being like this until now."
|
| Passkeys have been advertised as a superior replacement to
| passwords, but really fundamental issues remain unaddressed.
|
| I have one (1) Windows PC and one (1) iDevice. Can I get these to
| sync? Will both be able to log me in to a Google Account? Or do I
| need an Android phone for that? Can I use an iDevice to
| authenticate with an Azure AD app? Can I recover the passkeys on
| a lost iDevice without having to pay Apple for a new device to
| restore the backup? Etc...
|
| I guarantee many more release notes that could be summarised as:
| "Now supports a common scenario!"
| 9dev wrote:
| Easy. Think of passkeys as per-device credentials. You can have
| (1) windows PC credential and (1) iDevice credential, and
| register both with Google and Azure.
| rickdeckard wrote:
| > I have one (1) Windows PC and one (1) iDevice. Can I get
| these to sync?
|
| "Why? Where's the profit for us in that case?"
| arnarbi wrote:
| > Will both be able to log me in to a Google Account? Or do I
| need an Android phone for that?
|
| Yes and no, respectively.
| echeese wrote:
| > I have one (1) Windows PC and one (1) iDevice. Can I get
| these to sync? Or do I need an Android phone for that?
|
| Yes. In Chromium-based browsers, at least. Your browser will
| display a QR code which you scan with your phone. Your phone
| will display a list of accounts you can sign in with, you
| select one, authenticate, and you're logged in. Firefox support
| isn't here yet.
| danShumway wrote:
| Passkey proponents have played really fast and loose with the
| word "sync" in my experience. No reasonable outside observer
| would call this syncing, it's cross-device sign-in.
|
| It's like saying you can sync your OTP-provider to your
| desktop computer because when you go to log into a website
| you manually copy the code into a form. That's not how most
| people understand the word "sync."
|
| What people are excited about here (assuming the details are
| good) is _actual_ sync -- the ability to take your iCloud
| passkeys and literally move them to a new device outside of
| Apple 's ecosystem as a mass operation rather than site-by-
| site. And that's really good and I'm excited about it and I
| hope that it addresses all of my issues. But its frustrating
| to see people still misrepresenting what's capable with the
| ecosystem today even under a positive announcement that
| signals that the actual concerns are getting addressed.
|
| It's so weird, I don't know of any other open standard I've
| seen where the proponents are so creative about acting like
| the ecosystem already supports things that aren't supported
| yet, and it's a huge reason why I remain skeptical of the
| passkey ecosystem -- because there are good-faith actors
| telling me to trust them but they're surrounded by people who
| are straight-up giving incorrect answers to basic questions
| like "is sync supported." I don't get it. If the limitations
| are going to be addressed, what is the value in pretending
| that they don't exist? How does the ecosystem benefit from
| that? All it does is decrease trust, to the point where I
| feel like I need to double-check every assurance I get from
| FIDO advocates to make sure that they're not redefining
| words.
| jiggawatts wrote:
| That's not what I mean by "sync". If I don't have the phone
| with me, I can't authenticate.
|
| Also, I use Firefox exclusively.
|
| This is precisely what I mean: common scenarios are not yet
| supported.
| abiro wrote:
| Any details on how passkeys sync using external providers?
| miles wrote:
| There is only this blurb to go on at the moment:
|
| "Passkeys can now be synced using external providers..."
|
| so it's hard to say exactly what it will mean for user control
| and choice. Which external providers? Will users be able to
| access and store their own private keys in compatible apps of
| their choosing? If so, aren't we largely back to passwords?
| danShumway wrote:
| > aren't we largely back to passwords?
|
| Key based authentication is a huge security improvement over
| passwords (especially for reducing phishing risks) even without
| the device-bound restrictions.
|
| I'm strongly opposed to hardware-bound keys as a mass standard
| for most users, but key based authentication is great. One big
| advantage is that during the login process, sites "prove" their
| identity to you.
|
| This is a security improvement that you could previously only
| really get with browser extensions and password managers, and
| even there it wasn't _great_ because those extensions didn 't
| work consistently across all sites and often failed at
| autofill, so a website failing to pull up your password manager
| might not actually be interpreted as a red flag. And there are
| other advantages too around account security for service
| providers, etc... none of which require attestation or
| hardware-bound keys.
| tehbeard wrote:
| > aren't we largely back to passwords?
|
| A password is a shared secret. Even if it's hashed on the
| server side, one could brute force it if a weak algorithm is
| used, or MiTM the service to get the plaintext when the user
| logs in.
|
| Passkeys / webauthn utilizes public key cryptography. I'm only
| ever giving them a (by the spec, unique to the combo of me and
| the site in question) public key to which I hold the private
| key pair.
|
| Authentication doesn't involve transmission of these, it's
| challenge based where you prove you have access to the
| corresponding private key.
| ndjdhdidve wrote:
| 1. article says nothing about external identity providers. which
| is what everyone here wants. still fully locked in.
|
| 2. it only hints at the UI being open to other apps, approved in
| the app store of course, using their new undocumented api
|
| 3. the sharing features will probably happens over their central
| control. not over the UI implementers.
|
| so many misconceptions in these comments. specially mixing up
| passkeys with in device keys
| zamadatix wrote:
| It starts out saying "Passkeys can now be synced using external
| providers", how does it say nothing about external providers?
| I'd love to see the detail as well but, lacking that, there is
| nothing in the article that says these takes are correct and
| the others misconceptions either.
| oulipo wrote:
| Interesting, but can someone tell us what this implies wrt.
| authorities? If someone gets your iPhone and forces you to press
| your finger on the TouchID, he gets all your passwords no? While
| with a general master password you could just pretend to have
| forgotten it?
| WorldMaker wrote:
| In good news, a somewhat recent CBP case recently ruled in
| favor of Touch ID coercion needing a warrant and _may_ be the
| start of a wave of change in court precedents to stop
| authorities from abusing biometric loopholes. One court win
| does not set a new precedent, of course, but it is hope that
| change may come.
| drtgh wrote:
| Whichever way you look at it, in every sense, password managers
| are a really bad, bad idea.
|
| Besides that, it is not needed to force you to press your
| finger; the delinquent needs only to have access to the device
| for to fool the sensor with a brute force, 2 hours in the worse
| of the cases with the simplest techniques. Although its easier
| to take your finger prints from a glass or something you used
| for to avoid the wait, or directly cut your finger if its a
| psychopathic criminal.
|
| And in all the cases, once your fingerprint gets public it gets
| compromised until the end of the times, of course, you can not
| "change the passw".
|
| This without talking about software infection with a remote
| attack.
| misnome wrote:
| > Whichever way you look at it, in every sense, password
| managers are a really bad, bad idea.
|
| Okay, how about, the actual problem they solved: Reusing a
| single, simple password on every site, shared behind an email
| login.
|
| That doesn't sound like a really, really bad idea.
| drtgh wrote:
| At what point did password managers invent the idea of
| using a different password for each account? That is
| computing basics from the beginning. They didn't solve a
| problem, they just increased the lottery prize if the
| master password gets compromised.
|
| Every body can continue down-voting, but that fact is not
| going to change.
| misnome wrote:
| No, the lottery prize is exactly the same: Access to
| every site in the list.
|
| The lottery chances have, however, dramatically changed,
| from no longer relying on the ongoing security practices
| of every single website you have ever signed into once
| being eternally a risk to breaching every single other
| website you have ever signed into.
|
| Perhaps you alone can remember a cryptographically secure
| password for every website. But I'd more suspect your
| downvotes come from the impression you give of apparent
| inexperience combined with what looks like a child-like
| propensity to bluster.
| mariusor wrote:
| > if the master password get compromised.
|
| ... and if a copy of the password wallet has been
| obtained.
| tzs wrote:
| > At what point did password managers invent the idea of
| using a different password for each account?
|
| They didn't invent the idea.
|
| They just made it useable for people who have a lot of
| different accounts.
|
| I've got nearly 500 accounts, and based on a comment
| thread a while back where someone asked here how many
| accounts people have in their password managers I'm on
| the low side.
| UncleMeat wrote:
| Password managers did not invent this idea, but we can
| observe people consistently reusing passwords when they
| don't have a password manager. It is just undeniable at
| this point that users cannot be expected to consistently
| create strong and unique passwords for each service.
| Lukas_Skywalker wrote:
| I would argue that password managers are not a "in every
| sense a really bad, bad idea" for a lot of reasons.
|
| Let's look at password reuse for example. As soon as you have
| more than a few dozen logins, the possibilities are mostly
| either reusing one or few passwords, or writing them down.
|
| Reusing is objectively bad, and for writing them down, the
| password manager makes it easy to use a really long and
| random password, which would make it tedious to write down.
| drtgh wrote:
| Password managers makes the user life easier, at a big
| price if the master password gets compromised, as all the
| passwords get compromised at same time, in an unified way
| that by other methods would require much more
| specialization and effort for to gather together.
|
| If that passwords are stored in internet even worst, one
| can take for sure those passw-managing servers are juicy
| targets, it is a countdown until the server will get
| compromised.
|
| If the user is only storing the pass of chat forums, I
| think then is one thing the attacker probably will ignore,
| if the reverse engineering of one of those sites using
| user's name is not in the secondary target list.
|
| Anyway, to use a unique password for every server, account,
| etc is a must do from the beginning of time, even for the
| temporal forum one had to register for to use a few
| minutes. It is the first computing directive. It's just the
| password managers are not accomplishing the objective of
| such directive.
| recursive wrote:
| Just because something is a "first computing directive",
| that doesn't mean people do it. If you're capable of
| remembering hundreds of high-entropy passwords, more
| power to you, but that approach doesn't work for most
| people. Password managers are better than reusing
| passwords between services, which in the real world, is
| the alternative.
| notpushkin wrote:
| How do you remember unique, strong passwords for a couple
| dozen sites?
| planb wrote:
| I don't mean this personal, but I find it very very hard to
| deal with people like you in professional contexts. You focus
| on a 0.01% problem and make an absolute statement ("in every
| sense, password managers are a really bad, bad idea"), while
| completely ignoring that for everybody else, password
| managers (and even more so passkeys) will prevent real
| problems like their bank account being emptied.
| Topfi wrote:
| That's a great development. Reducing vendor lock-in removes one
| of the bigger reservations some mentioned in regards to WebAuthn.
| garganzol wrote:
| The development hardly changes anything. Apple (and Google) is
| still a middle man and thus poses a point of failure.
| francislavoie wrote:
| That's great to see! I just tried out 1Password's beta browser
| extension which has passkeys support, and the UX is super
| seamless. Played around with it on https://www.passkeys.io/
|
| I'm really hopeful about this, a lot more than any of the
| previous iterations of the FIDO stuff. I worked at a company that
| was an early adopter/implementer of the original FIDO U2F spec,
| and it had major UX problems, enough that I couldn't see it ever
| being used by the general public (who the heck would carry a USB
| key with them?? and this only works with desktops/laptops, sure
| Bluetooth support, but ehhh), but with this, synced to your
| password manager of choice, that's A LOT better.
|
| The passkey is usable anywhere (signed up on my desktop, hopped
| over to my laptop and signed in there with the same passkey). I
| can't use it from my Android phone yet, but that will come soon
| I'm sure when 1Password adds support to the mobile apps + Google
| does the same as Apple here with adding proper Android
| integration.
|
| On Android I can still only use a USB/NFC/Bluetooth security key,
| or "my lock screen" (i.e. on-device security key, not passkeys)
| so far. If I click on "Sign in with a passkey" it says I have no
| passkeys via an Android system dialog, but if I sign in with my
| email it lets me use my "security key" (i.e. biometric lock
| screen prompt).
| jabbany wrote:
| > who the heck would carry a USB key with them??
|
| Why not? I do this. It's no different from any other physical
| key like a door key, and I keep it on the same keychain too...
|
| > The passkey is usable anywhere (signed up on my desktop,
| hopped over to my laptop and signed in there with the same
| passkey).
|
| I don't see how this conflicts with physical tokens like
| Yubikeys? The tokens help you "remember" the key like how a
| physical door key helps you "remember" the bitting (which is
| the real authentication info).*
|
| Just like passkeys, U2F can also be done using a virtual U2F
| device if you so choose (https://github.com/bulwarkid/virtual-
| fido). And presumably you could create an off-device portable
| token to store passkeys...
|
| The real problem at the end of the day is just consistent
| adoption. There's still a ton of 2FA services that don't accept
| U2F and only use SMS or email codes...
|
| *: This is a simplified take on things but at a high level
| that's what's happening.
| francislavoie wrote:
| > Why not? I do this.
|
| Again, you are not the general public. You're a highly
| technical person. My dad/grandma would never. That's the
| point.
| jabbany wrote:
| Are you saying they don't use any physical keys? That would
| be surprising to me...
|
| I've found it really easy to teach non-technical people how
| to use U2F tokens. Just tell them it's like a door key but
| instead of plugging it in and turning, you plug it in and
| touch. That's all there is. It's been much more intuitive*
| to my older family members than SMS codes (that sometimes
| get lost), authenticator apps (that have a huge list of
| services from which you need to quickly find the one you
| want and type the code), or password managers (that either
| cost money or are difficult to set up across devices).
|
| *: I know this because I've never had to do "tech support"
| for family members that have accounts set up to use U2F
| tokens, but I have had plenty of calls related to "not
| getting the SMS code" or "the (insert brand) password
| manager isn't filling in the password for my account!"
| theshrike79 wrote:
| The difference is that I can know with significant
| certainty that shoving my house key in a random lock
| won't copy the form of my key and send it to a 3D printer
| where a thief will get it and use it to access my house.
|
| How can I know that won't happen when I use my USB dongle
| on a random coffee shop public computer?
| SahAssar wrote:
| You are literally wrong on both cases: A normal key can
| be quite easily copied and a yubikey or similar security
| key cannot be copied.
| jabbany wrote:
| This is exactly what U2F protects you from!
|
| You can actually safely plug U2F tokens into random
| computers and rest assured that the keys inside cannot be
| cloned. This provides security guarantees above and
| beyond that of physical keys! In fact, an untrusted
| computer can't* even MITM the authentication process of
| U2F, unlike with SMS codes! (Of course, an untrusted
| computer could fake the UI to try and exfiltrate other
| info from you, but that's beyond the scope of
| authentication itself.)
|
| The worst a malicious client can do to a U2F token is to
| fry it :-)
|
| *: There's some asterisks here, but if you want to know
| the details check out the U2F spec or this
| https://www.yubico.com/blog/creating-unphishable-
| security-ke... for a more accessible explanation.
| Banking-grade U2F/similar tokens actually behave like
| hardware crypto wallets and will show the auth request
| metadata on an internal screen, in case the device you
| are plugging into is completely untrustworthy.
| UncleMeat wrote:
| Okay.
|
| How is that different from a password? How can you know
| that when you type your password into a random coffee
| shop public computer that the computer isn't running a
| keylogger and sending your credentials to criminals?
| notpushkin wrote:
| > I can know with significant certainty that shoving my
| house key in a random lock won't copy the form of my key
| and send it to a 3D printer
|
| Are you sure? https://www.minutekey.com/products/key-
| copy-kiosk/
| vladvasiliu wrote:
| > who the heck would carry a USB key with them??
|
| > but with this, synced to your password manager of choice,
| that's A LOT better
|
| While I agree with your general point that passkeys are great,
| I strongly disagree with these specific points. It's much
| easier for me to carry a small usb-key everywhere than it is to
| carry a big-ass phone (I often leave it at home) or my own
| computer.
|
| With a yubikey on my keychain, I can log into my company's
| AzureAD from any computer. In a pinch, this also works on a
| phone if it has an NFC reader. It used to work fine on my
| iphone 7.
|
| Another use case is specifically not wanting anything company-
| related on my own computing device. My personal phone isn't
| enrolled in the company's AzureAD, I don't have their 1passwork
| vault there, etc.
| francislavoie wrote:
| I'm talking about the "personal use" usecase and not the
| professional/business usecase. I agree with the value of
| security keys as being a physical token with low/no risk of
| leaking. But for personal use there's no way I can make that
| work for me day-to-day, even less of a chance I could get my
| parents bought-in on that idea. And I've tried, as someone
| who actually developed software to interface with this tech
| directly. I always have my phone with me, but if not, I can
| always login to my cloud-synced password manager in a pinch.
| (Worth mentioning, I don't have the same paranoia as some
| regarding cloud-synced vaults when done right, big reason I
| left that aforementioned company).
| Hamuko wrote:
| I did a WebAuthn implementation at work and the UX for WebAuthn
| was fucking awful. Especially on macOS, every browser had a
| completely separate implementation of WebAuthn, and if you used
| the Touch ID as a WebAuthn device, you basically could not see
| it anywhere and deleting it was also a pain in the ass. On
| Chrome, you basically had to just delete all of your passwords
| for the last N days to get rid of them.
|
| On Windows, I think all browsers handled it centrally with
| Windows Hello, but even there the WebAuthn devices just kinda
| disappear into the ether once you register them, and deleting
| them had to be done through the command-line. There were also
| weird ass bugs where the UI would behave completely differently
| depending on whether or not you had Windows Hello login in use,
| so websites would need to engineer around it.
|
| Haven't played around with passkeys key, but I imagine the only
| direction to go is up.
| francislavoie wrote:
| Yeah. With 1Password it's _just another item_ like a
| password, but named "passkey". And in the browser when you
| set it up or use it, you get a little overlay on the website
| in the top-right and you click on it. That's it. Super
| simple, no faff, full visibility.
| ckastner wrote:
| Of all the recent publications with regards to passkeys, FIDO2,
| WebAuthn, etc., finally there's one with a simple and concise
| summary of the benefits:
|
| > Strong credentials. Every passkey is strong. They're never
| guessable, reused, or weak.
|
| > Safe from server leaks. Because servers only keep public keys,
| servers are less valuable targets for hackers.
|
| > Safe from phishing. Passkeys are intrinsically linked with the
| app or website they were created for, so people can never be
| tricked into using their passkey to sign in to a fraudulent app
| or website.
| labcomputer wrote:
| > Safe from server leaks. Because servers only keep public
| keys, servers are less valuable targets for hackers
|
| That's not quite true, though. What is true is that the server
| does not have a _plaintext_ copy of your private keys. That's a
| crucial difference.
|
| The server has an encrypted copy of your private key, which
| your with token decrypts with its private key. That is how a
| usb key can store an _unlimited_ number of U2F credentials: The
| USB key isn't storing them at all. They are stored on the
| server you are authenticating to.
|
| What this also means is that if there is a backdoor in the
| crypto algorithm used by your token and an attacker gets a copy
| of the server's U2F credentials, then you are at risk of having
| your private key stolen.
| JulianK wrote:
| The idea behind private keys is that they are private and
| never sent anywhere so I believe your assertion that the
| server knows anything about your private key is incorrect.
|
| Here's a link to Yubico with a visual diagram of how passkeys
| work: https://developers.yubico.com/Passkeys/How_passkeys_wor
| k.htm...
|
| But fundamentally it's very similar to how all public/private
| stuff works. You send people the public key and sign stuff
| with the private key.
| notatoad wrote:
| i'm pretty sure you're wrong. or at least, you're directly
| contradicted by the apple docs, which say "The other key is
| private, and is what is needed to actually sign in. The
| server never learns what the private key is."
| https://support.apple.com/en-ca/HT213305
|
| the basic claim about being able to store "infinite" passkeys
| on a USB is also directly contradicted by the yubikey docs,
| which say they can store 25:
| https://www.yubico.com/blog/a-yubico-faq-about-passkeys/
| [deleted]
| DANmode wrote:
| https://en.m.wikipedia.org/wiki/FIDO2_Project
| 9dev wrote:
| This is just plain wrong. The server only ever stores your
| public key, private keys are stored on the clients.
| Everything else would defeat the entire purpose.
| chimpoftheages wrote:
| No, it is technically correct for nondiscoverable mode.
| Naturally, there should be low value in breaking the
| opacity of the stored key as it should be a private key
| only used with the server that holds it. (But it would
| still mean many sites requesting that you replace any token
| found to have such a defect.)
| lost_tourist wrote:
| Are they safe from Apple shutting down your account? Seems like
| an all your eggs in one basket problem, with passwords I can
| back up and always retrieve them locally.
| TheNewsIsHere wrote:
| Passkeys were designed from the start to enable portability
| if desired. The rollout has been a mess though, so it's been
| very effective in causing a lot more confusion than needed.
|
| From the page:
|
| > What's new
|
| > Now people can share passwords and passkeys from iCloud
| Keychain with their trusted contacts. *Password manager apps
| can save and offer passkeys on iOS, iPadOS, and macOS*.
| Enterprises can take advantage of passkeys thanks to Managed
| Apple ID support for iCloud Keychain. And administrators can
| manage which devices passkeys sync to using Access Management
| controls in Apple Business Manager and Apple School Manager.
|
| Emphasis is my own.
|
| Dashlane and 1Password both support passkeys, and you can
| export your data from both services. I am certain more will
| follow as more third party support arrives for managing
| passkeys.
| kps wrote:
| That emphasized sentence is key. Pessimistically, it could
| mean that password managers can 'save' only to the Apple OS
| passkey store, acting as an intermediary transport, without
| being able to provide cross-platform vendor-agnostic
| sharing.
| TheNewsIsHere wrote:
| 1Password previously announced that mobile support for
| passkeys stored in 1Password was on its way later. I
| assume they had advanced knowledge of this announcement.
|
| I totally understand a pessimistic reading. In trying to
| roll out passkeys to everyone at once, and doing a poor
| job of UX and documentation clarity, all the major
| players bungled the 2022 launch. Not having some
| portability out of the gate absolutely caused unnecessary
| distrust about passkeys.
|
| But I strongly believe this won't become a vendor lock-in
| playground.
|
| I have replied a lot about passkeys. I should disclose a
| former employer works in this space, but I'm not
| advocating for any particular company or product here,
| and I no longer have any inside knowledge relevant to the
| topic that isn't already public.
|
| Edit: grammatical typo; disclosure clarification
| kps wrote:
| That's good to hear. If cross-platform sync is possible,
| passkeys are definitely a better option for the 95% of
| crud that currently lives in browsers' password managers.
| TheNewsIsHere wrote:
| You mean this is annoying?
|
| google.com (never save)
|
| google.com (Jane.Doe)
|
| google.com (Jane.Doe) (Grandma use this one)
|
| google.com (never save)
|
| google.com (Jane.Doe) (password missing)
|
| google.com (Jane.Doe) *Your password may have been
| exposed in an online breach.
|
| I fully agree with you. Passkeys solve a lot of usability
| problems, especially for the less technically adept,
| while solving so many password problems.
|
| Edit: formatting nightmares
| ljlolel wrote:
| The last one is a problem for a lot of use cases. Lots of sites
| have different domains (also for example when HBO max renamed
| to max).
|
| Plaid also relies on entering bank passwords on neobank sites
| and is widely used.
| madeofpalk wrote:
| > Plaid also relies on entering bank passwords on neobank
| sites and is widely used.
|
| This is an anti-pattern, and is not worth supporting in new
| tech that's supposed to be "secure first".
|
| We already have tech for delegating authorization.
| scott00 wrote:
| Plaid isn't a solution to a technical problem. It's a way
| to deal with the fact that banks don't want their customers
| to bypass their websites/apps and the cross-selling ads
| within.
| TheNewsIsHere wrote:
| In their defense, Plaid also very quickly demonstrated
| why you might not want an online bank access free for
| all. At least in privacy-centric terms.
| tialaramex wrote:
| Sure, the Big Boss will be extremely annoyed. Thanks to their
| innovative branding strategy they've grown New Brand from $0
| to $150M revenue in just the first year of operation, a huge
| success. Did it cannibalise customers from Old Brand, which
| was $180M revenue and now is just $1M of residual revenue on
| its way to closing down? Sure, but don't do arithmetic, focus
| on the tremendous leadership.
|
| If authentication systems, like customers, think New Brand is
| just pointlessly confusing because it's different from Old
| Brand for no good reason, that undermines Big Boss's amazing
| strategy and makes it look like something a toddler would
| try, and that's not OK.
|
| However the nice thing when you have players like Google is
| that their technical people have got license from above to
| say "Fuck off" on technical issues without somebody who
| doesn't know the first thing about it overruling them because
| their golf buddy asked them to. So you're not going to see a
| way to override this behaviour and thus allow phishing even
| though I'm sure HBO execs would think that's fine.
|
| In terms of practical effect, what that means is that when
| they use WebAuthn outfits like HBO end up needing to keep
| login.old-brand.example working, even though supposedly old-
| brand.example was a completely different product and is now
| dead, because that's how users actually log into new-
| brand.example as they are in reality the exact same product.
| gjulianm wrote:
| AFAIK, passkeys aren't really linked to a domain. It's old-
| school public-key verification, the server stores your public
| key and uses it to verify the signature of a challenge they
| send to your device on login. As long as the different
| domains/apps can share the public key you should be able to
| login.
|
| And for things like Plaid, I think banks are moving towards
| OAuth-style permissions, where you login to your bank and
| authorize the connection. Under the hood, Plaid or other app
| can connect to the bank with limited permissions using API
| authorization keys. It's a different problem, I think.
| tialaramex wrote:
| > AFAIK, passkeys aren't really linked to a domain. It's
| old-school public-key verification, the server stores your
| public key and uses it to verify the signature of a
| challenge they send to your device on login. As long as the
| different domains/apps can share the public key you should
| be able to login.
|
| In principle the fancier systems with a user interface
| _could_ add a feature where you can change the DNS names
| associated with a key it 's storing. That sounds like a
| monumental pain in the backside, and of course the primary
| consequence would be it increases phishing because now your
| users can be tricked into allowing it - but sure, they
| could do that.
|
| For simpler devices like a Yubico Security Key, there is no
| such interface, they aren't storing any keys so there's no
| way to make such an association. The keys are bound to the
| DNS name and are actually stored (encrypted) by the sites
| you're actually authenticating to. So without a matching
| DNS name they're intentionally just useless nonsense.
| [deleted]
| vladvasiliu wrote:
| I may be wrong here, but since the yubikey and similar
| don't actually store anything site-specific, it means
| they just respond to a challenge, right? What they prove
| is that they own a specific private key.
|
| So if the website bundles its domain in the challenge, it
| can make sure that the client signed the challenge for
| itself, and the client can verify that it signs the
| challenge for the current domain.
|
| So now, if the service's domain were to change, it would
| presumably be aware of it and incorporate it in the new
| challenge, which the client would sign, since it's
| browsing the correct domain, with the same private key
| used before.
|
| Is this not how it works?
| heavyset_go wrote:
| FIDO2 allows for things like resident keys, which the
| Yubikey can only hold so many of.
|
| The Yubikey can act in HMAC challenge mode, though, but
| that's not the mode used on the web.
| TheNewsIsHere wrote:
| Most web based services don't seem to be using the
| discoverable credentials either. So far only my Apple ID
| and Azure AD accounts are utilizing those.
| [deleted]
| tialaramex wrote:
| Nope, but I can see why you'd expect that because the
| actual design is very clever and so it's not obvious how
| this could work.
|
| What's inside the cheapest authenticators isn't a private
| key, after all they present a unique random public key
| for every single enrolment, so that couldn't work if they
| held a single private key. Instead it's a _symmetric_ key
| (e.g. AES-256). Lets see how that 's done:
|
| When you enrol at a site, the authenticator mints a
| _completely random_ new public /private key pair (with
| Elliptic curve crypto it's really easy to pick random key
| pairs because with a few bit ops any random bits become a
| random key) and after signing the enrolment step, the
| authenticator encrypts its new private key using that
| secret symmetric key and the DNS name in an authenticated
| encryption mode and provides that encrypted value too.
|
| The browser, with the authenticator's help, puts together
| the final enrolment document, with a signature and it
| includes that encrypted private key as a Unique
| Identifier. All the Unique Identifiers in the protocol
| are huge random looking numbers, so the encrypted key
| blends right in with that.
|
| For a web site, you need to store the public key
| (obviously) and this unique unique identifier value. You
| have to do that for everybody, anyway, it's mandatory.
| You can't decrypt the identifier even if you were sure
| it's encrypted, you don't know the key, so all you can do
| is play it back when you want a user to authenticate.
|
| When it's played back, the authenticator takes the web
| site's DNS name, plus its own secret key, and decrypts
| the identifier to get back its private key, which it can
| now use to sign authentication messages. Of course if the
| DNS name is wrong, the decryption fails, which is exactly
| the same thing as happens if you try to use the wrong
| authenticator, or you're being phished, or a dozen other
| things - the authentication can't succeed.
| detourdog wrote:
| It is essentially kerberos only Apple has managed to grow a
| coherent ticketing system for all hardware, services, and
| users. Each Developer essentially has their own ticket
| signing system. Apple can revoke any ticket at any time and
| a developer can revoke their own tickets.
| danieldk wrote:
| _AFAIK, passkeys aren 't really linked to a domain. It's
| old-school public-key verification, the server stores your
| public key and uses it to verify the signature of a
| challenge they send to your device on login. As long as the
| different domains/apps can share the public key you should
| be able to login._
|
| The credentials are scoped to a relying party, which must
| be equal to the domain or registrable domain suffix:
|
| https://www.w3.org/TR/webauthn-2/#scope
|
| If this wasn't the case and it was old-school public-key
| verification, it would still be vulnerable to phishing,
| since the phishing site could just forward the challenges.
| ElFitz wrote:
| I've never understood Plaid. Given what they do, they can't
| possibly encrypt the credentials they're given, let alone
| hash them, can they?
|
| And considering how most banks are set up, we are talking
| about the user's only set of credentials. Which have the
| user's permissions.
|
| Then there are all these fintech startups saying that they're
| secure because they use Plaid to access all your financial
| life, all to provide you with centralised analytics or
| supposed financial advice.
|
| Sure it's probably (one can hope) more secure than every
| single one of them rolling out their own hacked together
| equivalent. But still.
|
| Am I missing something?
| squeaky-clean wrote:
| If your bank doesn't use something like OAuth they do store
| your login credentials. If your bank does use OAuth or
| similar Plaid still has to store the access token, which
| hopefully your bank has given a read-only scope.
|
| They can definitely encrypt the credentials, they just also
| have to make it simple for their backend to decrypt it when
| they need access to your bank, which defeats a lot of the
| security there. (It's still better than just storing it in
| plaintext).
|
| https://support-my.plaid.com/hc/en-
| us/articles/4410324401047...
|
| > In other cases, when you link a financial institution to
| an app via Plaid, you provide your login credentials to us.
| We store those credentials and use them to collect the data
| to power the services you've chosen and, when requested,
| securely share it with the app you're using and establish a
| secure connection that you control. We then help keep your
| data safe and private with best-in-class encryption
| protocols.
| masklinn wrote:
| I don't think you are, plaid is a horrible and completely
| insecure work around banks not providing programmatic
| access.
|
| I'm not sure how it even works with second factors (I've
| never looked).
| squeaky-clean wrote:
| If you have 2 factor enabled for each login you get told
| your account settings are incompatible with Plaid and
| have to disable 2fah. If it's only enabled for first time
| logins on a new browser/client Plaid ask you for the
| code.
|
| https://support-my.plaid.com/hc/en-
| us/articles/9098915502999...
|
| I don't know for sure how they do it, but it must just be
| a thousand custom forms and browser automations for each
| bank they support. And have to be updated whenever the
| bank updates.
| TheNewsIsHere wrote:
| This is one of my (numerous) top complaints about Plaid.
| From the start they've been more about working against
| than working with banks, and that's sort of obvious still
| today.
|
| My credit union doesn't give a flying fuck about Plaid
| and it's a constant cat and mouse game that amuses me to
| watch. My credit union doesn't have a path to online
| banking without per-session MFA.
|
| I think banks should be required to provide a user-opt-in
| OAuth API for read-only access, but not so that companies
| like Plaid can pilfer your data.
| cco wrote:
| > From the start they've been more about working against
| than working with banks... At the very beginning sure,
| but very quickly Plaid built out a team to try and work
| with banks. Banks were the biggest roadblock to OAuth,
| most banks have (had) zero appetite to provide a good
| experience for users to delegate programmatic access to
| their own user data. Banks see user financial data as
| their own and _not_ belonging to their users (as it
| legally does).
|
| However Plaid has made in-roads at many large
| institutions, and now supports OAuth, or OAuth-like,
| access at all (nearly all?) major US financial
| institutions.
|
| Plaid never liked working against banks, that just made
| everything worse for everybody involved.
|
| > My credit union doesn't have a path to online banking
| without per-session MFA. This obviously kills async
| products at Plaid, like continuous transaction data, but
| doesn't block sync products like Auth (account and
| routing data).
|
| In fact, Plaid made a huge push to increase the amount of
| MFA encountered on their platform. When banks or credit
| unions didn't offer MFA, or didn't allow users to enforce
| MFA on every login, Plaid would attempt to force it
| through a variety of mechanisms to ensure a bad actor
| would encounter MFA on Plaid even if the bank would
| otherwise let them through their actual website.
| masklinn wrote:
| As far as I know that's pretty much what it is yes, a
| bunch of per-bank scraping systems, which get updated
| when the bank decides to switch things up.
|
| IIRC Yodlee and Mint do (did?) about the same thing, for
| banks without a formal API.
| WorldMaker wrote:
| From my understanding in recent years Mint uses a lot
| more of the Quicken/QuickBooks semi-formal APIs when
| formal APIs don't exist. My understanding is that is one
| of the few, biggest benefits of Mint being bought by
| Intuit because that 200-pound gorilla has always had a
| surprising number of special read only APIs and export
| dump tools from even the quirkiest, smallest banks
| because of how ubiquitous their tax software is (and how
| many users would rebel if they didn't have easy access in
| Quicken or QuickBooks).
| arianvanp wrote:
| They're actively working on an extension on WebAuthn that
| supports these kind of 3D-Secure usecases.
|
| https://www.w3.org/TR/secure-payment-confirmation/
| https://github.com/w3c/webauthn/issues/1667
| Rygian wrote:
| > Safe from server leaks. Because servers only keep public
| keys, servers are less valuable targets for hackers.
|
| It's still an attack scenario to keep in mind. If a server can
| be tricked into storing the wrong public key, authentication is
| defeated.
| Corrado wrote:
| By the same token, if the server can be tricked into storing
| the wrong password, authentication is defeated. However, with
| passkeys, even downloading the entire database doesn't give
| the attacker any useful credential information. This is in
| contrast to today, where a database download gives you salted
| & encrypted passwords that are (generally) knowable (given
| enough time). I'll take passkeys over passwords any day.
| TheNewsIsHere wrote:
| This is my view as well. I think in the more technical
| crowds but outside of people who actively deal in identity
| and authentication daily, there seems to be this fixation
| on the marketing of passkeys that focuses on the FIDO
| component, and this muddies the virtues of the
| specification.
|
| Many focus too much on the (potential) MFA use case rather
| than the idea that we can use effectively the same tech as
| in Yubikeys (etc) to make phishing resistant authenticators
| everywhere.
|
| The (IMO) messy rollout by the major platforms really
| doesn't help either. They absolutely could have spent a
| little more time baking the UX and designing edge case
| mitigations, but they didn't.
| WorldMaker wrote:
| I think that is why it is both good _and_ bad that Apple
| have effectively taken the lead in the rollout. They are
| _great_ at UX and keeping an eye out for edge cases and
| trying to sand down the worst sorts of gotchas. If anyone
| can make sure that Passkeys _feel_ good to the average
| user it is probably Apple.
|
| On the flipside, that early lead also led to so many of
| the misconceptions about Passkeys that people have.
| People think it by nature has to be a locked, walled
| garden, because Apple has the lead and loves walled
| gardens when it has the lead.
|
| I think that's why this newest rollout announcement is
| such great news (which we knew was coming, but wasn't
| obvious to some of those misconceptions from Apple being
| in the lead): complete integration with the larger
| ecosystem of password apps already in the App Store wild
| (use your 1Password passkeys just like you can use
| 1Password passwords), and a UX for grouping passkeys and
| _sharing_ those groups with other contacts (that also
| helps with all the misconceptions about passkeys being
| some sort of crack down on password sharing).
|
| These UX flows would have been great to have seen in the
| initial rollout to assuage a lot of fears about Passkeys.
| It is _great_ to see them happening right now while it is
| still early enough to stop _most_ of the FUD before it
| starts to get outside of the HN paranoia bubbles and into
| average consumer ears.
| paulddraper wrote:
| Yes, but that's not a leak
| chongli wrote:
| The point is that a hacker can't use the public keys obtained
| in a data breach to access your accounts on other services.
| This is a common problem when a lot of people use the same
| email and password for many different sites.
| markstos wrote:
| And how might this happen?
| milkshakes wrote:
| account recovery process
| bnj wrote:
| Just chiming in to ask -- the immediate need for account
| recovery is in cases with lost or forgotten passwords. Am
| I right in assuming that account recovery becomes a much
| smaller attack surface when using passkeys? Or are there
| scenarios I'm overlooking?
| judge2020 wrote:
| It's mostly how sites will likely still allow full
| account recovery with just sms-based authentication,
| making account recovery the weakest link. It's still
| required, though, in case someone e.g. signs up with a
| passkey on their Windows desktop then forgot to enroll
| one on their phone before taking a vacation.
| whatusername wrote:
| So you're covered for "forgotten" - but "lost" is still
| an issue. What happens when a user loses their passkey?
| (stolen phone, no backups, house fire, etc).
| bnj wrote:
| Got it, thanks. A blind spot on my part there. It's funny
| how quickly the concept of losing access to a phone has
| taken root, I'm fortunate to have never had that happen
| to me and I need to remember how easily it could.
| xmdx wrote:
| Is the whole idea of syncing passkeys a bad idea? Or at least a
| less secure idea. Someone explained to me that passkeys are
| hardware backed, each passkey is stored on device and tied to the
| hardware, so even if someone managed to get access to it, they
| would also need the hardware to get it to work. These software
| based keys that can be synced are less secure as a result. Then
| it just becomes like a password again.
|
| I need to read up a bit more on passkeys in general tbh.
| WorldMaker wrote:
| Passkeys as a brand include both hardware-backed keys that
| can't be exported and are device-specific. These can be used
| for things like 2FA/MFA-type scenarios. They _also_ involve a
| lot of site-specific keys that may not be hardware-backed and
| syncable. The neat fun thing is that they can be synced with
| hardware-backed keys for strong E2E between a user 's enrolled
| devices and only the user's enrolled devices (plus maybe a hard
| to use recovery key). (That's basically how iCloud's
| Password/Passkey store and a lot of iCloud E2E in general seems
| to work.)
|
| Passkeys in general, especially the focus on a lot of site-
| specific E2E shared ones, are very much "just like a password",
| but as the sibling comment points out, the switch to PKI alone
| is a huge security win and would stop a lot of the
| haveibeenpwned sorts of leaks and the overall attractiveness to
| crackers to break into various company's password databases,
| because only having a public key is a lot less useful than a
| salted/hashed password that might be broken or found in a
| rainbow table.
| stavros wrote:
| It is less secure, but more convenient. You can pick either
| option. Or you can have both with delegation ("your husband is
| trying to log in as you on www.google.com, allow?").
| whatyesaid wrote:
| I think passkeys + 2FA is enough. Just enforce 2FA for any
| important service and it will be fine, if you don't force it
| then people who aren't as tech savvy will not do it or people
| may forget.
|
| For anything non-important I actually use sign in with Google,
| so.
| vouaobrasil wrote:
| So far, no one has commented on this large downside of passkeys:
| that it will promote the ease of sites to require login since
| it's much easier to generate a passkey than to remember a new
| password or even store it.
|
| Thus, passkeys lubricate the path towards an ever-increasing
| login-based society where it becomes much easier to track and
| monitor your online behaviour. Although it has the benefit of
| making our existing lives easier by removing the need to remember
| our banking passwords, it also will bring us further into the
| realm of technology by making more and more services log-in
| based.
|
| A greater ease of making a log-in based service means more
| revenue, more profit for Apple, and a greater integration of
| technology into our lives. Few people realize this because we
| have been conditioned to believe that new technology is solely
| for our benefit.
|
| In reality, Apple is not concerned with our benefit. They are
| concerned with profit and making technology more efficient to
| accomplish that end. So although passkeys might seem nice, there
| is a serious downside to this technology.
| cj wrote:
| > passkeys lubricate the path towards an ever-increasing login-
| based society where it becomes much easier to track and monitor
| your online behaviour
|
| This trend is already in motion thanks to the deprecation of
| 3rd party cookies and Apple's restriction of device
| identifiers, etc, on iOS.
|
| For most advertisers these days, the only way to run
| retargeting campaigns or measure conversions is with 1st party
| data. That means people are no longer relying on cookies at all
| for much of their conversion tracking. Instead, email addresses
| are used.
|
| This is (I think) an unintended side effect of stripping away
| cookies.
|
| At least with cookies, you could delete them locally. But now
| so much tracking is done with first party data, cookies are
| playing much less of a role. And of course there's not an easy
| "delete all first party data" button in your browser because
| the data is (obviously) held outside the browser.
| DCKing wrote:
| It's a thought provoking angle you have here for sure. However,
| am I right that the implication of this direction of thinking
| is that we should stay with our current ways of doing
| authentication simply because them being too hard to use puts
| up a natural barrier? That some of the ways in which they are
| broken are intrinsically good?
| rickdeckard wrote:
| It's also a convenient workaround to synchronize information
| about your online-behavior, while still being able to state
| publicly that your browser-history is never processed to
| profile you.
|
| Upvoting this because it's a view worth sharing (and I'm sure
| you'll be downvoted just because of your baseless claim that
| Apple is concerned about something as dirty as profit /s)
| theshrike79 wrote:
| Apple is making filthy amounts of money just from hardware
| and app sales.
|
| All of their attempts at targeted advertising have been
| rounding errors at best.
|
| And they know that complete unbreakable privacy is the place
| where Google (an ad company) can never ever fully follow no
| matter what kind of lip service they do in their keynotes
| about privacy.
| clairity wrote:
| all of apple's recent growth is coming from its content
| ("services") business, which means it's hot to track you
| for advertising purposes. passkeys provide another stone in
| their walled garden to be able to track you but keep others
| from doing so as effectively, which on balance contributes
| to its competitive advantage.
|
| make no mistake that this is the direction apple is headed.
| it's been clear for the last 5 years or so, since hardware
| sales have leveled off. perhaps the goggles will dampen the
| velocity a bit, but i'm very skeptical that the AR/VR
| market is mature enough to have that effect in the near
| future.
| arianvanp wrote:
| Passkeys are stored in your encrypted iCloud keychain. Apple
| doesn't see or process what websites you're logged into on
| their servers.
| dan-robertson wrote:
| I don't think this makes sense.
|
| Sites already desperately try to get people to log in. I don't
| particularly see it as an advantage for Apple if eg the Reddit
| website or some random online shop makes you log in. If Apple
| are interested in selling ads, I think they should not want to
| make it easy to track people on websites through logins as that
| helps their competitors.
|
| I generally model Apple as preferring that you use (and pay
| for/in) some app rather than a website, and logins are less
| necessary for apps where you can store information about your
| session and don't need to regularly prompt the user for
| passwords. I think Apple would rather you don't have some
| separate account you can log into on a website to eg pay for a
| service without in-app-purchases.
|
| I mostly think of passkeys as a better version of the password
| manager: allowing users to do what they already want in a more
| secure way. If there is some subtle business advantage it is
| maybe that users would make new accounts rather than using
| sign-in with Google/Facebook, though I don't know to what
| extent those features are valuable to Google/Facebook.
| danShumway wrote:
| This is not high on my list of concerns about passkeys.
|
| I worry about attestation, vendor lock-in, the spec process,
| etc... but (if attestation isn't a huge issue) easier account
| creation is not a huge deal because multiple-account creation
| will also get a lot easier.
|
| If a system is requiring your passkey plus a metric to verify
| your identity (again, assuming attestation doesn't become a
| problem), then they're already in a position where asking for
| your email is not a big deal. So I don't see how passkeys
| change anything for them.
|
| On the other hand, any account that would have asked for my
| email before now doesn't have to. And if attestation goes well
| and Apple continues rejecting it for roaming providers, they
| won't get _any_ information other than my login credentials. I
| have disposable email addresses, but most people don 't.
| Getting rid of a factor that essentially forces them to only
| have a single account with a service and makes it easier to
| track them across services -- getting rid of that is a good
| thing.
|
| There's tons to be worried about with passkeys, but this is not
| something that worries me. What worries me is if attestation
| pushes its way into the roaming provider implementations and
| suddenly I can't create an account on a rooted phone anymore.
| But getting rid of extra verification/identity steps would be
| good for users and good for privacy. It would be great if I
| could sign up for a service just with a key and without an
| email address.
| RcouF1uZ4gsC wrote:
| > So far, no one has commented on this large downside of
| passkeys: that it will promote the ease of sites to require
| login since it's much easier to generate a passkey than to
| remember a new password or even store it.
|
| Actually, this ease of use may be beneficial to privacy. Sites
| don't need user generated/remembered passwords to require a
| login, they can just use the sign in with Google/Facebook/Apple
| buttons. Because it is easier than remembering another
| password, users will typically use those options. Passkeys is
| more private than signing in with Google/Facebook/Apple, while
| also providing more privacy than those options.
| vouaobrasil wrote:
| You are ignoring the other side of the equation: more sites
| with logins.
| goalieca wrote:
| Each website gets a unique key. They are not signed or rooted
| in any trust. You can still pick any username you want for the
| account. What passkeys do is replace OTP and MFA. They live
| along SSO and do not replace it.
| anderspitman wrote:
| I think the first use cases of WebAuthn were targeted at MFA,
| but passkeys are definitely being advertised as replacing
| passwords as the primary/only factor (with the caveat that
| you'll also be expected to perform some sort of pin/bio
| authentication on the local device).
| UncleMeat wrote:
| "Authentication has to be messy and painful so it isn't
| adopted" is an odd take.
|
| This also seems to be the polar opposite of most complaints
| about passkeys. The typical response is that they won't replace
| passwords because passwords are easy and accessible. Here you
| are saying that passkeys are easier. It can't be both.
| bravetraveler wrote:
| It's a fair point, but I'm not that worried about more logins.
| We're already being pushed this way by Big Business wanting
| more and more users to mine/advertise towards.
|
| I worry a little about normalizing on fingerprints, but not
| because tin-foil-hat thinking about _tracking_.
|
| Those can _certainly_ be ordered /forced by a judge, where
| passwords/codes are less well defined. I'm not up to anything
| shady, but I fear an authoritarian government.
|
| Let's consider PINs, too. Those can be used instead. How many
| of these are people going to memorize? Many passphrases become
| one relatively easily guessed number on a device you can lose
|
| Implementation details, surely - and I'm really green... but I
| worry about unintended consequences a lot
| arianvanp wrote:
| How? you make claims that seem to have no substance. What extra
| vector does Passkeys add for tracking? I don't see any.
|
| Passkeys are an origin-bound login mechanism. Worst case is
| that somebody places a first-party cookie to keep you logged in
| after you authenticated with a passkey. which they and will
| already do today without your consent or without logging in.
| (First-party session cookies don't even need a cookie wall.
| They're considered "necessary" processing)
| vouaobrasil wrote:
| If it is easier to do something, more websites will do it.
| Passkeys make it easier to make new logins, so more websites
| will do it. Just like seatbelts make people drive more
| dangerously.
|
| If more websites require logins, they can track you more
| easily, simple as that. It has nothing to do with the
| engineering aspects of passkeys, and everything to do with
| the fact that technology which makes logins easier will
| encourage more login-based services.
|
| You need to step away from the engineering details and look
| at things sociologically.
| dan-robertson wrote:
| Doesn't Apple Pay make it easier to not log in to websites
| (by getting rid of their desire to save payment details or
| addresses to get through later checkouts faster)? I just
| don't really see some grand pro-login plan implied by
| Apple's actions.
| vouaobrasil wrote:
| You are right. Of course, I am not talking about a
| conscious plan by board members or employees, but the
| general emergent trend inherent to this type of
| technology. I did not mean to imply conscious action as
| we know it.
| cj wrote:
| With 3rd party cookies going away, companies now need your
| email address to effectively track you.
|
| Tracking you via your email address is actually better than
| using cookies (for the advertiser) because it works cross-
| device and cross-browser.
|
| Any mechanism that makes it easier to login to sites will
| promote the usage of email addresses for tracking purposes.
| Think retargeting and conversion tracking (no longer needing
| to be cookie-based).
|
| Passkeys = quicker and faster to get a user's email address.
|
| Email address = even better than "super cookies"
| TimothyBJacobs wrote:
| > Passkeys = quicker and faster to get a user's email
| address.
|
| Using passkeys doesn't give a site your email address. The
| site would have to still ask for your email separately.
| dan-robertson wrote:
| But Apple offer this service where they make a fresh proxy
| email for you which is unique to the service. Why would
| they do that if they want to enable cross-service tracking
| via email address?
| withinboredom wrote:
| I use 1password + fastmail for exactly this. The
| integration is better than Apple IMHO.
| anderspitman wrote:
| Do 1password/fastmail have functionality built in for
| this or do you just manually generate your emails based
| off a wildcard?
| withinboredom wrote:
| Yes. It's built-in. https://1password.com/fastmail/
| closewith wrote:
| > Tracking you via your email address is actually better
| than using cookies (for the advertiser) because it works
| cross-device and cross-browser.
|
| At least in the EU, you'll need express consent to do this.
| tourmalinetaco wrote:
| "Need" is a very strong word. Any potential fines will
| just be rolled into the costs of doing business, and if
| it's found to still be worth it they'll keep abusing user
| privacy as there is a net benefit profit-wise.
| withinboredom wrote:
| IIRC, the fines are some % of revenue. Basically enough
| to tap into margins.
| closewith wrote:
| Up to 4% of global turnover, so substantial.
|
| From personal experience, businesses I've dealt with in
| the EU are eager to be compliant as long as it's applied
| across the board (ie, they aren't losing their
| competitive advantage).
| mcherm wrote:
| Passkeys do not help track people between sites, but if they
| are used in places that passwords never were, it might
| increase tracking within a site.
|
| Hacker News, for instance, allows non-logged-in read-only
| usage. If Hacker News decided that Passkeys were so easy for
| the user that non-logged-in usage would be eliminated, then
| some degree of privacy would be lost.
|
| Personally, I don't think it is that much of a risk. I DO
| worry about putting too much control in the hands of Apple
| and Google.
| WorldMaker wrote:
| If sites started going Passkey only even for "guest"
| access, you'd quickly see a rise in Passkey managers that
| quickly generate throwaway passkeys and you'd also see a
| rise in "globally shared" anonymous group passkeys, just as
| people already do today to get around paywalls and some
| walled gardens with passwords and "phone memberships" at
| rewards clubs (the notorious Jenny's Number being a common
| one there). The techniques don't really change that much.
| Passkeys really don't have any more identifying information
| than passwords or phone numbers and temporary anonymous
| passkeys or over-shared passkeys are likely to be a thing
| in some places as soon as they are seen as necessary.
| runeks wrote:
| > If Hacker News decided that Passkeys were so easy for the
| user that non-logged-in usage would be eliminated, then
| some degree of privacy would be lost.
|
| Not if you the user generates a new login upon every visit,
| which should be trivial.
| smcleod wrote:
| Hopefully this comes to Strongbox soon!
| anderspitman wrote:
| My main concern with passkeys is I'm not aware of a way to pre-
| authorize someone who doesn't yet have an account. For example,
| with email I can just grant X access to anyone who can prove they
| have access to Y email address. But passkeys don't have a single
| public handle like this. This isn't such a big deal with
| centralized services where everyone is likely to already have an
| account, but might pose a problem for selfhosted services. Still,
| I like passkeys and wish there was a way to have my cake and eat
| it too.
| spuz wrote:
| One thing I don't understand about offering passkey login for
| your email is how you would go about recovering an account if you
| lost access to the device which holds your passkey? Google
| states: "When you create a passkey, you opt in to a passkey-
| first, password-less sign-in experience.". This seems to imply
| that you will not be able to use your old password if you ever
| lost your phone. Do Google still offer backup passwords for
| recovery purposes if you switch to passkeys? Their site doesn't
| seem to explain this.
|
| https://support.google.com/accounts/answer/13548313?hl=en#zi...
| Ajedi32 wrote:
| Think of passkeys as being the same as a password database. The
| provider can offer whatever recovery mechanism they want, and
| sites that use passkeys can continue to offer account recovery
| methods completely independent of their use of passkeys.
|
| As for what Google does specifically with their implementation,
| I'm not sure. I personally plan to use KeepassXC's
| implementation, whenever that comes out, with my own custom
| database backup strategy.
| snagg wrote:
| This is an area with the specs contrast with the vendors.
|
| The WebAuthn specs recommends to register multiple
| passkeys/credentials per device and assume that once a
| credential is lost it might not be recoverable.
|
| Apple and other vendors using keychains/wallets are
| effectively offering the option to delegate the recovery of
| the passkey to the recovery of the account with them (eg: the
| iCloud account).
|
| In case it is of interest, we wrote a long blogpost on the
| topic: https://www.slashid.dev/blog/passkeys-security-
| implementatio...
| [deleted]
| [deleted]
| arnarbi wrote:
| You can still use your password today on a Google account with
| passkeys. And account recovery via other means (depending on a
| lot of things) is still available.
|
| It's too early to completely replace all methods with passkeys,
| but the hope is that as they gain better support and
| understanding websites will be able to make other methods
| rare/exceptional. For exceptional cases such as account
| recovery, as opposed to day-to-day account sign-in, there is
| room to apply a lot of other abuse signals and other methods to
| make it harder for attackers.
|
| More here: https://security.googleblog.com/2023/05/so-long-
| passwords-th....
| [deleted]
| izacus wrote:
| Same way as you recover a password stored in your password
| manager. It's pretty much the same thing.
| spuz wrote:
| The way I do that is I memorise my password manager master
| key. How do I do that with a passkey?
| toomuchtodo wrote:
| Email magic link, recovery codes, web of trust (recovery
| contacts), or remote government credentials proofing
| (ID.me, Stripe Identity, etc).
| ttul wrote:
| This is a smart move by Apple. Authentication infrastructure is
| necessarily cross platform. It doesn't generate revenue for
| Apple, but the lack of cross platform auth would limit enterprise
| adoption of Apple products.
| supriyo-biswas wrote:
| Passkeys (otherwise known as WebAuthn) isn't an Apple specific
| standard though.
| ttul wrote:
| Absolutely. 1Password is betting heavily on being the passkey
| clearing house for enterprise. I think what Apple is doing
| here is saying that companies like 1Password can do this for
| their flavor of WebAuthn too.
| riffraff wrote:
| > It doesn't generate revenue for Apple,
|
| but it creates lock-in, if all your credentials are in a iCloud
| keychain, you're encouraged to get a phone that can sync with
| your ipad, laptop, and desktop.
|
| Manually find and re-sync your stuff from firefox-on-desktop to
| chrome-on-mobile to safari-on-ipad is a major PITA.
| rickdeckard wrote:
| And it creates nicely labeled and synchronized information of
| when and how often a user logged into a eCommerce
| service/Streaming portal/..., while still being able to state
| that your browser history is never processed for profiling...
| danShumway wrote:
| I still want to see more details. That being said, extremely
| positive news. Vendor lock-in is one of the biggest issues with
| passkeys and one of the biggest reasons I haven't been able to
| get on board with them and why I usually end up advocating
| against them whenever they come up.
|
| Between this and Apple blocking attestation efforts for mobile
| passkeys, it gives me more confidence that this could turn into a
| standard that I want to use. I criticize the passkey standard
| pretty consistently, I would be very happy to eat crow on that.
|
| I will say that it would go a long way to make this stuff part of
| the standard, I don't like how much these really critical pieces
| of passkey functionality are boiling down to "wait and see what
| vendors do." But I'm cautiously optimistic to see where things
| go. It is a _really_ big deal for Apple to support 3rd-party
| providers and an even bigger deal for Apple to support sync with
| 3rd-party providers.
___________________________________________________________________
(page generated 2023-06-06 23:02 UTC)