[HN Gopher] Passkey technology is elegant, but it's most definit...
___________________________________________________________________
Passkey technology is elegant, but it's most definitely not usable
security
Author : Flimm
Score : 281 points
Date : 2024-12-30 12:31 UTC (10 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| freetonik wrote:
| In some parallel universe, each computing device manufacturer is
| required by law to provide a storage so that the user can plug in
| their single, universal, transferrable set of security
| credentials (like passkeys). Instead of "many cooks" mentioned in
| the article, there is one standard.
|
| I cannot bring myself to agree to any "switch to passkey" prompt
| from any device because I have no idea (and too tired to figure
| out) how and where that key will be stored, how do I deal with
| different devices, etc. I already have a universal solution for
| credentials: 1password, which is cross-platform. With Apple's
| keychain, and I suspect other companies' solutions, passkeys are
| connected to your account and at best synced between devices from
| the same manufacturer. But even with Apple, I can't sync stuff
| between my personal and work computer because they use different
| Apple IDs, even though the underlying true identity (me) is the
| same.
|
| Like with many other solutions, the current approach with
| passkeys is designed for an imaginary "user in vacuum" model each
| company dreams about, where people are 100% into one ecosystem,
| forever.
| YPPH wrote:
| >But even with Apple, I can't sync stuff between my personal
| and work computer because they use different Apple IDs
|
| You can't save your personal passkeys on your work phone and
| vice versa, but when logging in to a service on one device, you
| should be able use a passkey from the other device via
| Bluetooth by scanning a QR code.
| freetonik wrote:
| Good to know, thanks! But I might not have the other device
| on me at all times.
| asah wrote:
| FIDO keys are _tiny_ e.g. yubikey 5c
| lxgr wrote:
| If anything, this achieves the opposite of making sure I
| always have mine on me.
|
| Dedicated, external hardware authenticators are great for
| logging in to very high value accounts or password
| managers, but arguably they're not really viable for 99%
| of users and use cases on a day-to-day basis.
| nixosbestos wrote:
| I don't agree at all. It's on my keychain, next to my
| keys, a nice symmetry. When I need to login I hold it to
| the back of my phone for half a second. It's incredibly
| easy and would be even easier if it weren't for the UX
| presented by iOS, Android, and Windows where they try to
| be the provider. Android has gotten a bit better. Windows
| is the worst about it afaict.
| lxgr wrote:
| Different people, different preferences.
|
| I don't like having to fetch my keys when I'm at home at
| all, which is where I do most of my authentications. I'd
| have to get up, walk to where I usually keep them, walk
| to my computer with them to authenticate, and then either
| walk back or forget the keys somewhere in the house and
| have to search for them when leaving (or detach the
| authenticator from the keychain and then not have it on
| me when I'm leaving).
|
| That's why I don't like using USB authenticators on a
| regular basis.
| ylk wrote:
| It's recommended to have at least two anyway, to still
| have access to your accounts in case one is lost. That
| means you can keep one key at your desktop and you'd only
| need to go up to get your keys when adding them to an
| account.
| lxgr wrote:
| Having two in the same house is a pretty bad compromise.
| Ideally you'll want one of them to be physically somewhat
| distant (in case of a fire etc.), which makes things even
| less ergonomic.
| clcaev wrote:
| An added challenge: Yubikey NFC doesn't work on iPad, only
| iPhone. USB operation also seems fraught. This has been so
| for 7+ years now. If Apple cannot get this to work with a
| closed ecosystem and the leading vendor, I think the
| technology is just not ready for mainstream.
| samcat116 wrote:
| Yubikeys work on iPad and iPhone via USB perfectly fine
| now. I do it quite often.
| haroldp wrote:
| Woah, you are correct. My YubiKey 5C now works with my
| iPad M4! When did they fix that??
| samcat116 wrote:
| I think they added better hardware key support at an OS
| level a little over two years ago. They needed all the
| web authn stuff for passkeys anyways, so I bet it was a
| necessity prerequisite.
| haroldp wrote:
| I just got the new M4 iPad like two months ago, and my
| YubiKeys absolutely did not work, no matter what I tried.
| There are articles on apple.com and yubikey.com that
| explain that USB-C YubiKeys will not work with USB-C
| iPads because Apple's USB-C implementation isn't sending
| the timing info (or something like that) that the YubiKey
| needs to function. People were buying Lightening YubiKey
| and connecting them to Apple's Lightening to USB-C
| "camera adapter" to work around this.
|
| I decided to double-check my YubiKeys before I responded
| to your post and (!!!) they work now! This is huge!
| lxgr wrote:
| Apple is actually doing a lot of work (largely) in the
| background with every OS update.
|
| I was recently pleasantly surprised to be able to use my
| smartcard form factor FIDO authenticator on macOS using a
| CCID USB smartcard reader. Not exactly ergonomic on a
| laptop, but totally viable on a desktop or docking station
| setup with a permanently plugged in reader. Sometimes I
| really do miss that contactless card reader option that
| some Thinkpads offered...
| _Algernon_ wrote:
| >In some parallel universe, each computing device manufacturer
| is required by law to provide a storage so that the user can
| plug in their single, universal, transferrable set of security
| credentials (like passkeys). Instead of "many cooks" mentioned
| in the article, there is one standard.
|
| Ignoring site support, this exists. It's called USB and
| yubikey.
| anotherhue wrote:
| Was called a SIM card before that.
| formerly_proven wrote:
| Both are smartcards. Yubikeys also happen to support the
| USB HID CTAP protocol, which is something unprivileged
| applications can usually talk to directly on most operating
| systems. Most other CTAP transports are just smartcard
| transports (APDUs over PC/SC or NFC). Yubikeys also have a
| PIV applet, which isn't used for your typical enterprise
| X.509 PKI, and an OpenPGP applet, which typically isn't
| used.
| lxgr wrote:
| PIV, GnuPG, or PKCS#15 are probably better comparisons. SIM
| cards use symmetric cryptography, which means you can only
| authenticate yourself to a single entity.
| gchamonlive wrote:
| Honest question, this isn't supposed to be a burn in any sense.
| But isn't it contradictory to want to know how and where your
| credentials are stored and use any credential management
| solution that isn't opensource and selfhosteable?
| freetonik wrote:
| Fair enough, but I believe there is a spectrum between "I
| don't want to know things, let them just work" and "self-host
| and manage an application for storing the most sensitive type
| of information".
|
| 1Password is neither opensource nor self-hostable, and it
| stores data in the proprietary cloud (at least exports are
| easy). But I understand that and accept it.
|
| If I get a Macbook, an Android phone, and a Windows PC (a
| very popular combination of devices, btw), I honestly don't
| have energy to investigate how to inter-operate their passkey
| solutions. From the get go, I assume it's gonna be either
| impossible, or very hacky and fragile. Maybe I'm wrong, but
| last time I checked I simply walked away thinking "nope, no
| passkeys for me".
| Aaron2222 wrote:
| 1Password itself has native passkey support. I don't have
| experience with it on mobile, but on desktop browsers their
| extension overrides the build-in passkey support to
| use/store passkeys from/in 1Password (with a button to fall
| back to the built-in implementation for its storage,
| hardware tokens, QR code to use/store a passkey from/on a
| smartphone, etc).
| Aaron2222 wrote:
| Looks like on iOS it integrates with the native passkey
| support (so is usable anywhere native passkeys are
| supported). 1Password on Android looks to have similar
| integration, but only for apps at this stage (not
| websites, due to an Android limitation). So still a
| little while to go yet for "it just works" across all
| platforms.
| mihaaly wrote:
| > With Apple's keychain, and I suspect other companies'
| solutions, passkeys are connected to your account
|
| And from this account you may be locked out for various reasons
| anytime, as it happened to countless persons previously,
| violating exotic or even understandable rules, or just been in
| the crossfire of some galactic corporate incompetence (some f'd
| up), but this way you'd be locking yourself out of everything
| especially if you were that user in the vacuum, exposing
| yourself to the mercy of a single organization with changing
| managemenet and incentives as the wind turns in a city's dense
| downtown.
| skybrian wrote:
| I solve this by creating two passkeys for each account, for
| iOS and Chrome. This covers all the devices I might use to
| log in and there's no single point of failure.
| HumanOstrich wrote:
| That doesn't solve anything. You just have twice as many
| problems now.
| skybrian wrote:
| What are you talking about? Redundancy is how you avoid
| getting locked out. Each passkey serves as a backup for
| the other one.
|
| More generally, you should have two keys for any lock, so
| you can still get in if you lose one of them.
| michaelt wrote:
| Setting up both Apple and Google passkeys solves:
|
| * Lost access to your Google account, but still have
| access to your Apple account (or vice-versa)
|
| * Apple device doesn't support Google passkeys, or vice-
| versa
|
| But it multiplies the following downsides:
|
| * Apple/Google account gets hacked, hacker gets all your
| 2FA credentials
|
| * Snooping on your activity. Particularly Google, but
| Apple also have an advertising business.
|
| * Setting up accounts on new sites is twice the hassle.
|
| * Too complicated for the kind of folks who need the
| phishing protection passkeys provide.
| rlpb wrote:
| Many passkey-supporting sites only support a single passkey
| per account.
| growse wrote:
| Which?
| _Algernon_ wrote:
| Paypal is one I've encountered.
| lxgr wrote:
| Paypal, as far as I can tell, doesn't even
| (intentionally) support passkeys. They refer to all
| WebAuthN credentials as "security keys" and remind me to
| "plug it in and touch it now" etc.
|
| I'm honestly already glad that they didn't make their
| annoying browser fingerprinting rigorous enough to also
| block authentications and aren't requiring attestation.
| xjlin0 wrote:
| Even google account's MFA allows back up codes, at least
| in the Enterprise accounts.
| kbolino wrote:
| This feels like the biggest misstep that may impede the
| success of passkeys to me. It's not that surprising,
| though, since it's pretty rare to find genuine support
| for multiple authentication factors of the same type
| already. You can usually only register one number for
| SMS, and/or one TOTP authenticator, etc. It seems like a
| lot of sites never really understood (or cared about) the
| benefits of MFA _to the user_ and so can 't be bothered
| to really understand passkeys either.
| skybrian wrote:
| Yes, this definitely needs to be fixed!
|
| Besides passkeys, some websites have alternative backup
| authentication, though, such as backup codes. However you
| do it, there should be an independent way to log in.
| vel0city wrote:
| I keep hearing this but then the only example I'm given
| is PayPal and that AWS used to be this way. What big
| sites do you experience only allow a single passkey?
| stouset wrote:
| I use a passkey on every site that supports it (say two
| dozen at this point). I have never encountered this.
| UltraSane wrote:
| Which is a serious flaw in the standard.
| compiler-guy wrote:
| The fact that the problem is solvable by technically savvy
| people doesn't stop it from being a problem for the general
| user.
| tjoff wrote:
| To add an insanely unsatisfactory solution as well.
|
| Even passwords are better. Seriously.
| JadeNB wrote:
| > I solve this by creating two passkeys for each account,
| for iOS and Chrome. This covers all the devices I might use
| to log in and there's no single point of failure.
|
| This just seems to mean that, instead of being the whim of
| one corporation from being locked out of all your accounts,
| you're the whim of two corporations away. That's better,
| but I'd hardly call it solved.
| skybrian wrote:
| "Google says no" is a threat model I'm concerned about,
| but it doesn't seem particularly likely, so I'll pick
| another passkey manager if it happens.
|
| (If it ever happened, Gmail and Google Photos would be a
| bigger loss.)
| 1oooqooq wrote:
| congrats. your problem is solved in the two or three places
| that actually allows or even implements any logic from N
| passkeys. on most places that will just give you a new
| account or wipe the first key.
| chrchr wrote:
| Really? Which place allows passkey login and only allows
| one key per account?
| frereubu wrote:
| I get that this this is a way to do it in practical terms,
| but isn't that just like having to have two passwords for
| each site (outside the fact that passkeys are a bit more
| secure than passwords)? I thought one of the main points of
| passkeys was to reduce admin.
| ghusto wrote:
| Does that mean you're locked into iOS and Chrome?
| marcosdumay wrote:
| If you can do that, you also have enough tech savyness to
| use passwords securely.
| patrakov wrote:
| The problem that passkeys solve is not that of their
| user. It is that of the website that authenticates its
| users. With mere passwords, there is no way they can be
| sure that the user follows the required password hygiene.
| With passkeys, there is no way a user could set up
| something insecure.
| theamk wrote:
| Are we taling savvy users or regular users?
|
| Regular users would not set up double passkeys, and would
| suffer vendor lock. They would be better off with
| password manager instead.
|
| Savvy users know how to follow password hygiene, and have
| no need to have it enforced on them. So they don't need
| passkeys either, they would be better of with good
| password manager.
| fauigerzigerk wrote:
| The security of passwords doesn't just depend on users
| though.
|
| https://haveibeenpwned.com/PwnedWebsites
| mapt wrote:
| At one point, a streamer on Youtube asked his audience
| something like "Spam F's in chat [to signal that you like
| this thing I just did]"
|
| Hundreds of users got banned by Youtube for spamming.
|
| But they didn't get banned from "Youtube". They got banned
| from "Google". They lost access to their Gmail, and to their
| Android login, and every other Google service, meaning they
| lost their phone text verification system for every other
| login, and quite possibly their password manager.
|
| Hundreds of identities were stolen and _set on fire_ by an
| overly aggressive approach to spam management.
|
| I try to remember this failure mode in planning (or being
| unable to plan) the security of my online presence.
|
| Then I incorporate Elon Musk's recent behavior and recognize
| that while the profit motive _generally_ constrains the
| behavior of these firms, it's by no means assured.
|
| For basic social welfare, either this identity stuff needs to
| be heavily regulated or all of these big companies need to be
| broken up.
| 6510 wrote:
| Even without malice or incompetence you will have false
| positives and false negatives. Then when you attempt to
| correct the mistake you will have false positives and false
| negatives again.
| feoren wrote:
| Should a false positive from the YouTube anti-spam
| algorithm accidentally temp-ban someone from commenting
| on YouTube for a week, or should it permanently and
| irrevocably destroy their online presence, possibly
| preventing them from logging into anything online: email,
| banking, government services, paying their mortgage?
| Because the whole problem is that we're in the universe
| where the latter happens.
| boredtofears wrote:
| This legitimately terrifies me because it feels like a
| realistic eventual outcome -- whether it's via a careless
| automated system with no recourse or simply
| enshittification of an existing product due to leadership
| change.
|
| I'm so entrenched in various platform ecosystems I'm not
| even sure how to claw my way out of it.
| UltraSane wrote:
| This is the exact scenario that led me to register my own
| domain name and email address on it.
| emuuscantly wrote:
| Just remember if you ever give up your domain, whoever
| purchases it will now have your email as root-of-trust to
| EVERY site you ever created an account with.
|
| Also, it can be pricey. If you have a .com/.org it is
| cheap, but I have a .io and the price keeps doubling
| every few years.
|
| Also, it can be risky: and there is a very real risk that
| .io will be (rightly) reclaimed by the country that owns
| it and either seize the domains are really jack up the
| prices even more.
| aftbit wrote:
| Yeah I would suggest against using a ccTLD unless you
| have a strong connection to that country. Don't buy .io
| or .ai because they're trendy. Buy .com or .net or .dev
| or something else generic, or buy .co.uk if you live in
| the UK etc.
| dvngnt_ wrote:
| > Hundreds of users got banned by Youtube for spamming.
|
| is there a source for this? googling just brought me back
| here
| oefrha wrote:
| I've heard this story quite a few times but it's always
| hearsay without anything concrete enough to even begin to
| verify. Given that one account of mine got perma-banned
| on YouTube (for violating the "impersonation rule" with a
| bunch of screen recordings set to private...) and it
| didn't affect the rest of the account, I have to assume
| the story is fake.
| Prickle wrote:
| https://9to5google.com/2019/11/09/google-account-bans-
| youtub...
|
| It definitely was not fake. I saw plenty of uproar on the
| day it happened.
|
| I remember a number of tech channels also started to post
| videos on how to de-google right after that.
| Prickle wrote:
| https://9to5google.com/2019/11/09/google-account-bans-
| youtub...
|
| This article provides a good summary of events.
|
| The short of it, is that a YouTuber was Livestreaming.
|
| He asks viewers to spam certain emojis to select what
| path the streamer should take.
|
| Google's automated system detected the spam, and banned
| google accounts.
| miles wrote:
| I couldn't find any other source for that anecdote, but did
| find plenty of other reports:
|
| Terraria on Stadia cancelled after developer's Google
| account gets locked
| https://news.ycombinator.com/item?id=26061935
|
| Google users locked out after 15 years' use
| https://news.ycombinator.com/item?id=24965432
|
| I got locked out of my Google account for a month
| https://news.ycombinator.com/item?id=15989146
|
| Tell HN: Need help, locked out of Google account with 10
| years of personal data
| https://news.ycombinator.com/item?id=42350245
|
| Android user locked out of Google after moving cities
| https://news.ycombinator.com/item?id=13004369
|
| Ask HN: I'm a small business and Google locked me out
| https://news.ycombinator.com/item?id=22705122
|
| Ask HN: Locked out of Google services with no recourse or
| explanation https://news.ycombinator.com/item?id=17428707
|
| ASK HN: Google account disabled. Oh what to do?
| https://news.ycombinator.com/item?id=350968
|
| Ask HN: Google just kicked me out of my account, no option
| to verify https://news.ycombinator.com/item?id=24709282
|
| Man locked out of Google Drive and loses 9 year old photos
| after SIM Swap attack
| https://news.ycombinator.com/item?id=41915523
|
| Ask HN: Locked out of Google Aps email with no recourse -
| advice? https://news.ycombinator.com/item?id=9768593
|
| When you get locked out of your Google account, what do you
| do? https://news.ycombinator.com/item?id=31070914
| fishywang wrote:
| >exposing yourself to the mercy of a single organization
|
| The nice thing about passkey is that unlike password, you can
| have multiple per account.
|
| So you can register a passkey from 1password to website A,
| and also register a passkey from Apple keychain to website A,
| and also register a passkey from Google account to website A,
| and also register a passkey from yubikey to website A, so
| even if you are locked out from one of your accounts, you
| still have several other ways to log into your account at
| website A.
|
| And _if_ your, say, Apple keychain is compromised, you can
| just revoke the passkeys from your Apple keychain from all
| the websites (yes it's tedious, but it's doable).
| efitz wrote:
| Having to have multiple passkeys per site to circumvent
| vendor identity lock-in is one of the main problems with
| passkeys.
| shim__ wrote:
| I'd be so easy if this proposal were implemented:
| https://www.yubico.com/blog/yubico-proposes-webauthn-
| protoco... one could always register one or more
| additional keys without having access to them.
| buran77 wrote:
| A door can be kicked in, a safe can be drilled, a
| password can be reset. But these keys (whether a phone or
| a Yubikey) to your digital life are irreplaceable if
| they're _all_ lost. We 've never been in this situation
| before.
|
| The problem with any solution relying on a couple of
| physical devices as the sole access to your digital life
| is that the management and protection of those objects
| becomes one of the most important things in your life.
| These keys are supposed to give perfect security so by
| design making "software" copies brings that security to
| the level of passwords. But losing them kills your
| digital life.
|
| You have two keys in the house and you have a fire or
| severe natural disaster? There's no reset for them and
| you just piled a tragedy on top of another. You want to
| restore them from a backup? You probably need the keys to
| begin with. People need one on them at all times, one at
| home, one or two in some other safe far away location but
| to still trust that they won't be misused there.
|
| That's all people hear when they look into passkeys. "One
| more key" is not enough for most people, tech savvy or
| not.
| theamk wrote:
| Even if it's possible technically, I don't think it's very
| practical, as UX is very heavily directed towards a single
| passkey provider. I can imagine doing this for one or two
| most important websites, but not for each of dozens
| (hundreds?) websites users have registeration on.
| gsich wrote:
| Those websites are unimportant enough to just use normal
| passwords.
| fishywang wrote:
| I'm not sure what UX you are talking about, the majority
| of the websites supporting u2f/passkey have UX to manage
| your u2f keys/passkeys. (the only exception I can think
| of is early Twitter when it first implemented u2f, and at
| that point it only allow you to add a single u2f key, but
| even Twitter fixed that later and supports multiple keys
| now).
|
| And (this is probably not emphasized enough) you really
| should never only use a single u2f key/passkey for a
| website, that's the recipe to get you locked out when you
| can't find your u2f key/get locked out of the provider of
| your passkey. I have at least 2 yubikeys on my keychain
| all the time (one for usb-a and one for usb-c), plus one
| for each of my computers, and passkeys from 1password,
| google, etc.. And whenever I add u2f keys/passkeys to a
| website I add all/most of them.
| bobbruno wrote:
| ...and you just described why this is not ready for prime
| time. Managing a number of physical devices tied to
| completely opaque secrets stored by unclear providers in
| places you never see, with hidden agendas promoting their
| locked-in solution over all others and complicating
| everything out of one ecosystem.
|
| Most standard users will either mess up royally or run
| away scared. Damn, I've been on this field for 30 years,
| I've been using 4 OSs, 5 different browsers and devices
| from every ecosystem, and I still find this whole thing
| too much of a hassle.
|
| And yes, I do have a backup passkey. Even though I had to
| convince my skip-level that it made sense. I just find it
| all too complex to adopt it broadly.
| theamk wrote:
| if I am reading right, any time you set up passkeys on a
| web site, you add half-a-dozen passkeys from various
| services? Yeah, this sounds totally impractical to me.
|
| Have you considered stopping using passkeys and using
| strong passwords stored in password manager instead? You
| will have approximately same level of security:
|
| - Either way, if one site is compromised other sites are
| not affected (because password managers have site-per-
| password)
|
| - Either way, you will be phishing-protected (because
| password managers autofill based on host name, and you
| are smart enough not to override it)
|
| - Either way, it'll be game over if you get a malware on
| your computer (because it will steal your passkey out of
| 1password)
|
| ... but your UX for new website would be dramatically
| simpler.
| vel0city wrote:
| It's not much of a hassle. I'll add at least two when I
| want to start using a passkeys for a site. So maybe add a
| passkeys to the phone and to my keychain device. Then,
| next time I use the service on my laptop, I'll sign in
| with either my phone or keyring (whatever happens to be
| closer) and make one there. Then next time I want to use
| the service on my desktop I'll sign in with whatever I've
| got nearby and add my desktop and the token in my desk
| drawer. And maybe my password manager _also_ has a
| passkeys, added somewhere in there.
|
| It's not like every time I sign up for a new site I have
| to drop everything right at that instant and go add a
| passkey to every single device I own.
| 6510 wrote:
| > And _if_ your, say, Apple keychain is compromised, you
| can just revoke the passkeys from your Apple keychain from
| all the websites (yes it's tedious, but it's doable).
|
| without the key?
| FireBeyond wrote:
| > The nice thing about passkey is that unlike password, you
| can have multiple per account.
|
| I would charitably estimate that of the sites currently
| supporting Passkey, the ones that support multiple passkeys
| are in the single digit percentage. So, practically, you
| can't.
| vel0city wrote:
| As someone who actually uses them in a lot of places, the
| number of sites I know that only allows a single passkey
| is one: PayPal. What other sites do you know only allow a
| single one?
| paxys wrote:
| > I already have a universal solution for credentials:
| 1password, which is cross-platform.
|
| You can store passkeys in 1password so they work everywhere.
| NikolaNovak wrote:
| The article is 80% about friction and confusion in trying
| that solution - from confusing prompts and endless questions
| designed to wrestle control over to local ecosystem, to use
| cases that just don't work with external vendor as opposed to
| native platform owner :-(
| lxgr wrote:
| Which use cases don't work with external implementations,
| but do with the first-party one? I have yet to encounter
| one on iOS and macOS.
| pas wrote:
| https://github.com/keepassxreboot/keepassxc/issues/10374
| Passkeys not working on certain sites
|
| I suspect 1password also has at least a few sites that
| need special handling
| onetwothreepass wrote:
| But 1password forces you to install the browser extension to
| do this.
| ElFitz wrote:
| I don't know about 1password, but proton pass supports
| passkeys, on both iOS, Safari & Chrome (and probably others).
| freehorse wrote:
| I use proton pass and have the same issues as the author.
| Whenever macos/ios is in the mood it lets me use it to store
| passkeys, else it is an endless maze of bugs and confusion.
| Proton pass supports passkeys but the OS does not always let
| it communicate with the website.
| lxgr wrote:
| Any chance that this is actually due to websites requesting
| weird WebAuthN credential parameters (e.g. enforcing
| attestation, which software implementations by definition
| will not be able to support) or using the legacy U2F API?
| In my experience that's usually the culprit.
| freehorse wrote:
| No idea. I do not have the technical knowledge neither
| the time to check sth like that. I am totally clueless
| even as to where and how exactly passkeys are stored in
| my computer. For me they just work until they don't. It
| does not really help in trusting them as password
| replacement.
| loloquwowndueo wrote:
| Pretty sure 1password can store and use passkeys.
| sigzero wrote:
| It certainly can.
| 1oooqooq wrote:
| until the time comes that it's used for spammers and
| everyone requires providers from a list that only included
| apple and Google.
|
| y'all trying very hard to not see where this will go.
| lxgr wrote:
| This would be possible via attestation, but both Apple
| and Google _removed that feature_ when they replaced
| their respective device-bound authenticator
| implementations with cloud-synchronizing ones. (Google
| technically still allows creating device-bound ones and
| supports attestation in that case, but that 's arguably a
| niche use case and not what people are talking about when
| they say "passkeys".)
| onetwothreepass wrote:
| It does, but 1password forces you to use the browser
| extension in order to manage passkeys.
|
| I still don't trust browser extensions. I'm probably being
| irrational, but it is hard to find good sec info on how
| "safe" extensions really are.
| Arnavion wrote:
| If you're copy-pasting passwords from 1password into your
| browser you're making yourself vulnerable to phishing. The
| browser extension's autofill will at least check the domain
| name and prevent that.
| grahamj wrote:
| I moved away from 1P some time ago due to their move to a
| subscription model. After trying other solutions and having
| high hopes for Apple finally shipping a passwords app I finally
| decided to move back this year.
|
| It's costly but excellent. I have several accounts shared with
| my wife and was getting caught up in the passkey problems you
| mentioned. Even though 1P handling OTP is not really 2FA it's
| very convenient and still more secure than no OTP. I also don't
| always want to have to have my phone on me.
|
| On top of that I like knowing that if I change my mind at some
| point I can export my credentials. Moving my iCloud keychain
| creds was an eye-opener: it felt purposefully painful. You can
| do it but much of the metadata is missing or lost in the
| process, with the titles being the URLs. Yuck.
| ramon156 wrote:
| Switching from 1p to icloud makes sense, but there's a decent
| chunk that isnt in the apple ecosystem. I'm keeping 1p for
| now, I'd even argue that the price is pretty good, especially
| for families.
| onetwothreepass wrote:
| I prefer to pay for something as important as a password
| manager. It's like some people get excited about all-you-can-
| eat sushi: sorry, but raw fish isn't something I want to go
| super-cheap with.
| lxgr wrote:
| Using 1Password as your passkey backend seems like it would
| solve all the problems you're describing, except that passkeys
| are (for the time being, at least) locked in to 1Password [1].
| It works on multiple OSes (as a native passkey backend on iOS,
| via browser extensions providing WebAuthN on all major OSes)
| and isn't tied to your Apple ID.
|
| If you care a lot about exportable passkeys, Bitwarden (and
| Vaultwarden) can export them. Not sure if any other
| implementation can import them at the moment, but the data
| looks portable enough (i.e. it contains the ECDSA private key
| and all other client properties required).
|
| [1] https://support.1password.com/save-use-passkeys/ mentions
| that "Passkeys saved in 1Password can't be exported at this
| time."
| johnmaguire wrote:
| 1P will support it in a standards-compliant way soon:
| https://blog.1password.com/fido-alliance-import-export-
| passk...
|
| KeePassXC also supports export but not yet using the
| aforementioned standard:
| https://github.com/keepassxreboot/keepassxc/issues/11363
| sheepybloke wrote:
| Same, I use bitwarden and it keeps all my passkeys in it and
| is available on all my devices.
| pcl wrote:
| _"But even with Apple, I can 't sync stuff between my personal
| and work computer because they use different Apple IDs, even
| though the underlying true identity (me) is the same."_
|
| Apple has recently addressed this. You can now create shared
| groups, and selectively assign passwords and passkeys to the
| groups. You could easily create a group with your two
| identities and move the credentials to that group.
|
| https://support.apple.com/guide/iphone/share-passwords-iphe6...
| mcshicks wrote:
| Like this
|
| https://www.congress.gov/bill/118th-congress/senate-bill/884...
| efitz wrote:
| I think that we should consider passing a law that a vendor may
| non disable "log in with" and supporting functionality like
| password recovery, for a user account for some lengthy period
| of time after involuntary termination of the user.
|
| But I think that the bigger issue is that I don't think that
| large corporations should be allowed to disassociate with their
| users except in the case where criminal activity against that
| company is involved. This is especially important now that all
| the vendors want ecosystem lock-in AND have ToS that allow them
| to cancel pretty much arbitrarily.
| gwbas1c wrote:
| > is required by law to provide a storage so that the user can
| plug in their single, universal, transferrable set of security
| credentials (like passkeys)
|
| Wow, that will immediately become a prime target for hackers /
| phishers.
| CamperBob2 wrote:
| So?
| gwbas1c wrote:
| Then we're getting to a point where the proposed law
| weakens passkeys to the point where they are much ado about
| nothing.
| throw0101d wrote:
| > _I cannot bring myself to agree to any "switch to passkey"
| prompt from any device because I have no idea (and too tired to
| figure out) how and where that key will be stored, how do I
| deal with different devices, etc._
|
| There is a draft standard in the works for export/import:
|
| * https://fidoalliance.org/specifications-credential-
| exchange-...
| joe_the_user wrote:
| _each computing device manufacturer is required by law to
| provide a storage so that the user can plug in their single,
| universal, transferrable set of security credentials (like
| passkeys)_
|
| Indeed and that law would provide overrides for the state. And
| which state, you might ask? All of them? The state where the
| device is manufactured? Hmm...
| exabrial wrote:
| That was called "U2F", but we made it "better" with PassKeys!
| trollbridge wrote:
| Most passkey stores refuse to let you export them, and the real
| reason is vendor lockin. (They also did this with TOTP keys.)
|
| Bitwarden is one of the few that don't - you can export passkeys,
| although for now, there's nothing to import them to unless you
| want to run a roll your own open source solution.
| growse wrote:
| > Most passkey stores refuse to let you export them, and the
| real reason is vendor lockin. (They also did this with TOTP
| keys.)
|
| Does this mean that any HSM where inability to export the
| private key is a _feature_ is also doing it for "vendor
| lockin" reasons?
| redserk wrote:
| If you're buying and implementing a HSM, you really ought to
| understand this concept. After all, you're getting paid to.
|
| I do not expect random consumers to understand this concept.
| It's grossly irresponsible and is simply user abuse.
|
| I love Passkeys. They're fantastic. I do not love how
| unportable the implementations for Average Joe and Jane are.
| fireflash38 wrote:
| It's both. Most of those vendors have ways to backup those
| keys securely to same vendor backup product. But they won't
| let you export them via a wrap or whatever.
|
| It functions both as a security feature and a vendor lock in.
| EvanAnderson wrote:
| It's absolutely vendor lock-in, first and foremost. It
| happens to align with security.
|
| I did a project 10 years ago to sign firmware for embedded
| devices w/ a planned 25 year product life. I spoke with two
| different HSM vendors. Both said the Customer would be able
| to backup and transfer keys from one HSM to another. Both
| also said that was applicable within their products only.
| There was no mechanism to switch to another HSM vendor (and
| neither offered a contingency to get the keys out if the
| vendor ceased business operations).
|
| Apparently this situation has gotten no better in the last
| 10 years:
| https://www.icann.org/en/system/files/files/hardware-
| securit...
|
| > In April 2023, IANA became aware of the decision by the
| manufacturer of the Keyper PLUS HSM - the equipment used to
| store private key materials for the Root Zone KSK - to
| cease its production of the device. Furthermore, the
| manufacturer will offer no successor product.
|
| That's ridiculous.
|
| There should be a standards-based protocol to transfer key
| material between HSMs. It should be tied to physical access
| using physical tokens. Make the protocol baroque and
| difficult. Heck, even make it a requirement the source HSM
| has to to be physically destroyed to complete the process
| (to prevent "cloning" attacks).
|
| For USB authentication keys this level of cloak-and-dagger
| LARPing is stupid. There should be a method to export and
| encrypted copy of the contents of my USB token and, worst
| case, import it into another token manufactured by the same
| provider. ("But cloning!" Fine-- tie it to registering the
| token with the manufacturer along with real-world identity
| verification. Make it a premium service with an associated
| cost, if that's what it takes.)
| 2OEH8eoCRo0 wrote:
| A YubiKey is not an HSM
| croes wrote:
| It's one of the reasons
| eigenspace wrote:
| Import and export of passkeys is coming "soon" to 1Password (as
| of October): https://blog.1password.com/fido-alliance-import-
| export-passk...
|
| I think some vendors do have intentions of locking in users
| with passkeys (*cough* Apple *cough*), but I also think it's
| also not the only explanation for why import and export isn't
| supported by most managers.
|
| A more charitable explanation would be that since passkeys are
| 'new', there's less people demanding import/export since they
| have very few passkeys to move around, and at least some
| vendors wanted to take time to develop a good solution for it /
| focus resources on actually getting the daily usage of passkeys
| working.
| thugcee wrote:
| KeePassXC imports passkeys from Bitwarden:
| https://github.com/keepassxreboot/keepassxc/pull/11401/files
| batata_frita wrote:
| Vendor Locking-In should be classified as an anti competitive
| practice.
|
| The year is 2025 (almost), and we're still suffering with
| companies closed garden syndrome.
| criddell wrote:
| Don't most sites let you create multiple passkeys which would
| avoid lockin?
| croes wrote:
| Imagine you switch from iOS to Android, now you need to
| create a new one for every site that need uses passkeys. Not
| to mention the hassle if you forgot one.
| WorldMaker wrote:
| In most cases it is as simple as: Download the Apple
| Passwords app on Windows and use it to login to that site
| on Chrome and then add a new "Google Passkey" in Chrome. It
| _is_ a hassle, and the UX isn 't entirely there today to
| make it feel "easy" or "seamless", but it is a _simple_
| hassle, relatively.
| recursive wrote:
| So you have to get a windows machine to switch to
| android? That doesn't sound like a solution.
| WorldMaker wrote:
| No that's just assuming the 70%+ case "average part of
| the bell curve" where a user switching iOS to Android
| already has a Windows machine somewhere. Remove the
| install step of the Apple Passwords app in the rarer case
| that the user has a Mac or iPad as their primary "other
| device".
|
| (If the hypothetical user was using Linux machines
| already by that point, they wouldn't have been using iOS
| Keychain for their Passkeys in the first place and
| probably would have the necessary skills or tech guru
| friend to load up Apple Passwords in a WINE session or in
| a Windows VM/dual boot.)
|
| All else fails, there's always most sites will continue
| to (forever) fallback to email-based recovery because we
| should all face it that email accounts have been the
| average user's primary password manager for decades
| anyway.
| jamesboehmer wrote:
| It may partially be because of vendor lock-in, but I think the
| real reason is security. For example with Apple's Secure
| Enclave hardware, you give secret-generation responsibility to
| this chip, and can never see the value. I use it for SSH
| private keys, which are meant to be disposable/changeable. As
| much as I want to own and control all my data, I personally
| think this is pretty good footgun protection, and I'm ok with
| being unable to export my passkeys from 1password (and for the
| record, 1password does not prohibit TOTP exports).
| Borealid wrote:
| This is extremely obvious in the new FIDO specification for key
| export, where they neglect to specify the format in which the
| private keys are encoded.
|
| In other words, it's a "standard" designed to let Apple,
| Google, and Microsoft enable portability between each other,
| but to keep software like KeePass out of the mix.
| lxgr wrote:
| This really is the least problem.
|
| As long as the key export API isn't actually gated (e.g. by
| only working over a backend-to-backend API with a mandatory
| "security audit" to gain access, by wrapping exported keys
| using vendor-specific keys and requiring a similar audit to
| be included as an export target etc.), everything else can be
| figured out. There's only so many ways you can encode an
| ECDSA key.
| comex wrote:
| Isn't that here?
|
| https://fidoalliance.org/specs/cx/cxf-v1.0-wd-20241003.html#.
| ..
|
| The private key is specified as being a "PKCS#8 formatted
| byte string which is then Base64url encoded". Is that
| insufficient?
| daft_pink wrote:
| I believe they are trying to make a common import/export
| mechanism to prevent vendor lock in.
| cchance wrote:
| I mean... i register in my most common one, and if i cant use
| that passkey store on another pc like at work... i just ...
| register another passkey there, you do it once an your done,
| once at home and once at work,
| Groxx wrote:
| Not just "most passkey stores". _The spec_ has _nothing_ about
| export /sync, so they've been working around it by hand.
|
| There is a process of drafting a decision to put before the
| committee to change this ~now[1], but tbh I think the omission
| from v1 is a strong sign that the omission is _literally
| intentional_. I 'm sure spec authors will disagree, as I am
| sure that many are well-meaning... but there are very strong
| incentives for the current giga-corps to impede and complicate
| it during design phases, as they are now doing to the UX. If
| backups and device-loss considerations for such intensely
| personal data is not baked in, simply, _and mandated_ from day
| 1, it 's intentional by _someone_.
|
| [1]: https://blog.1password.com/fido-alliance-import-export-
| passk...
| Nekit1234007 wrote:
| One of the Passkeys/WebAuthn spec people made a huge fuss over
| how KeePassXC did their export function
| https://github.com/keepassxreboot/keepassxc/issues/10407
| thefz wrote:
| "Passkeys are not optimal because onboarding UX is etherogenoeous
| across vendors" is waaay less clickbaity thank the original
| title, but then I remember Ars has gone to shit as a tech website
| years ago, and close the page mid-article.
| recursive wrote:
| One problem with your proposed title is that "etherogenoeous"
| doesn't seem to be a word. Even it is, approximately no one is
| likely to know what it means.
| sunshowers wrote:
| The article is quite good, and as someone who uses passkeys I
| feel it. So far I've only been using them as a convenient
| alternative to passwords (passkeys go right next to passwords
| in 1password), and I plan to keep using them that way.
| jmclnx wrote:
| I will never use Face ID or Fingerprint for any device, but I
| agree, passkeys are a bit too much. Also, the OSs I use may not
| support passkeys. They are not on the list.
| lxgr wrote:
| Your OS doesn't need to support them; browser extensions can
| implement them too.
| eigenspace wrote:
| While I agree with many of the points raised by the author, I
| guess I just had much much more pessimistic expectations than
| they did. If I were to write an article on the topic, I'd
| probably end up listing the exact same factual information, but
| with the opposite spin: "This is progressing much quicker and
| more smooth than I would have anticipated!"
|
| Switching from passwords to passkeys is a _big_ change in the
| entire security model of the modern user-facing internet. We
| shouldn 't be at all surprised that people are both cautious and
| opinionated about how it should be done, how to migrate users,
| and how to deal with fallbacks.
|
| Yes, the current situation is one that is messy and not
| significantly more secure than the previous status quo, but the
| direction of travel seems at least promising.
|
| I wouldn't actually want my bank to overnight decide that
| passkeys are the way to log in, and if I use a passkey there
| should be no insecure fallback options. I want my bank to roll
| out a passkey, and figure out the infrastructure around it, probe
| for problems, and allow fallbacks that are equivalent to their
| previous systems. Similarly, I wouldn't want every passkey
| management implementation to instantly coalesce around one
| specific set of management practices and UX. I want various ideas
| to be tried out and see what comes out of it, even if some of
| those experiments are bad.
| Schiendelman wrote:
| The article you would write is the right article! But it
| wouldn't get shared and make the first page of HN.
|
| It's entirely possible people have written exactly the article
| you want, but our discovery mechanisms are all based on
| aggregate emotional reaction.
| growse wrote:
| Lots of criticism in the article, some of it valid, none of it
| constructive.
|
| Sure, there's UX problems as we're still trying to figure out
| what good looks like here. But in the absence of specific,
| concrete suggestions about how we improve usability for
| unphishable credentials, it seems that passkeys are a pretty good
| go. Perfect? No. Better than passwords? Undoubtedly.
| saagarjha wrote:
| The point of the article is that they are not actually better
| than passwords in a lot of ways that people actually want them
| to be better.
| growse wrote:
| One of the primary, explicit design goals of webauthn is that
| they're not phishable. Passwords are phishable.
|
| What are the other ways that people want passkeys to be
| better?
| saagarjha wrote:
| They want to share them across devices, sometimes even
| devices made by different vendors. They want to hand a
| passkey to a family member or friend. They want to not be
| concerned they will lose the passkey if the device they are
| on is lost. They want to understand what the passkey is
| actually doing for them when they log in, rather than it
| sometimes being both the username and password, sometimes
| just replacing the password, and sometimes becoming a sort
| of weird second factor thing. They want to know how they
| can change their passkey. The rollout of passkeys leaves a
| lot to be desired.
| growse wrote:
| I don't disagree with you about the UX. It could be
| better. It could be worse. What's your proposal on what a
| better UX might look like (along with getting everyone to
| adopt it)?
|
| > They want to share them across devices
|
| I do this today on Bitwarden, Apple users do this today
| with Keychain. Who's the "they" here?
|
| > sometimes even devices made by different vendors.
|
| > they want to hand a passkey to a family member or
| friend
|
| ..... Why? What's the use case here?
|
| Tying a credential to a single identity (and therefore,
| human) is another explicit design goal of webauthn. I
| seem to remember the original proposal was that locking a
| private key to a device in an unextractable, un-copyable
| way was an explicit benefit - if it can't be exported,
| then it can't be stolen/copied without the device also
| being stolen. This was softened with the purpose of
| allowing syncing amongst devices that already have a good
| story on sharing sensitive data, but this mechanism _does
| not exist_ generically. There is no standard way, right
| now, that my iPad and Pixel device can share a private,
| sensitive piece of information without the help of a 3rd-
| party syncing provider. Without that, cross-platform
| credential sharing can 't exist out of the box by
| default.
| jampekka wrote:
| > Why? What's the use case here?
|
| Tech support for relatives. Accessing accounts from
| different machines. Joint access for family members and
| friends. Emergency access when a phone or dongle breaks
| down or gets lost.
|
| Tightly device-tied authentication mechanisms are
| fundamentally out of touch with the real world.
| saagarjha wrote:
| I mean I like them in theory but they should just be
| passwords you can't easily copy from your password
| manager. You can export them, which I'm sure someone will
| trick people into doing, but that's somewhat different
| from being tricked into pasting ul0vek1tt3ns into
| legitimateapple-support.info.
|
| As for sharing passkeys: never grabbed a friend's Netflix
| account? Had to log into your kid's college application
| page to confirm your income? Sign up for an appointment
| for your elderly parents? This is a thing people actually
| need to do, and value more than avoiding being phished.
| Believe me. It's not worth abandoning for "ok there is a
| possibility someone can be phished if the key material
| isn't protected by a hardware key and three layers of
| DRM".
| michaelt wrote:
| _> What 's your proposal on what a better UX might look
| like (along with getting everyone to adopt it)?_
|
| The current passkey implementation is: Your
| google/apple/microsoft cloud account lets you log into
| websites without a password, using a 'keyring' of
| 'passkeys'
|
| But we already had countless websites with a "log in with
| google" button, for users who want to authenticate using
| their cloud account, and skip entering a password.
|
| So they could have just kept that... exactly how it was?
| rawgabbit wrote:
| The analogy is similar to swiping your credit card versus
| using Apple Pay. With "login using Google/Apple", you are
| submitting the username and password which could
| potentially be harvested by malware or a key logger. With
| passkey/Apple Pay, you are submitting a one time token
| that has no value in the Dark Web.
| robertlagrant wrote:
| > > they want to hand a passkey to a family member or
| friend
|
| > ..... Why? What's the use case here?
|
| This is the problem, if you can't even imagine this case.
| Someone in their 70s who isn't great with computers would
| likely be very happy to share their password with a tech-
| savvy child who can do some things for them. Passwords
| make this really easy, and you can even register a second
| MFA that goes to the child's phone/TOTP.
| rtsil wrote:
| You don't even need to be in your 70s or not tech-savvy.
| Password-sharing happens frequently between spouses,
| children/parents, friends and probably a lot of other
| cases.
| growse wrote:
| I share accounts with my spouse using passkeys just fine.
| We just register our own passkeys. _shrug_.
| ndriscoll wrote:
| My wife and I share passwords fairly regularly. Usually
| in a context where one of us is busy and wants the other
| to log into something they set up (e.g. to pay a bill),
| so the entire point is to not spend a few minutes going
| through an enrollment flow or whatever to give the other
| access (otherwise they'd just do the task). We may also
| not be in the same location when things like that come
| up.
|
| Tying a credential to a single human is exactly _not_
| something desirable for a subset of users. Some married
| couples essentially act as a single person in most
| contexts (e.g. sharing an email address and /or phone
| number), which kind of makes sense; legally (in many
| states) the point of getting married is that everything
| becomes shared. The goal is to reduce friction around who
| owns/has access to what.
|
| The real world obviously has different constraints, but
| works basically in this way. e.g. if I go to drop
| off/pick up a prescription for my wife, I just tell them
| her name, not mine. We use credit cards with the other's
| name all the time. etc.
|
| > What's your proposal on what a better UX might look
| like (along with getting everyone to adopt it)?
|
| Passwords, obviously.
| growse wrote:
| > My wife and I share passwords fairly regularly. Usually
| in a context where one of us is busy and wants the other
| to log into something they set up (e.g. to pay a bill),
| so the entire point is to not spend a few minutes going
| through an enrollment flow or whatever to give the other
| access (otherwise they'd just do the task). We may also
| not be in the same location when things like that come
| up.
|
| Mine too! We simply register multiple passkeys under the
| same "account" for a service and we can both log in as
| the same identity. Have I missed something? Why is this
| hard?
|
| > Passwords, obviously.
|
| Passkeys are trying to solve the phishing problem. I
| guess pretending that the problem doesn't exist is also
| some type of solution, but I don't think it's a very good
| one.
| recursive wrote:
| > Why? What's the use case here?
|
| I had a tele-medicine visit scheduled regarding my son.
| When I logged in, it said I wasn't authorized. My wife
| had no problem. So she gave me her password. We both
| logged in as her. Everything was fine. I'm sure this was
| some record-keeping issue, but if we had been using
| passkeys, I just would not have been able to participate.
| sunshowers wrote:
| > ..... Why? What's the use case here?
|
| Others have pointed out use cases, but please step back
| for a second. Sharing passwords is extraordinarily common
| for a variety of legitimate reasons.
| growse wrote:
| And why do they do it? What are they trying to achieve?
|
| I'd guess that they most likely want multiple people to
| be able to access a single account. Passwords are forced
| to be shared because a password is typically implemented
| as a single credential - there's one valid password for
| that account.
|
| This is .... not true for passkeys. If you want two
| people to access the same account, they both add passkeys
| to that account.
|
| Sharing passwords happen because of a _property of
| passwords_. It 's not some fundamental requirement that
| people have. What people want is shared access.
| eadmund wrote:
| > Passwords are phishable.
|
| Passwords auto-filled by a browser extension are not
| phishable.
| growse wrote:
| What stops the user pasting their password out of their
| password manager into a random evil site? Auto-fill isn't
| infallible.
|
| This isn't a controversial topic, the data is pretty
| unambiguous. If you give humans a secret they can put in
| their clipboard and train them to enter it into text
| boxes, some fraction of them will send their credentials
| to the wrong people.
| saagarjha wrote:
| Maybe we don't actually need perfect solutions.
| robertlagrant wrote:
| "Maybe" is not a viable justification for a position.
| saagarjha wrote:
| I am being flippant. Obviously my position is that
| perfection is a harmful thing to strive for.
| growse wrote:
| We're not aiming for "perfect", we're just trying to make
| some progress on the phishing problem.
|
| The irony here is that many of the complaints in this
| thread seem to be complaining about how imperfect
| passkeys are. No-one disagrees that they're imperfect!
| ndriscoll wrote:
| The same thing that stops the user from going through an
| account recovery flow to enroll an attacker's key. Such
| flows are of course more necessary in a world where you
| can easily lose/damage the only place where your keys are
| stored.
| jtbayly wrote:
| This. In other words, password managers have all the
| benefits and none of the drawbacks of passkeys. And
| passkeys require a password manager anyway, so why are we
| trying to switch?
| robertlagrant wrote:
| They don't have the benefit of not being pastable into a
| phishing site.
| samcat116 wrote:
| Should password managers make it impossible to copy the
| plain text of the password? Thats the only way to make
| this truly not phishable
| growse wrote:
| If you show it on a screen, someone will read it out and
| type it into a website. We don't need to guess at this,
| it happens a lot in the real world.
|
| No matter how many UX barriers you put in place, an
| exportable credential _will_ be handed over to an
| attacker by an unwitting user at some point.
| snowwrestler wrote:
| "Huh, wonder why that didn't autofill this time." Person
| copy/pastes password from manager into phishing site.
|
| Browser extensions do not _prevent_ copy /pasting, or
| typing in, passwords. In contrast, there is no way to
| copy/paste or type in a passkey if the phishing site
| fails the key check.
|
| Now you might say that YOU have the discipline to never
| do this. And it might be true. But that's not the same as
| saying autofill passwords are not phishable.
| magicalhippo wrote:
| I just wanted a standard data exchange interface between my
| browser and my preferred password manager, so that my
| password manager didn't have to try to emulate a human
| being typing or pasting a password.
|
| That way the password would only "live" in the password
| manager and wouldn't need to even be easily visible to me.
| I almost never care what the password actually is.
|
| But it would still be a password so compatible with most
| sites as-is, and easily backed up and restored on new
| devices.
| ghjfrdghibt wrote:
| I don't think it's the responsibility of the author to make any
| constructive input to the passkey problem. The point of the
| article is to show the valid shortcomings of this technology
| that a bunch of companies are attempting to force on users.
|
| My workaround to allow passkeys to be reasonably usable is to
| use my password manager, just like the author of this article.
| This makes passkeys essentially the same as passwords.
|
| At no point am I tying account access to a device, or series of
| devices, as this is ridiculous and unusable.
|
| Passkeys as encouraged by the big companies are all about
| vendor lock-in than security.
| growse wrote:
| > I don't think it's the responsibility of the author to make
| any constructive input to the passkey problem.
|
| Oh, it's not their responsibility, sure. But moaning about
| the UX without considering the trade-offs and decisions that
| got us to this point isn't very useful. Passkeys are badly
| implemented on some sites. _So let 's fix that_.
|
| > This makes passkeys essentially the same as passwords.
|
| Passkeys in a password manager are fundamentally different to
| passwords. Try copying the passkey private key into your
| clipboard from your password manager.
|
| > Passkeys as encouraged by the big companies are all about
| vendor lock-in than security.
|
| The fact they prevent phishing is just a useful side-effect?
| This is veering into conspiracy theory territory.
| cypherpunks01 wrote:
| Anyone know what adoption rates for passkey looks like now? I
| think they are cool too, but the constant prompting to create
| them and invisible/variable UI everywhere is a problem. It
| presents as inconsistent as compared with the standardized
| username/password form that grandmas understand.
| eadmund wrote:
| > And forget about trying to use a passkey to log into PayPal on
| Firefox. The payment site doesn't support that browser on any OS.
|
| I had no idea! That's pretty awful.
|
| > Somehow, the mysterious entity responsible for this message
| (it's Google in this case) has hijacked the process in an attempt
| to convince me to use its platform.
|
| I do _not_ want Google to be managing my passkeys or passwords.
| Even if they promise to keep them device-local, I frankly don't
| believe them: the temptation to make it easy for users who have
| lost a device or forgotten a password is too strong, and at some
| point they will take the plaintext, and then it is game over as
| far as security is concerned.
| ballenf wrote:
| I don't know. If you're in the iOS ecosystem and using iCloud
| syncing and Safari things are super easy and default more secure
| than without passkeys. The author's examples of Firefox, chrome,
| a password manager and a physical key apply to very technical
| users who seem quite capable of navigating the complexities he
| complains of.
|
| The vast majority of people are just not going to encounter most
| of his issues. I sympathize with his issues, but he's kind of
| complaining that fighting the ecosystem is complicated.
|
| My guess is that <<1% of people use his combination of multiple
| browsers a non-iCloud pw manager and a physical key on MacOS. And
| they're not substantially less secure than his setup.
|
| My only issue with passkeys is sites that don't seem to have them
| figured out yet. They'll let you setup a passkey but then offer
| to let you sign in with a password first. These seem to be
| becoming more rare, but even amazon's passkey seems random when
| it lets me use it. And even then it wants to send me a text
| message code anyway (this is probably a setting somewhere, so my
| fault I'm sure).
| hkpack wrote:
| > They'll let you setup a passkey but then offer to let you
| sign in with a password first.
|
| I am not sure if that is what you're talking about, but the
| standard way to implement login with passkeys is to use a
| normal username/password form and leverage the auto-fill
| mechanism to offer you to sign with a passkey if it is
| discoverable.
|
| Another way is to have a two-step login, where you enter your
| login/email in the first step, and then use passkey to login in
| the next.
|
| There are benefits and drawbacks in both of them.
|
| Also, passkey can be used with multiple authenticators (like
| Yubikey), and most popular websites consider that verification
| of the user is not implemented sufficiently for some of them to
| be used as the only way of authentication, so they don't allow
| you to login with them without a second factor (i.e. password).
| sneak wrote:
| It gets worse. U2F keys were stateless, the site key pair was
| stored by the site (encrypted to, and by, the u2f key). Now,
| passkeys are stored _in the device_ , and, you guessed it - they
| have a limited number of slots.
|
| The fido2 situation is really bad.
| ttyprintk wrote:
| 25 on my YubiKey. Would 100 be enough?
| Borealid wrote:
| A Yubikey purchased today actually allows 100 discoverable
| credentials. Keys running older firmware stored a max of 25.
| ttyprintk wrote:
| Thank you
| FireBeyond wrote:
| If you don't get old stock - wasn't there some issue
| recently where they were still selling Yubikeys with the
| known vulnerability saying that "unless you knew about the
| vulnerability and specifically had a need to avoid it and
| told them", that that wasn't a problem?
| lxgr wrote:
| Both are awkward in that I could reasonably expect to exceed
| them in the lifetime of a hardware authenticator.
|
| The ideal number would be infinite and is in fact very
| achievable with a very small API modification, but alas, the
| WebAuthN working group didn't consider it necessary:
| https://github.com/w3c/webauthn/issues/1822
| jlokier wrote:
| I have about 1000 accounts in my password manager. 100
| passkeys to replace them is not enough. I wouldn't feel
| comfortable with that as a hard limit, if it's to replace all
| passwords.
|
| Many of those 1000 are obsolete (old accounts I'll never use
| again), but many are not. At least 30 are things I use every
| week, most of them financial or tech admin, i.e. not social
| media. I'm confident (though not certain) that I login to
| more than 100 accounts over a typical year, and there are
| accounts that I sometimes login to more than a year since the
| previous time, glad that I recorded the credential.
| WorldMaker wrote:
| Not all passkeys need to be stored on the device. This is
| exactly what things like key-derivation functions are for. You
| can have a "primary" device key that derives a Passkey based on
| the site address with maybe a little salt and/or pepper (but
| maybe not needed with most KDFs).
|
| FIDO2 allows that just fine, it's a complicated dance between
| the hardware vendor and the OS right now if your particular
| hardware device uses a full slot per Passkey or derives the
| Passkey from some "primary" key.
| mongol wrote:
| I haven't used passkeys, I have not been prompted about it, asked
| to create one, been reminded to change to it, or anything like
| that. It is like they don't exist to me. Am I supposed to be
| nagged about it in order to change to it? Or is it something you
| have to hunt for in the account details of a site? Unsure if I am
| a late adopter or if the technology has not found me yet.
| throwaway894345 wrote:
| Google, GitHub, and a few other services have bagged me to
| create passkeys. I haven't tried hard to understand how to use
| them, but at some point I created one on one device and
| whenever I try to log in from a different device it doesn't
| work but passwords and MFA work just fine across devices so I
| mostly just ignore it. Annoying that a lot of services are
| pushing passkeys as the default mechanism though.
| mongol wrote:
| Did you use 2FA before? I use it, possibly they deem my
| security good enough because of that?
| the_clarence wrote:
| I moves to an android phone to buy a folding phone and I lost all
| my passkeys. Its a nightmare
| Borealid wrote:
| The article author skirts around the key true observation here,
| which is that passkeys were a great idea until cloud vendors
| waged war on hardware keys.
|
| The concept of a passkey as desired by Yubico was that every user
| buys a set of hardware keys, uses those instead of passwords, and
| has no ability to authenticate otherwise.
|
| The concept of a passkey as desired by Apple, Google, and
| Microsoft is that every user magically authenticates using their
| OS, and has no ability to authenticate otherwise.
|
| The reason the UX is confusing is because the OS vendors don't
| want the users using non-OS software or hardware - they want you
| to use a cloud-hosted passkey instead of using a Discoverable
| Credential on a Hardware Authenticator, and instead of using a
| password manager providing its own sync facility. This is shown
| in the screenshots in the article.
|
| The ideal future state is:
|
| * the provider for newly registered credentials would be a
| browser setting
|
| * the setting would come configured to use the OS vendor out of
| the box
|
| * installing a password manager providing passkeys would prompt
| to change the setting to use the password manager instead
|
| * one of the options in this setting would be "prompt me every
| time". Approximately nobody would choose that option
|
| * there would never be a prompt for what to use on authenticate()
| calls, only register(). Authenticate would use whichever valid
| credential you provided first, whether that's plugging in a token
| or scanning your thumb to unlock a TPM or whatever
|
| In this world, 99% of people are using OS-vendor-provided cloud-
| synced passkeys, but technical users get what they want too and
| everybody has both a secure and an easy experience.
|
| The thing stopping us from getting to that ideal state is that
| the provider of the FIDO "platform" (the software that lets you
| choose a key to use) is the OS vendor instead of the browser
| vendor, and they have a conflict of interest because the OS
| vendors are also cloud services vendors.
| fastball wrote:
| What is the benefit to Apple?
| neogodless wrote:
| Doesn't Apple primarily want the best user experience, and
| the safest way to use devices? So they should get onboard
| with what is best for the user.
| Borealid wrote:
| No, Apple directly benefits in that users only get the
| "magical" user experience when using Apple devices. There
| are two perverse incentives: one for Apple to lock their
| users into their platform, and one for Apple to implement a
| "better" experience unilaterally. Apple does both of these
| things.
|
| Today, if I create a passkey on an Apple iPhone, and I pay
| Apple a monthly fee for iCloud, I can then walk over to an
| Apple Macbook I own and sign in to the same web site
| without another step.
|
| But if I don't pay Apple a monthly fee, OR the phone isn't
| an iPhone, OR the laptop isn't a Macbook, then I don't get
| that user experience.
|
| There is absolutely no technical reason that I shouldn't be
| able to get precisely the same level of security and
| precisely the same user flow without having to need all the
| devices to be Apple. But Apple chooses to restrict how it
| can happen.
| kalleboo wrote:
| Apple allows you to use third party apps as passkey
| providers
| mercutio2 wrote:
| Why do you say you have to pay a monthly fee for iCloud?
|
| None of the technology you're discussing here requires a
| paid account.
|
| You may, separately, decide to sync more than the meager
| free quota of data on iCloud, but that's an unrelated
| issue. You're welcome to use iCloud just for keychain
| sync.
| baby_souffle wrote:
| > Doesn't Apple primarily want the best user experience,
| and the safest way to use devices?
|
| Presumably, yes.
|
| > So they should get onboard with what is best for the
| user.
|
| What happens when there's a conflict? They usually go with
| the option that screws the smaller niche user base.
| daft_pink wrote:
| If all your passkeys are synced to Apple, then it makes it
| really easy to use that new Apple device and really hard to
| use that PC/Android Phone/Meta VR headset/etc.
|
| They are trying to make an import/export mechanism to prevent
| vendor lock in, but what if I want to still use my iPhone and
| my Meta VR headset. Import/export doesn't mean sync :(
| samcat116 wrote:
| Every passkey setup flow I've ever seen has allowed me to use a
| hardware key or the OS provided store. Am I missing something?
| Borealid wrote:
| Have you:
|
| A) read the article, paying particular attention to the
| screenshots therein (ESPECIALLY particularly to the user
| experience on an Apple device), and
|
| B) noted the part of my comment where I say that I should be
| able to set the choice of using hardware keys one time
| instead of needing to do so every time I create a new
| credential?
|
| Today it's so hard to use a hardware key with Google Play
| Services that I (a software developer who actually works in
| this field) have had users tell me their phone didn't let
| them do it at all. In reality, the support was there, is was
| just so unusable they didn't even understand they had that
| option.
| berdario wrote:
| Some flows might allow only Platform authenticators
| (disallowing external hardware keys)
|
| https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Gu.
| ..
|
| https://www.reddit.com/r/webauthn/comments/197ggm7/comment/k.
| ..
|
| The only one that I witnessed, is the optional passkey for
| restoring your Whatsapp account
| lxgr wrote:
| > The concept of a passkey as desired by Apple, Google, and
| Microsoft is that every user magically authenticates using
| their OS, and has no ability to authenticate otherwise. [...]
| The reason the UX is confusing is because the OS vendors don't
| want the users using non-OS software or hardware
|
| Completely untrue. Both iOS/macOS and Android offer an API for
| third party passkey implementations ("backends"). macOS also
| offers a client API for that that browsers ("frontends") can
| hook into. You can use Strongbox (a KeePass implementation)
| with Chrome, iCloud Keychain with Firefox, a Yubikey with
| Safari...
|
| It's really as open an ecosystem as it gets at this point, and
| for software implementations, there isn't even attestation that
| could allow relying parties to block any specific
| implementation.
|
| > The thing stopping us from getting to that ideal state is
| that the provider of the FIDO "platform" (the software that
| lets you choose a key to use) is the OS vendor instead of the
| browser vendor [...]
|
| No, this "ideal state" is in fact the reality I've been
| experiencing for the past few months.
| Borealid wrote:
| If this is so, could you explain why the dialog for a Google
| Play Services webauthn login today says "use passkey"
| (meaning "use google-account-hosted passkey") and "try
| another way" (meaning "present an options page to let me
| choose, after another click, a passkey that doesn't happen to
| be a google one")? How about the bit in the article where the
| Apple signin screen says "unlock with TouchID" and you have
| to decline to do that TWICE before you can use a hardware
| key?
|
| Yes, it's technically possible to use hardware keys today.
| No, it's not ideal - specifically, what's broken is:
|
| * the user experience where all three major platforms attempt
| to make it more difficult to use anything other than their
| platform.
|
| * the ability to sync cloud-hosted passkeys between the major
| vendors AND self-hosted options
|
| * the ability to decline to use the OS vendor platform once,
| instead of needing to decline it on EVERY SINGLE SITE, EVERY
| SINGLE TIME
|
| > there isn't even attestation that could allow relying
| parties to block any specific implementation
|
| This is, unfortunately, not true. FIDO2 credentials have
| support for an "AAGUID" and a signed attestation certificate
| that does, in fact, allow blocking particular
| implementations.
| lxgr wrote:
| > How about the bit in the article where the Apple signin
| screen says "unlock with TouchID" and you have to decline
| to do that TWICE before you can use a hardware key?
|
| > * the ability to decline to use the OS vendor platform
| once, instead of needing to decline it on EVERY SINGLE
| SITE, EVERY SINGLE TIME
|
| This doesn't happen once you disable iCloud Keychain as an
| autofill option in the device settings in favor of a third-
| party integration. You could of course argue that it's
| anticompetitive of Apple to enable their integration by
| default, but I had to do this exactly once, not every time.
|
| > This is, unfortunately, not true. FIDO2 credentials have
| support for an "AAGUID"
|
| Yes, but neither Apple (at least for non-MDMed devices) nor
| Google (for synchronized credentials) provide attestation,
| so any relying party enforcing attestation implicitly
| excludes the two largest implementations, making it a non-
| starter for most use cases.
|
| > the ability to sync cloud-hosted passkeys between the
| major vendors AND self-hosted options
|
| This would be nice from a usability point of view, but it
| sounds like a nightmare to do securely. I'd be fine with a
| one-time import/export option, and that's being worked on.
| teeray wrote:
| > It's really as open an ecosystem as it gets at this point
|
| However, they fumbled the introduction by trying the "maximum
| vendor lock" approach first. Now they need to convince
| everyone otherwise, even if technically it's open now.
| WorldMaker wrote:
| I disagree somewhat that that is a "fumble" so much as a
| symptom of what was necessary to get mainstream acceptance,
| what a lot of us on HN see as "maximum vendor lock" is
| _also_ an attempt at building a "pit of success" for
| average, "boring" users. An "Uncle Charlie" with an iPhone,
| an iPad, and a Mac that trusts Apple and was already using
| iCloud Keychain as their primary password manager is going
| to have an _easy_ time with passkeys and is going to have a
| harder time accidentally enrolling a passkey they don 't
| understand or know how to use the next time or next device
| they login from. That's a reasonable "pit of success" for
| an average, "boring" user.
|
| There's a lot of users that isn't great for. Especially
| there are statistically a lot of iOS users that use Windows
| desktop/laptops that Microsoft and Apple are trying to
| bridge but don't always have the best UX today. Same for
| Android and Windows users, there's statistically even more
| of those.
|
| Also, as you can tell from HN comments every time Passkeys
| come up, HN is full of anecdotes of the craziest mixed
| device ecosystems people can build. We can be a loud set of
| users, and we certainly need the most convincing that our
| "power user" needs are met for all of our complexity
| requirements.
| lxgr wrote:
| I largely agree, except for this:
|
| > anecdotes of the craziest mixed device ecosystems
| people can build
|
| All it takes is for somebody to use both an iPad and an
| Android phone. iPads are relatively cheap (cheaper than
| many Windows laptops!); iPhones are quite expensive.
| That's a lot of users right there, and I think it must be
| at least as common as Windows + iOS users.
| WorldMaker wrote:
| Right. That is not what I meant by "craziest mixed device
| ecosystems", and yes, I agree that Android + iPad is a
| common enough situation that needs good defaults that we
| haven't yet entirely solved for (but there are options
| today and hopefully it will get better). Windows "knows"
| it has to be a bridge device with whatever the user's
| phone ecosystem is, iPadOS today mostly assumes the
| user's phone "must be" an iPhone. From Apple's
| perspective that still makes sense as a useful "default"
| for what they consider to be their average user.
| lxgr wrote:
| I also wish they'd have started off like that from the
| beginning.
|
| It might have taken them a bit longer to get the initial
| implementation out the door, but it would have avoided all
| of these discussions, which I'm certain are also impacting
| WebAuthN/passkey adoption across the web (assuming that the
| views on passkeys here are at least somewhat representative
| of technical decisionmakers).
|
| But if the choice is between getting to the status quo via
| suboptimal intermediate steps or not having WebAuthN and
| passkeys at all, the former seems much preferable.
| palata wrote:
| > No, this "ideal state" is in fact the reality I've been
| experiencing for the past few months.
|
| I agree that technically, it seems possible to choose between
| hardware keys and OS passkey. But I also agree with the
| article that they try to push their own solution by hiding
| the alternatives, and that should not be allowed.
| mikepurvis wrote:
| Looks good until Mallory sets up a phishing site that tricks
| users into installing a thing that registers itself as their
| "password manager" and mitms their entire life.
|
| Not saying there aren't other reasons the OS vendors are
| pushing back on supplying that hook, but that's one that is at
| least vaguely pro-user.
| amluto wrote:
| I think a critical feature is missing that makes this almost
| entirely unworkable: usable handling of backup tokens. There is
| no way to register a token in a safe. There is no way to name a
| token to keep track of which one it is. There is no intelligent
| way to migrate from one token to a new one. Working with two
| computers with mutually incompatible ports is incredibly
| annoying.
|
| NFC tokens have basically no security against a close range
| attacker. How much this matters depends on the threat model.
|
| Also: the cloud vendor passkeys (Apple, Google, etc) are _far_
| more secure against an attacker that steals a device.
|
| This is not to say that cloud based passkeys are amazing.
| AFAICT there is nothing remotely resembling an automated way to
| rotate a key. I'm not even convinced it can be done manually in
| a straightforward manner. This is not so great, given that a
| passkey is effectively an unlimited lifetime key pair with no
| revocation mechanism, that may well be stored without hardware
| security and that can be propagated to different generations of
| devices. Also, what happens if a device is stolen and
| compromised at least enough to keep its password manager
| running?
| Borealid wrote:
| > NFC tokens have basically no security against a close range
| attacker. How much this matters depends on the threat model.
|
| No, the CTAP standard (what FIDO is using for communication
| with NFC tokens) provides pretty good resistance against this
| threat. There's actually a diffie-helman key exchange between
| the computer (platform) and authenticator (token). The only
| way it could really be better is if it did challenge-response
| for your PIN authentication, but as it is if you eavesdrop a
| CTAP NFC exchange you do not get the user's PIN, or the
| ability to generate/use a credential later.
|
| In order to attack a CTAP token over NFC you need to man-in-
| the-middle it.
| amluto wrote:
| In order to attack a CTAP token, I can tap it against an
| ordinary phone or a Proxmark or any PN532 device attached
| to a computer with some fairly straightforward software.
| There isn't any authentication! It could be ECDH or
| SnakeOil-102400-super unbreakable for all an attacker
| cares: the attacker can just speak the protocol as
| specified.
|
| edit: Okay, I found the pinToken mechanism in the spec. It
| is, to put it politely, not a PAKE. It has a trivial DoS
| attack by design allowing anyone nearby to destroy an
| authenticator. It looks vulnerable to an attack in which
| someone taps a malicious token against a phone or other
| reader, triggering the phone to try to authenticate, and
| thus captures the PIN, hashed but not even salted.
|
| Oh, and I've personally never been prompted to set a PIN,
| and the UX looks miserable.
| lxgr wrote:
| That's why you either use authenticators as a second
| factor only (i.e. you require a password entry first), or
| you require user verification (which is usually a PIN
| entry verified by the authenticator). Both solve this
| problem.
| Borealid wrote:
| Oh, one more thing!
|
| > There is no way to name a token to keep track of which one
| it is
|
| Tokens support listing which credentials are stored on them,
| and most (not 100%, but most) tokens also support storing an
| arbitrary blob of data at least 1024 bytes in size. You can
| name your token if you want to name your token.
| amluto wrote:
| This does _absolutely nothing_ to help me keep track of
| which physical gadget matches which token listed in the
| GitHub 2FA page without manually typing some kind of
| descriptor and hopefully getting it right.
| lxgr wrote:
| Github lets me name my passkeys. There's a little pencil
| icon next to each one (on [1]), and as far as I remember
| it even prompted me for a name when I originally created
| it.
|
| [1] https://github.com/settings/security
| amluto wrote:
| Indeed. But it's on me to manage it. There ought to be a
| way to tell my computer, once, the name of a token.
| lxgr wrote:
| There does seem to be some way. I'm relatively sure I've
| seen keys pre-labeled with the name of my password
| manager in the past.
|
| Some sites make bad assumptions, though, e.g. labeling
| every passkey I create as "iCloud Keychain" (because my
| user agent tells them I'm on macOS, and they assume that
| it must be that then).
| lolinder wrote:
| > passkeys were a great idea until cloud vendors waged war on
| hardware keys.
|
| > The concept of a passkey as desired by Yubico was that every
| user buys a set of hardware keys, uses those instead of
| passwords, and has no ability to authenticate otherwise.
|
| This was never a great idea, it was totally unworkable for
| nearly everyone. Physical keys work because locksmiths exist,
| keys can be copied, and users get to choose when they lock the
| door/box/whatever. And _even with those benefits_ they 're
| rapidly being replaced for a lot of people with PIN codes or
| mobile apps precisely because physical keys are suboptimal.
|
| Hardware keys as envisioned here cannot be copied without
| registering the copy separately with each and every service,
| have no equivalent of locksmiths besides "store these 10
| recovery codes somewhere safe" (also unworkable as a solution),
| and between session timeouts and multiple devices users are
| regularly unable to predict when and where they will need to
| create a new session.
|
| Hardware keys were designed for a spherical humanity, not for
| the humanity that has to deal with ADHD, dementia, babies,
| kids, fires, floods, and a host of other failure modes. OS keys
| inherit many but not all of the flaws of hardware keys, but at
| least they don't rely on a human being responsible!
| Borealid wrote:
| I think the passkeys would have remained a great idea if all
| passkeys were provided either by hardware devices not sold by
| cloud services vendors, or by software not written by OS
| vendors.
|
| I largely agree with your point, and I don't think most users
| should be using hardware tokens. But the TPM chip in the
| user's phone should be usable by any app on that phone, not
| just by the OS vendor.
|
| I stand by my original statement that the standard was fine
| until users started getting shoehorned into "use Google
| passkeys on your Android".
| lxgr wrote:
| > by software not written by OS vendors.
|
| In an ideal world, I'd prefer that to.
|
| In the practical one we're living in, this would mean that
| almost no website would implement them, because almost no
| user would be capable of using them.
|
| As much as I dislike the platform lock-in consequences,
| bootstrapping a two-sided network is incredibly hard and
| usually does not succeed without something aggressively
| pushed onto users (e.g. by preinstalling and preselecting
| it) to kickstart things. In the best case, this is then
| quickly replaced by user choice, and that's what has
| fortunately happened for passkeys.
|
| > the TPM chip in the user's phone should be usable by any
| app on that phone, not just by the OS vendor.
|
| Do you mean TPM as a generic term for a hardened secure
| element/enclave? Unfortunately, these are not standardized
| at this point (actual TPMs are, but these are a PC thing).
|
| And what would be the point? I could see secure
| enclaves/elements implementing CTAP2 instead of a
| proprietary interface, but I don't really see the benefits
| of that. The much more important thing would be that all
| applications on the OS can access that implementation
| through some API, and that would reasonably be the "FIDO
| backend" APIs both iOS and Android already provide.
| palata wrote:
| > And even with those benefits they're rapidly being replaced
| for a lot of people with PIN codes or mobile apps precisely
| because physical keys are suboptimal.
|
| I would be careful with the use of "suboptimal" here. PIN
| codes or mobile apps are possibly _more convenient_ to some
| people, not necessarily more secure (a PIN can leak, a
| smartphone can be hacked).
|
| I would argue that hardware keys _are optimal_ in the use-
| case they solve. It 's just that not everybody wants to solve
| this use-case. And that's okay: passkeys should allow users
| to choose.
| ihumanable wrote:
| Yea, the physical key is, to me at least, one of the top
| human inventions.
|
| Ubiquitous, cheap, convenient, and provides sufficient
| security. My little brass key never needs charging, never
| refuses to open the door because I didn't apply the latest
| over-the-air update, doesn't phone home to an advertising
| firm to track every time I open and close a door.
|
| I can make as many copies as I like and give them to
| friends and family in case I lose mine. There are some
| scenarios where it might be nice to have a smart lock, but
| for me at least, they are so few and far between that I'll
| stick with this tiny bit of metal.
| lolinder wrote:
| This is valid: use case matters. But almost no one has a
| use case for which hardware keys are optimal.
|
| If you live in an area where you don't have bars on your
| windows, you don't gain more security from using a physical
| key over a PIN or app. (Even if you do have bars, the
| physical key is likely still suboptimal).
|
| If you're a regular user of the kind of application where
| anyone ever thought passwords were a valid authentication
| solution, you don't benefit from a hardware key.
|
| And it's not just a question of more security than
| necessary: using a security mechanism that is overkill for
| your needs can actually leave you with _lower_ total
| security, because you 'll end up doing things to make your
| life more convenient that are worse than what you'd have
| done with a weaker mechanism (like in the physical case
| leaving the door unlocked to avoid locking yourself out).
| hansvm wrote:
| > 10 recovery codes
|
| Mostly unrelated, I fondly remember Google doing one of those
| "prove you're you" checks when I was in a different state,
| allowing me to waste one of my 10 recovery codes as one of
| the options, and still refusing to let me log back in till I
| got back on my home WiFi a few weeks later.
| WorldMaker wrote:
| > installing a password manager providing passkeys would prompt
| to change the setting to use the password manager instead
|
| iOS supports this today. If a password manager app describes
| that it implements passkey management, iOS asks what you want
| to be the default and the UI changes a bit to allow easier
| choices between iCloud and your password manager app.
|
| It sounds like macOS is the place where Apple is lagging the
| most on API hooks that applications can use to trigger the UX.
|
| It's also possible that Apple is just prioritizing that macOS
| users are mostly bought into the iCloud Keychain and their
| cloud infrastructure whereas iOS does have a large known
| mixture of iOS/Windows users that may bring their own
| keychains/password managers.
| kenada wrote:
| macOS also supports the APIs, but password manager developers
| don't seem willing to implement them there.
|
| I've used 1Password for a long time, but I'm probably going
| to drop it for Apple's password manager because when users
| ask 1Password to add support, they are directed to use
| 1Password's browser extension and universal autofill instead.
| Neither support passkeys in applications. I also find the
| browser extension buggy at times (especially with passkeys).
| frereubu wrote:
| TOTP suffers from a similar issue - I use 1Password to store my
| TOTP codes, but both Google and the UK's HMRC tax website talk
| about using their own apps for codes rather than anything agreed
| like "one-time passwords". The digital world is rife with this
| kind of jockeying for position through language. It took me far
| too long to understand that "podcasts" are just mp3 files from an
| RSS feed.
|
| Likewise, in the heyday of interactive TV in the early 2000s,
| when it was going to conquer the world because everyone had a TV
| but not a computer, an agency I worked for were invited for a
| demonstration of a choose-your-own-adventure game they were
| developing. They kept referencing a "carousel system" where all
| pages were sent in a looping system and when someone made a
| choice it waited until that page came round in the "carousel". I
| kept asking whether that was like Teletext -
| https://en.wikipedia.org/wiki/Teletext - but they absolutely
| refused to say that and kept saying "well, it's a carousel
| system".
|
| This refusal to deal in everyday language, alongside trying to
| get people to use their own apps / sytems, really hinders the
| adoption of useful technologies.
| ffsm8 wrote:
| That's not what podcasts are at all?
|
| Most of the popular ones are primarily viewed with video
| even...
|
| A more realistic description would be "a mostly unedited
| dialogue between people, usually published in a series"
| xethos wrote:
| I'm not going to dictate MP3, but yes: podcasts absolutely
| are an audio file pulled from an RSS feed. Your description
| covers some podcasts, but not every podcast has video (which
| should be entirely optional if it's there at all, and frankly
| makes it less of a podcast in my opinion), and many go
| through some pretty heavy editing, even if just to balance
| audio levels, prune dead conversational branches, and remove
| filler words or dead air.
| Izkata wrote:
| Part of it is right there in the name: "pod" came from
| iPod. The device that was audio-only.
| hoherd wrote:
| https://providersupport.spotify.com/article/podcast-
| delivery... shows literally every data element as
| "RSS/something"
|
| https://en.wikipedia.org/wiki/Podcast says "Podcasting is the
| preparation and distribution of audio or video files using
| RSS feeds to the devices of subscribed users."
| ffsm8 wrote:
| TIL that the average HN reader believes that podcast is a
| Spotify trademark and their technological implementation is
| it's definition.
|
| Guess what the biggest or at least most notorious podcast
| is?
|
| The joe Rogan experience.
|
| Guess what it's primary distribution was, way before
| Spotify paid him millions to come to their platform?
|
| Yes, Video.
|
| And literally the first paragraph of your Wikipedia link
| proves my point. Your reading comprehension really seems to
| be horrendous.
|
| I hope y'all already drunk, as the alternative is really
| disheartening
| bananagoat wrote:
| Spotify does not have a trademark on rss podcast
| delivery. RSS feeds have historically been the primary
| delivery method for podcasts and it long predates Spotify
| and the JRE. Many of the most popular or historically
| significant primarily used RSS: Serial, This American
| Life, Stuff You Should Know--the list goes on and on.
| Some podcasts are distributed via video, but even many of
| those also have a corresponding rss feed for the audio
| version.
|
| Here's the rss feed for Joe Rogan
| https://feeds.megaphone.fm/GLT1412515089
|
| If you use a podcast app today, it is guaranteed to be
| primarily fetching from RSS feeds.
|
| I'm pretty sure the kind of insulting rhetoric you're
| using is against the rules here. You may prefer Reddit
| for starting those kinds of arguments.
| ffsm8 wrote:
| I didn't claim it had a trademark, but if you literally
| skipped entirely over the comment I was responding to:
| _he quoted the Spotify docs for their podcast APIs as an
| argument why podcasts are RSS /MP3_
|
| And his second link literally confirmed how entirely
| wrong his own claim was, within literally the first
| paragraph. Which you seem to have skipped over too....
|
| So where does that leave us? With now two very confused
| commentors that seem to be unable to read, hence my
| previous quip about reading comprehension
| eudidjhdjf wrote:
| >That is definitively what they were when the term
| "podcast" was new and I was trying to figure it out
|
| Reading comprehension. Or are we just starting the clock
| from when the Joe Rogan podcast began?
|
| >And literally the first paragraph of your Wikipedia link
| proves my point. Your reading comprehension really seems
| to be horrendous<
|
| Are you ESL or something? Because the Wikipedia link is
| referring to the modern context in that paragraph.
|
| Here, we can overcome the way society failed you
| together.
|
| >The first edition was published on August 13, 2004, as a
| live show that software developers could use as a test
| for their download software. Podcasting technically
| already existed at that time, but Adam was the first to
| bring together RSS, scripting, and actual audio content<
|
| You're disabled so maybe you were confused when you read
|
| >In October 2000, the concept of attaching sound and
| video files in RSS feeds was proposed in a draft by
| Tristan Louis.[18] The idea was implemented by Dave
| Winer, a software developer and an author of the RSS
| format.[19]<
|
| But the key word in this sentence is "proposed", as in
| speaking to what was possible but not what had been done
| yet. I'd add a flashcard of that one to my vocab deck
| since it seems like one of the harder ones for you.
|
| So yes, early podcasts were audio and RSS and Joe Rogan
| wasn't around yet.
| ffsm8 wrote:
| In case your genius mind wasn't able to comprehend this
| amazing concept: the technical implementation of most
| podcasts in 2000s does not define the concept of a
| podcast.
|
| Yes, once upon a time, that was the most common way
| podcasts were distributed. It however wasn't the
| definition of the word "podcast".
|
| Did you get that, or was that once again too complicated
| for you?
| frereubu wrote:
| That is definitively what they were when the term "podcast"
| was new and I was trying to figure it out - and in any case
| this seems like rather pointless hairsplitting.
| jazzyjackson wrote:
| - distributed as mp3 files via RSS protocol
| nashashmi wrote:
| Not sure what you are talking about TOTP suffering from a
| similar issue.
|
| TOTP works via a secret key provided by the service. The
| TOTP(secret key + time) function generates a 6 digit code. This
| is a standard. The secret key can be stored on Authenticators
| and those authenticators sync to cloud services.
|
| When adding the secret key for the first time to your
| authenticator, you have to also copy that to a notepad. This
| way if you want to transfer the keys, you have them available.
| Authenticator apps don't always allow you to export the keys.
| TOTP.app is a good auth app that does allow but there is no
| sync to cloud capability.
| samcat116 wrote:
| I seem to be in the minority of HN users that love passkeys. I
| use them for any login that I reasonably can. When creating a
| passkey I create one in iCloud Keychain as well as in 1Password.
| I do agree that there needs to be a better import/export story,
| but I have confidence that will come.
| aednichols wrote:
| Same. It is annoying to dodge the prompts that guide me to save
| in Chrome or iCloud instead of 1Password, but with patience I
| have always succeeded. Of course, I know what I want and when
| to ignore what the machine suggests, which I wouldn't expect of
| non-enthusiasts.
| SXX wrote:
| I would even get idea to make passkeys non-exportable, but lack
| of import feature for me as power user just kills passkeys for
| me.
| jeroenhd wrote:
| Same here. My passkeys are in Bitwarden and they're more
| complex and secure than any password websites will let me
| enter.
|
| I don't trust cloud providers like Google and Apple to keep my
| secrets for me, but with Bitwarden I can just dump the secrets
| and load them from a backup if I wish to do so.
|
| I've also been pleasantly surprised at how well logging in
| through CTAP2 works. Any laptop/desktop PC with Bluetooth can
| use the Bitwarden vault on my phone (after unlocking it with a
| password, of course) to log in with very little hassle. Much
| better than copying over passwords, or opening the password
| vault on every PC I need to log in to something.
| fredfoo wrote:
| I think the elephant in the room is the total lack of
| website/framework/library support Fido has. Trying to implement
| support on any random site is about as insane as rolling your own
| crypto and having the single sign on bolt on is sort of how
| people selling FOSS+enterprise want it.
|
| The end result is that it was more a standard for them more than
| for direct use by the little sites, and password managers getting
| involved only furthers that enterprise industry standard feel.
| WorldMaker wrote:
| Yeah, it has been frustrating me lately that there isn't a
| _simple_ drop-in Passkeys-only library /framework yet. Right
| now the best advice is "use Auth0/Okta or competitor and
| configure them in Passkey-only" which adds a vendor where you
| shouldn't need a vendor.
|
| The other day I just wanted to store passkeys in Deno KV
| without feeling like I was rolling my own crypto library. I did
| not succeed in the limited amount of free time I had on that
| personal project, and that seemed a shame and a half.
| shim__ wrote:
| It's rather simple actually: https://developer.mozilla.org/en-
| US/docs/Web/API/Web_Authent..., no crypto involved
| palata wrote:
| Unfortunately, that's probably way too technical for most
| developers nowadays, who are almost proud of not being able
| to read a manual.
| notatoad wrote:
| on the client side, it seems like it should be simple. in the
| time i allowed myself, i was not able to figure out how to
| integrate it server-side in my python app. you're not
| implementing your own crypto, but you are having to interact
| with and understnad crypto.
|
| there doesn't seem to be a standard python implementation,
| and there's no feedback at all about what went wrong if your
| challenges/responses are not accepted by the client-side
| APIs. the error if your server-side implementation sends
| anything unexpected is essentially "no, that's wrong".
| jeroenhd wrote:
| This doesn't look all that hard:
| https://github.com/mkalioby/django-passkeys but I guess it
| depends on how low-level your backend is.
|
| I would personally separate auth and the application.
| Configuring something like Keycloak or Authelia or one of
| the many other alternatives to do all the difficult work
| for you and just logging in through SSO/SAML seems much
| easier than having to keep track of your own authentication
| rules/security hashes/salting/etc. without making a
| mistake.
| fredfoo wrote:
| Yeah right, its easy to write a PAM module too, but
| configuring an authentication registration and flow is not
| actually a similar skill set.
| cchance wrote:
| Why is it defaulting to passkey if i want to use a security
| key... probably because 99% of people will be using the builting
| apple passkey and not a third party hardware device that few
| have... hence why the hardware device is considered "other"
| mixmastamyk wrote:
| It's not merely a default, but a desire to punish outliers to
| conform.
| shreddit wrote:
| As an Apple ecosystem user i really like passkeys. I don't have
| to remember passwords and once i set up a passkey on a device
| it's synced to all my other devices. It's just really convenient.
| EPWN3D wrote:
| This piece reads very nitpicky, and I just don't identify with
| what it's saying. My use of passkeys in Safari on Apple platforms
| has been basically seamless.
|
| I guess if you use tons of different browsers on tons of
| different platforms and want to work in hardware tokens, it's a
| pain, but most people aren't doing that.
|
| The problems highlighted are real, but they don't rise to the
| level of "Passkeys aren't usable security". For users that would
| have otherwise not opted into 2FA at all (or don't know how to
| set up TOTP), passkeys are fine. I'm sure there are some warts to
| iron out, but they have to be evaluated within the context of the
| practical alternatives, not the context of the author's own
| personal security priorities.
| wyattblue wrote:
| I think you're downplaying real concerns people have. Having
| two different devices is not an exotic scenario
| jbverschoor wrote:
| It's invisible. A black box, non transferable. There's no mental
| model that maps and you can't back it up as a normal person.
| Implementations are half baked and still require all the rest,
| all the attack surface is even larger.
|
| Was super excited, totally not anymore.
| NelsonMinar wrote:
| I think passkeys are a failed product. Time to give up and start
| over again.
|
| I don't say this casually. I have been arguing for ending
| passwords for nearly 20 years now. I'm a software engineer and
| broadly understand a lot of security protocols. I spent hours
| understanding passkeys and figuring out how to use them in my
| environment. The core idea is great! But the usability is
| garbage.
|
| I still can't use passkeys reliably. The combination of bad
| implementations in Windows, Chrome, 1Password, and various
| websites has defeated me. All passkeys do now is clutter up the
| one login flow that works for me (1Password form filling, as
| awful as that is.)
| lxgr wrote:
| > All passkeys do now is clutter up the one login flow that
| works for me
|
| You can always disable that in the settings with one click.
|
| > I still can't use passkeys reliably. The combination of bad
| implementations in Windows, Chrome, 1Password, and various
| websites has defeated me.
|
| I can't speak for how bad things are on Windows, but my flow on
| macOS (Firefox) and iOS (Safari) is the following:
|
| - Try to set up a passkey at a site offering them.
|
| - Log out and attempt to log back in using the passkey. If it
| works (and it does for 80-90% of all sites), great, use it in
| the future!
|
| - If it doesn't work, delete the passkey, make a mental (or
| actual, in the password manager) note that the site has a
| broken implementation or very bad user experience, for future
| shaming in threads such as this. (Hi, Amazon and Paypal!)
|
| Obviously that's not viable for non-technical users, but it
| does save me a lot of time in the long run, since every
| subsequent login is so much faster than using whatever second
| factor sites are requiring me to provide otherwise.
| Groxx wrote:
| > _Log out and attempt to log back in using the passkey. If
| it works (and it does for 80-90% of all sites)_
|
| ... and right there is a big part of the reason I distrust
| the current passkey implementations. That 's an _absurdly_
| low success rate, and I see similar numbers echoed by many
| people who use them, regardless of the site 's importance to
| their life or apparent technical ability. (my own dabbling
| has an even worse success rate, though I've somehow managed
| to dodge multiple complete-passkey-data-loss issues in
| clients)
|
| And for some reason it doesn't seem to be getting much more
| consistently working either.
| thefreeman wrote:
| As a technical user who understands how these work and has none
| of the confusion issues the author describes, my biggest problem
| and the reason I stopped using them for google is they seem to
| arbitrarily set the session length for passkey authenticated
| sessions much lower. I found myself needing to reauthenticate
| with google every day or 2 when signing in via pass key. I assume
| the developers thought this would be seamless, but it is a very
| annoying interruption to workflow. Especially since I use
| 1password as the backend with my laptop screen closed it results
| in me needing to type my (long and complicated) password manager
| password every time and usually when I am trying to access
| something timely like a meeting invitation.
| wnevets wrote:
| Forcing a new key pair for every single website was a mistake. If
| the crypto is secure than a single key pair should be suffice.
| That is how we use public key crypto almost every other use case
| and we get to avoid vendor lock in completely.
| whartung wrote:
| Maybe someone can explain it better to me.
|
| It seems that the primary goal for passkeys is to eliminate
| password fishing.
|
| You still need a password for the site. Even with passkeys, you
| can still login with a password, either from a different machine,
| or, if nothing else, to recreate your passkey.
|
| But passkeys offer a bit more security to enforce that you're
| actually sharing the credential with the proper site, correct?
|
| Am I missing something?
|
| I mean, there's the whole syncing passkeys across stuff, but
| that's all optional. There's no requirement for that. You should
| be able to configure multiple passkeys to the same site across
| your various machines (for whatever reason), right?
|
| And I assume the sites won't "auto login"? Even with a passkey
| you would need to (potentially) hit a login button or something.
|
| I just want to make sure I understand it clearly.
| amelius wrote:
| After reading 1/2 of the article, I still have no idea what a
| passkey is.
| mixmastamyk wrote:
| My understanding: It's like a yubikey (a device that lets you
| login securely) but using a similar protocol without the
| hardware. "Virtualized" in other words. Unfortunately
| susceptible to poor self-serving implementation UI by greedy
| vendors.
| alfiopuglisi wrote:
| In my limited understanding, they are similar to SSH
| public/private key pairs. But the details continue to elude me,
| no matter how much I read about them. Won't try them out until
| I get how they work.
| lll-o-lll wrote:
| It's that, except the OS manages the private key (in a
| "secure enclave"). So you, the user, (or malware), never get
| access to the private key.
|
| The second crucial part is that these private keys are cloud
| synced. This means that the average Joe doesn't lose their
| passkeys when they lose their phone. Get a new phone, and it
| will sync your passkeys and you are back. For people in the
| Apple ecosystem, it really is a straight upgrade over
| passwords.
|
| Where it sucks:
|
| - I'm not comfortable trusting a big vendor with the keys to
| my digital life
|
| - I only have one device, so when I lose that device I'm
| locked out till I get another
|
| - I want to use my own password manager to handle passkeys
|
| - I am in multiple big vendor ecosystems
|
| - I want to export these private keys (this one is sort of
| coming, the standard has been defined to allow export and
| import, but again in such a way that the user (or malware)
| cannot access these private keys)
| samgranieri wrote:
| I'd like to just keep using security keys, thank you very much.
| They are much simpler and easier to understand and explain.
| ilaksh wrote:
| I like the idea of using a password manager, but I think we
| should be aware that can create a single point of failure. For
| example, the LastPass breaches.
| NelsonMinar wrote:
| This article links to a bunch of pages at FIDO Alliance, the
| official passkey info source, pages like
| https://fidoalliance.org/fido2/
|
| FIDO Alliance's website is pure garbage.
|
| On first load all the content is covered by a demand you "sign up
| for updates!", a modal blocking the rest of the page. Also
| there's a surveillance consent popup that opts you in to
| tracking.
|
| It takes 9.9MB to load this content-free page. Closing the
| distractions so you can read the content loads another 3MB.
|
| Why would I trust this alliance for anything to do with website
| creation?
| jmakov wrote:
| How is this different than just using your SSH key?
| mixmastamyk wrote:
| One difference is that it is hardcoded to the destination site.
| vinay_ys wrote:
| The most common lock and key ergonomics that everyone is familiar
| with is the following:
|
| 1. You have a lock, you have a corresponding physical key. You
| can have more identical physical keys. All of them will unlock
| the lock. If you lose the physical key, you can call the
| locksmith to change the lock. Physical key is anonymous. Only you
| know which key unlocks which lock. If a random person finds your
| physical key on the street, they shouldn't be able to find their
| way to your lock to try and unlock it.
|
| 2. That's all well and good. Now, comes a magic key. That's your
| personal magic key. Any lock you are permitted to unlock, your
| magic key can unlock it. Any key you are not permitted to unlock,
| your magic key cannot unlock. Now, you can more than one magic
| key - where only some of the locks you are allowed to unlock can
| be unlocked by one magic key vs another. And if you happen to
| lose your magic key, you can call your locksmith to cancel your
| magic key - actually, that's a keysmith than a locksmith!
|
| 3. Your magic key is still anonymous. Only you know which magic
| key can open which locks. A random person who finds your magic
| key shouldn't be able to find their way to all the locks it can
| unlock.
|
| 4. When you see a lock, you are prompted to insert a key. The
| prompt doesn't say which key. You try one of the magic keys have
| that you think should unlock it. If it happens to the wrong key,
| not a big deal. You just try another magic key you have, and if
| that's the correct key it will unlock it.
|
| 5. When you buy a new lock (sign-up), you decide which magic key
| you have that should be the one to unlock it. This pairing of the
| key to the lock is done simply by asking pair a key to the lock.
| You are not being told to use a specific vendor of magic keys.
| You are not being peddled only magic key vendor over another!
|
| 6. If you want to change the magic key paired to a lock, you can
| do so at anytime on your own as long as you are in possession of
| the current magic key.
|
| 7. And of course, you can have multiple magic keys paired to the
| lock, so that you can unlock with any of the keys.
|
| 8. When you use a key to unlock a lock, the lock can tell which
| paired key was used - you can give nicknames to the paired keys
| that the lock remembers. The lock will tell you which nicknamed
| keys were used to unlock it previously and when.
|
| -----
|
| Here's where I think passkeys went awry. They became yet another
| platform war. The OSes and browsers are supposed to be neutral
| and provide an unobtrusive prompt for user to pair a key or use a
| key, that's it. And the user should invoke a keyring against that
| prompt. If the keyring provider has features - like portability
| or non-portability of keys etc that's unique to each key ring
| provider and as long as the user is comfortable with it, everyone
| should be good with it. The prompt needs to be unassuming. Today
| it is very assuming and that's the problem!
| tasuki wrote:
| > chosen to sync the passkey using my 1Password password manager.
| In theory, that choice allows me to automatically use this
| passkey anywhere I have access to my 1Password account
|
| I have never used passkeys and don't know much about them, but
| isn't the main point that they're distinct per device?
|
| If one syncs pass keys using a password manager, what benefit do
| they bring over passwords?
| Groxx wrote:
| The main benefit: if used to _replace_ passwords, they
| eliminate bad passwords and password reuse and password leaks
| by things you log into. Which is a _gigantic_ improvement in
| practice, as those are extremely common ways for mass account
| theft.
|
| (I am not personally a fan of passkeys for a variety of
| reasons, but the main goal is very pragmatic and _something
| like_ passkeys is a very obvious choice. I just don 't like
| this spec, the UX awfulness and railroad-everyone-into-giga-
| corp-systems-and-giving-up-all-control shown in this article is
| a direct and very predictable result of the spec's decisions.)
|
| ---
|
| Per-device is an option (part of the spec, and I believe always
| allowed), but it has a bootstrapping problem that leads to
| custom out-of-spec shenanigans (how do you attach your account
| to a second device, without any other way to log in, if the new
| device has nothing that can prove it's related to the other?)
| and most people don't have enough devices to be able to have
| guaranteed backups. Lose your phone and you might lose
| literally everything. Or a house fire. Data is FAR easier and
| cheaper to put in multiple locations for redundancy.
|
| Also I set up new devices like a dozen times a year, whether
| it's a new physical device (relatively rare) or simply an erase
| and start over / OS switch (at least annually , it ensures my
| backups work and I get rid of cruft). If my passwords weren't
| backed up and handled with far more paranoia than my _browser
| session_ , I've have lost them at least a couple times.
| Arnavion wrote:
| They don't bring any user-visible benefit over passwords if you
| use a password manager for your password (so that the password
| is stored securely on disk behind the password manager's login)
| *and* the password is unique and large (eg randomly-generated
| by the password manager) *and* you have the password manager
| autofill it instead of copy-pasting it manually (because the
| password manager can reliably check the domain name without
| falling for lookalikes, homoglyphs, etc).
|
| From a UX perspective, passkeys eliminate user choice about the
| above matters, so it's easier to railroad users into secure-by-
| default.
|
| From a technical perspective, a shared secret like a password
| is generally worse than an asymmetric key like a passkey,
| especially since stupid websites can save the password directly
| instead of using a KDF in the usual way and then get breached,
| but if the secret is unique that matters less.
| sunshowers wrote:
| It is possible to use distinct passkeys per device, but that's
| a crappy user experience, similar to having a distinct SSH
| private key per device (which is also often recommended by
| naive technologists). You generally want to lean towards
| turning M * N problems into M + N problems.
| gwbas1c wrote:
| The best way to solve a big problem is to break it up into lots
| of tiny problems.
|
| It seems like, IMO, the best way to get the general public to
| adopt passkeys, and to refine (cough debug cough) the UI, is to
| use them in low-stakes situations, in a gradual rollout.
|
| Instead of focusing on high-stakes use cases, like banking,
| perhaps:
|
| 1: Focus on low-stakes situations, like blogs and news sites
|
| 2: Services need easy ways to "add a device," such as opening a
| link in an email or SMS on the device they want to use.
|
| 3: Don't bother syncing passkeys across "devices." Instead, focus
| on syncing within the browser, where passkeys sync however
| bookmarks sync.
|
| 4: Work on APIs for a user to _elect_ to use a 3rd party passkey
| manager
|
| At that point, services like iCloud, OneDrive, Google Drive, ect,
| could also provide passkey synchronization. It's up to elect to
| use such services; because otherwise, re-signing-in on each
| device the user uses might be "good enough."
| tonymet wrote:
| Every additional factor just weakens the chain. None of these
| solutions addresses the social attacks due to decreased
| usability. Users are more confused and have less control now.
| They will spam every factor to get to their resources.
| notatoad wrote:
| regular people strongly disagree. from what i can tell, people
| who aren't HN commentators or tech bloggers _love_ passkeys.
|
| you click "sign in" and you are signed in. that's the dream. my
| non-technical family and friends have been lamenting not being
| able to do that for years. my customers are asking for it.
| hbn wrote:
| Give it a few more years to marinate, and people start getting
| new devices. Then we'll see how good this actually works.
| gavinhoward wrote:
| And that will quickly reverse once people start losing their
| accounts by losing passkeys or devices.
|
| My extended family fought me about migrating to Signal for
| years. I stopped trying. One or two years later, they were all
| on it, acting as if they hadn't given me grief for it.
|
| They have learned their lesson, though. A couple of them have
| come to me asking about passkeys, and I tell them the threat of
| losing access and let them make their decision. I think both of
| them chose to keep passwords.
| Groxx wrote:
| Every person I've talked to in person who has used passkeys
| has lost all their passkeys at least once, by no fault of
| their own.
|
| The more techno-masochistic ones tried again immediately out
| of curiosity (hence "at least"), but the rest have sworn off
| passkeys permanently.
|
| And I don't blame them. Without cross-platform sync being
| standard and literally everywhere, it's trusting _hardware
| and OS vendors_ to do a good job and inter-operate correctly
| for the long-term future. They 've all used computers for
| long enough to know that's not something you can trust them
| with, particularly not in low-margin devices like most people
| use.
| notatoad wrote:
| i think you're overestimating how good people are about
| maintaing their passwords. if you tell people "you'll lose
| your passkey and have to reset it" they'll freak out. but
| most people lose their passwords and get locked out of their
| account on a somewhat regular basis anyways. people suck at
| passwords.
|
| if they can have that level of reliability with a bit more
| everyday convenience, they'll be happy.
| benced wrote:
| I'm really not convinced by passkeys as a socio-technical
| phenomenon because it seems to lock people to their OS. As a
| technical user, having them in 1Password which is OS-neutral (and
| plans to support export eventually - I'll change my mind on
| passkeys if this never comes), they're great.
| rawgabbit wrote:
| I guess I am a bit dense when I create Apple passkeys for the few
| websites that support it, I don't have any issues with using
| chrome or safari and macOS or windows? I will test again but I
| don't remember experiencing this.
| lll-o-lll wrote:
| I think there is a big difference in experiences for people who
| are in the Apple ecosystem and people who aren't. Apple has
| made the whole show seamless, so you move from device to device
| and everything just works, your passkeys are there. At worst,
| you use your phone to do the login.
|
| It's also seamless if you lose a device. Your new device has
| your passkeys, and you can get by with an iPad or older phone
| until replaced. I think the space where people have all the
| pain is outside of this ecosystem. Apple is showing it _can_ be
| done well, but it's clearly not the experience people are
| having outside of that walled garden.
| cratermoon wrote:
| "Most try to funnel you into a vendor's sync passkey option"
|
| Therein lies the problem. Every vendor's profit motive and
| #enshittification means they want to own your passkey and all the
| personal data associated with it. None of the care to interop or
| work with decentralized solutions. They need your data, and
| they'll do everything they can to lock you into their jail.
| high_5 wrote:
| Passkeys deployment reminds me of a cartel agreement among FAANG
| without the actual coordination. It's too good of a new tech
| frontier not to colonize.
| dp-hackernews wrote:
| Why not use something similar to SQRL instead?
|
| https://en.m.wikipedia.org/wiki/SQRL
| paultopia wrote:
| This matches my experience perfectly. As someone who is
| technically skilled but has no particular security expertise,
| I've tried to gradually implement passkeys where available across
| the most important and frequently used of my accounts, and... I'd
| have to go read the goddamn spec to have any idea what's going
| on. Pretty much all I've learned is that sometimes I can use
| touch ID to log into stuff now, and sometimes I can't, and the
| reasons are totally damn opaque.
| greatgib wrote:
| The magic of password is that you can write them to paper or keep
| them in your mind. No interoperability issue if suddenly having
| to use it temporarily or permanently with another device, like if
| you lose your phone. And you can also pretend they don't exist
| and no one can prove otherwise. Also if you don't use a password
| manager, no one (hacker or else) can extract it from your head
| like it can be forced from your devices.
| jeroenhd wrote:
| That password is Hello123! for most people and that's why
| people get "hacked". Great that you're one of the dozen or so
| people who can keep hundreds of passwords in your memory palace
| for several decades, but that's not feasible for us mortals.
|
| Good passwords are hard because password booklets get lost, or
| aren't nearby when accounts are created, and people are
| terrible at remembering hundreds of passwords. Or even ten
| passwords, as I've found out working helpdesk.
|
| If everyone used passwords safely, we wouldn't need 2FA on all
| that many services. Unfortunately, credential stuffing remains
| super effective.
|
| I'm not saying passkeys are the perfect solution here, but
| pretending passwords are fine as-is is just burying your head
| into the sand.
___________________________________________________________________
(page generated 2024-12-30 23:01 UTC)