[HN Gopher] Bitwarden developer survey: Secrets, security and th...
___________________________________________________________________
Bitwarden developer survey: Secrets, security and the future of
passkeys
Author : CharlesW
Score : 43 points
Date : 2023-10-22 19:14 UTC (13 hours ago)
(HTM) web link (bitwarden.com)
(TXT) w3m dump (bitwarden.com)
| latchkey wrote:
| Still waiting for passkey support. Looking through github, it
| feels like it is still pretty far off.
| hedora wrote:
| It's strange that they say most developers favor passkeys.
|
| They certainly didn't ask the HN crowd. I wonder who they
| surveyed.
|
| Are they conflating fido2 hardware tokens with "google owns your
| credentials, and you can't back them up" passkeys?
| rat9988 wrote:
| "They certainly didn't ask the HN crowd. I wonder who they
| surveyed." You probably didn't survey the HN crowd either.
| hedora wrote:
| I did not, but sentiment about passkeys is overwhelmingly
| negative in the comments sections of previous articles.
|
| Here's the "most popular" article according to a HN search
| for passkeys:
|
| https://news.ycombinator.com/item?id=36712497
| m-p-3 wrote:
| Personally I hope to see Passkeys becoming more prevalent.
| pomstazlesa wrote:
| Personally, don't
| OJFord wrote:
| I'd like a better baked version to be more prevalent..
| right now it seems a bit 'how can we standardise a way
| for everyone to have a walled garden'.
|
| I want bitwarden, or whatever password manager, to be the
| (cross-platform) provider, not the OS. It's coming,
| maybe/hopefully?
| cassianoleal wrote:
| 1Password already has it. I'm sure others will implement
| it soon enough as well.
| OJFord wrote:
| Sure, but the man on the Clapham omnibus is going to use
| Apple's, or whatever's, that's what I don't like - it
| seems set up to serve incumbents rather than to stand on
| technical merit.
|
| There's precedent for only supporting certain walled
| gardens, too: Google MFA sign-in supports Yubikeys et al.
| only if used in Chrome; in Firefox for example you get
| the prompt and everything, it just stubbornly refuses to
| accept it on touch.
| cassianoleal wrote:
| > but the man on the Clapham omnibus is going to use
| Apple's, or whatever's, that's what I don't like
|
| You don't like that people will use the tool that's most
| convenient to them? I'm not sure I understand your
| argument.
|
| Right now pretty much all people except us geeks either:
|
| - Re-use the same password everywhere; or
|
| - Use their OS's password manager; or
|
| - Use their browser's password manager.
|
| How is this any worse?
| m-p-3 wrote:
| Most if not all services which I use that supports
| Passkeys allows you to enroll more than one per account.
| I have my phone (Android), my laptop (Windows Hello)
| andnmy primary and backup Yubikeys enrolled. I'm not
| restricted to a specific platform.
| kiwijamo wrote:
| Which platforms allows you to enroll your yubikey as as a
| passkey? I know Google for example does not support
| hardware keys within their Passkeys system and that's a
| major gap IMHO.
| m-p-3 wrote:
| Uh.. I enrolled my Yubikeys as Passkeys without any
| problems with Google.. just be sure Windows Hello doesn't
| get in the way, and be sure to select your USB device
| when enrolling.
|
| https://files.catbox.moe/eowjba.png
|
| I also have my Microsoft account enrolled as a Passkey,
| and Bitwarden is enrolled using WebAuthn.
| danShumway wrote:
| > Most if not all
|
| That this is not a required part of the spec and that
| it's possible for a website to go through certification
| and get an official endorsement of support without
| supporting multiple keys per-account is a complete
| failure of the FIDO Alliance.
|
| One of the big issues with how passkeys are being
| developed is the painful naivety of the FIDO Alliance
| about actually standardizing good behavior.
|
| Every response is, "but why would providers do X bad
| thing?" If we're expecting every provider to allow
| multiple keys, then _require it in the spec_. Otherwise,
| if it 's important that the spec not mandate that, then
| don't tell me that every provider is going to allow
| multiple keys, because apparently there's use-case for
| only allowing a single key and we're expecting the spec
| to need to accommodate that behavior.
|
| ----
|
| > I have my phone (Android), my laptop (Windows Hello)
| andnmy primary and backup Yubikeys enrolled. I'm not
| restricted to a specific platform.
|
| That people are seriously suggesting this as a solution
| to cross-ecosystem recovery and backup makes me skeptical
| of the potential of passkeys to ever be simpler or more
| straightforward than passwords are. Normal users can't be
| taught not to reuse passwords, they can't be taught to do
| 2FA, and you think they're going to proactively enroll
| multiple keys in every website they sign up to?
|
| That's not going to happen; what will happen is they're
| going to lose their Android phone and they won't be able
| to do cross-device authentication without it, and they
| won't have proactively done cross-device authentication
| on their Windows machine, and the only way to get access
| to those keys will be to buy another Android phone.
| "Register multiple devices ahead of time" is only a
| solution if you expect passkey usage to be restricted to
| niche technical groups.
| nl wrote:
| This article isn't even negative! It's pointing out that
| passkeys could make most security keys obsolete because
| they lack the storage to store resident passkeys for lots
| of sites.
|
| It even provides recommendations to work around this
| problem.
| nl wrote:
| I think the negative sentiment towards passkeys I've seen on HN
| is about how bad the experience has been setting them up. If
| you are using a non-standard browser there were plenty of parts
| of the process that fell over.
|
| > Are they conflating fido2 hardware tokens with "google owns
| your credentials, and you can't back them up" passkeys?
|
| Not sure why you say this, but perhaps you are conflating
| device-bound credentials (which aren't supposed to be moved
| between devices):
| https://passkeys.dev/docs/reference/terms/#device-bound-pass...
| kiwijamo wrote:
| I personally am wary over passkey. An Android update to my S21
| earlier this year dropped support for hardware keys. Now
| whenever I try to sign into a site that expects my hardware key
| the Google passkey dialog pops up and I have no way to use my
| hardware key to sign in. I wouldn't mind passkeys if Android
| continues to support the hardware keys alongside passkey but to
| replace the former with the latter is a step too far for me. I
| do wonder what the motivation behind passkey is if they're
| willing to drop support for hardware keys without any
| notification and push passkey instead.
| SushiHippie wrote:
| In their survey question they mentioned "fido2 and passkeys",
| so it's not clear how many are pro passkeys and how many had
| yubikeys in their mind. And the question isn't asked directly.
| They ask if passwords are here to stay and the answer options
| aren't about what the surveyed person would like to see in the
| future but more about what will happen in the future. e.g.
| "they [passkeys and fido2] will replace passwords" instead of
| "i want them [passkeys and fido2] to replace passwords"
| acdha wrote:
| > Are they conflating fido2 hardware tokens with "google owns
| your credentials, and you can't back them up" passkeys?
|
| Passkeys are an open standard, not a Google SSO service. You
| can use it with Apple devices (where passkeys shipped well
| before they did on Google devices), 1Password, etc. without
| having a Google account at all.
|
| The concern around backups is partially true (backups are
| possible, exchange between implementations is in progress) and
| I think that's where the confusion is coming from: the whole
| point of passkeys is that your private key can't easily be
| stolen and the first implementations did that only within
| specific services with known characteristics - for example,
| Apple's iCloud Keychain robustly backs up the keys (even
| against complete loss of all devices) but only in that service,
| which is understandable given their audience and the exposure.
| All of the major vendors have committed to interoperable
| private key exchange as things mature and we're already seeing
| that with e.g. 1Password and iCloud Keychain allowing you to
| share keys with other people.
| danShumway wrote:
| > Passkeys are an open standard, not a Google SSO service
|
| This ignores the practical reality of every single
| implementation of Passkeys today. The fact is, call them Open
| all you want, the implementations are almost entirely
| proprietary. The official dev site says they don't work on
| Linux (https://passkeys.dev/device-support/) and in fact
| doesn't even list Linux as a target (only Ubuntu), and
| doesn't even list _plans_ to support providers on Linux.
| Numerous people have said that exchange between
| implementations is in progress, but there 's basically zero
| information about it (the spec process and design of exchange
| seems to be happening behind closed doors as far as I can
| tell, or at the very least I don't know where to search to
| find the meeting notes), and there's no timeline at all about
| when it will be supported, and in the meantime no major
| passkey provider from any ecosystem supports transfer.
|
| But that hasn't stopped any of the major providers from
| launching passkeys to the general public and advocating that
| people start using them today.
|
| So forgive me for being doubtful that the industry actually
| cares, because they clearly didn't care enough about this
| stuff for it to be a blocker in front of asking people today
| to commit to ecosystems that have zero transfer systems in
| place if anyone needs them. Vendor lock-in is not a
| theoretical future concern; every passkey system being
| advertised to users today is currently vendor lock-in. We are
| past the point of lock-in being a future concern, _today_
| passkeys as they are presented to most users are almost
| entirely walled gardens and the only silver lining is that we
| have vague promises that the existing problems that make
| passkeys user-hostile right now might be fixed in the future.
|
| But that's apparently OK because ordinary users who can't be
| taught not to reuse passwords will just remember to make
| multiple keys across ecosystems for every website, and them
| needing to do that is apparently fine and nobody should
| complain about it or point out that it's not a reasonable
| thing to ask nontechnical users who can't wrap their heads
| around 2FA codes to do. /s
|
| And I don't know, I don't think that people get to use "when
| the ecosystem matures" when _Apple_ is telling its users to
| start using the ecosystem today. The ecosystem is mature, the
| industry has decided the ecosystem is mature enough to
| launch. The features that are still not implemented are
| features that the industry has decided were not essential
| parts of the standard. The industry and FIDO Alliance did not
| care enough to implement those features before launching
| passkeys and advertising them to regular users.
|
| ----
|
| So passkeys are an industry standard, but I am increasingly
| doubtful that they are an _Open_ standard in any of the ways
| that actually matter. Just because the docs are public, that
| doesn 't change the fact that the major implementations are
| effectively closed silos today. I don't know if I'm being
| greedy or if I'm spoiled by web standards processes, but I
| would expect an Open standard to have Open reference
| implementations that work on every single OS. I think it's
| weird to have a bunch of proprietary implementations and a
| spec for providers that is theoretically possible to
| implement on Linux but matters so little to the FIDO Alliance
| that the official dev site doesn't even list Linux as a
| target. Imagine if Matrix didn't have an Open client or
| server reference implementation. Imagine if that entire
| process was happening behind closed doors and the only way to
| get news about what the Matrix devs were working on was to
| ask on Reddit or Mastodon or Twitter.
|
| Would we call that an Open process?
|
| ----
|
| > All of the major vendors have committed to interoperable
| private key exchange as things mature and we're already
| seeing that with e.g. 1Password and iCloud Keychain allowing
| you to share keys with other people.
|
| Genuinely, not as a joke or a gotcha but as a real request, I
| would love to see actual documentation about this, because
| maybe I'm bad at looking but I've gone through the official
| passkey sites and I search online about this regularly and I
| can't find official confirmation of this from most of the
| major vendors. Arguably Apple seems to have committed? But
| it's tricky to actually determine that because I'm never sure
| if they're talking about cross-device _access_ or if they 're
| actually talking about transfer.
|
| I would love to see a section on the actual passkey.dev
| website committing to key exchange, that would make my day. I
| would love to see confirmation not on Twitter or a blog that
| companies are committed to this as more than a "nice to have
| whenever we get to it, but in the meantime just start using
| them, what's the problem." I would love to be wrong about
| this, please show me an official document from the FIDO
| Alliance itself saying that key exchange is going to be part
| of the standard and is going to be a required part of
| certification and giving even a semblance of a timeline about
| when it's going to exist.
|
| 1Password constantly gets brought up as evidence that
| interoperability and lock-in isn't going to be a problem, but
| 1Password does not support transfer between ecosystems and
| while they have said on _Reddit_ that they are interested in
| avoiding vendor lock-in, I can 't find official confirmation
| of that on the site and there is no timeline or details about
| how that's going to work. And again "it isn't going to be a
| problem" doesn't cut it anymore, people are recommending that
| users start adopting passkeys. It is a problem now. When a
| system gets launched and recommended to regular users and
| that system is missing critical infrastructure, that's not a
| future problem anymore; now it's a current problem.
| effie wrote:
| What problem does passkey solve? Passwords and SSH keys already
| exist, and I have no problem with them.
| gnabgib wrote:
| They solve three things:
|
| 1. You prove you have control of a key without telling the
| service the content of the key (like SSH keys, and any other PK
| setup) so: _you cannot lose your password_. The private part
| probably never leaves your device (probably - if you use Apple
| or Google 's implementation there's magic/low security sync,
| you might also manually backup the private keys to a file)
|
| 2. A new keypair is generated per service. Don't reuse your
| password is baked in the spec, and by using individual keypairs
| the service can't profile you by the public key (privacy).
|
| 3. And possibly the most important. WebAuthn (of which Passkey
| is a popular marketing term) includes the asking identity
| during the registration/signup and login/proof stages, it
| doesn't rely on the user inspecting the url/webpage look/auth
| domain. Ie. You cannot be phished by examp1e.com when
| connecting to example.com (much like SSH's TOFU, but sorely
| missing from most web interactions).
| nl wrote:
| It's amazing that this is the best explanation of passkey
| that exists on the web.
| danShumway wrote:
| The general idea behind passkeys (and WebAuthn in general) is
| _fantastic_. They 're phishing resistant (not totally phishing-
| proof, but way better than existing auth methods). They
| eliminate entire categories of phishing attacks around site
| identity. The UX flow provides users who would not be making
| secure passwords with strong-by-default security, making
| password reuse almost impossible. Even the cross-device
| authentication stuff, while not sufficient on its own for
| things like backup is still an improvement over copying and
| pasting keys.
|
| Being able to authenticate a device and log in without ever
| transferring your authentication credentials to that device is
| cool. That enables some security setups that would otherwise be
| very difficult to build.
|
| Some of the benefits are oversold (the privacy benefits seem
| overblown, there is nothing about passkeys that guarantees that
| your accounts won't still require email addresses, and there's
| nothing about passwords that forces sites to ask for email
| addresses, so nothing on that front is likely to change) -- but
| in general, the core idea is wonderful and passkeys would be a
| massive improvement over passwords if they were implemented
| well.
|
| The problem is the implementation and the development process
| for the spec.
___________________________________________________________________
(page generated 2023-10-23 09:01 UTC)