Chrome's password manager is pushing it.

Everything else should be considered malware.

I don't understand how such a 'techy' crowd here on HN can be so belligerent with this security vs convenience trade off.

KeePass locally, gmail yourself an encrypted backup. That's it. FFS.

Google is just as powerful as state actors, the same rules apply.

Don't stick out.

The "Big Three" are on the FIDO board, along with 1Password. They can't really do the extinguish thing, and it really isn't in their interst to do so.

An no, the small tweaks don't kick anyone out of the game.

There will be other, perhaps more trusted, companies that you can use to move your passkeys around between eco-systems.

Unfortunately no. A passkey is a registered credential that supports user verification and discoverability, to support a usernameless and passwordless authentication experience.

U2F did not support either of these capabilities, and was only meant to be used for second factor authentication after a traditional authentication (e.g. username/password).

So a website which wants the passkey capabilities in order to provide a particular user experience is not going to be able to accept U2F devices - unless they provide those users an alternative experience. There may simply not be enough U2F devices in active use for many sites to justify that.

Newer Yubikeys which support CTAP 2.0 or later can generate "single device passkeys" for websites. The "single device" is meant to indicate that there is no backup capability, and losing that keyfob will lose the ability to authenticate using that mechanism. Web Authentication Level 3 describes this capability to websites, as they may this information to determine whether to offer a user any sort of 'account security upgrade' that removes passwords and/or site-provided recovery mechanisms.

Since discoverable credentials require storage inside the security key, the newer the keyfob is the more robust it is likely to be. It is even possible that some security keys may support some form of optional backup and recovery in the future (e.g. you could imagine a system with factory-paired keys packaged together, and a software agent that exports/imports that encrypted data)

> Or are MS+Google+Apple doing an "embrace, extend and extinguish" on webauthn?

I don't think any of them have a goal to reduce a diverse selection of webauthn authenticators. However, platform support does implicitly affect that ecosystem, because the shipped default is what most people will want to use.

The platforms may want to focus on a particular set of features, so this diversity plays to their benefit - I suspect at least some of the platform vendors want to point to the existence of a FIPS-certified Yubikey such that they don't need to implement such behavior themselves.

> Are the "small adjustements that ever so slightly reduces the security" sufficient to effectively kick security keys hardware vendor out of the game?

Leaving the remark about older security protocols not supporting the usability features - I think (and hope) there will be a place for hardware vendors to provide products and services to meet the needs of companies that platform vendors simply won't want to (or won't commit to on a reasonable schedule).

The hardware vendors may see consumer sales drop with the new alternatives, or may grow due to a significant increase in consumer understanding of what their hardware uniquely provides and in where their hardware can be used.

Yes the spec is horribly complex unfortunately.

In my own project I send the assertion and attestation as multipart/form-data. Which means I can just directly send the ArrayBuffers over the wire.

    PublicKeyCredential.prototype.toFormData = function (this: PublicKeyCredential) {
        const formData = new FormData()
        formData.append('type', this.type)
        formData.append('id', this.id)
        formData.append('rawId', new Blob([this.rawId]))
        switch (this.type) {
            case 'webauthn.get':
                if (!(this.response instanceof AuthenticatorAssertionResponse)) {
                    throw new Error('Unknown type')
                }
                formData.append('response.authenticatorData', new Blob([this.response.authenticatorData]))
                formData.append('response.signature', new Blob([this.response.signature]))
                formData.append('response.clientDataJSON', new Blob([this.response.clientDataJSON]))
                if (this.response.userHandle) {
                    formData.append('response.userHandle', new Blob([this.response.userHandle]))
                }

            case 'webauthn.create':
                if (!(this.response instanceof AuthenticatorAttestationResponse)) {
                    throw new Error('Unknown type')
                }
                formData.append('response.attestationObject', new Blob([this.response.attestationObject]))
                formData.append('response.clientDataJSON', new Blob([this.response.clientDataJSON]))
                break
            default:
                throw new Error('Unknown type')
        }
        return formData
    }

    async solveChallenge(challenge: Challenge, credential: PublicKeyCredential) {
        const formData = credential.toFormData()
        await fetch(challenge.location, { method: 'POST', headers: {'content-type':'multipart/form-data'}, body: formData })
    }

There are SaaS solutions that implement it for you and make it easy to include in your app.

Yes, the spec has improved somewhat but it is still more about describing and exposing individual capabilities rather than serving as an implementers' guide.

There are also usability differences in how the various platforms behave that can be difficult to navigate. In particular, it can be very difficult to restrict which options are presented to a user.

My hope is that efforts like https://passkeys.dev will serve to promote particular broad usability patterns (e.g. primary authentication) and serve to describe the choices and implementation within that context, as well as point people to libraries/products that may help get that experience.

> It seems like hybrid auth with your phone or FIDO gives you sign in, and local could be used for sessions?

by hybrid and local, do you mean the QR code based flow vs some local presented authentication system by the platform?

Generally - no, they are the same in that they both provide authentication in the manner the user chose.

Trying to say one is used for one authentication purpose and the other is used for a different purpose will just cause you to shoot yourself in the foot once they move from their desktop to their phone and the two roles switch.

Instead, there are two main behaviors - passwordless use as a multi-factor system, and use as an additional factor after some other authentication mechanism. These map to discoverable vs non discoverable credentials, and whether you are requesting user verification.

It is typically better to require these broadly and let the user choose whatever they want to use (their phone, their desktop, a security keyfob over NFC). Then, possibly react to their choice with additional checks. Outright rejection of the user choice is really limited to tightly controlled environments (such as enterprises who issue employees security key fobs).

> The developer UX was also pretty bad, ArrayBuffers was a poor design choice for passing around what ultimately becomes JSON.

Yes, its unfortunate - the guidance was that was the proper choice to make in JavaScript API, while it has made people have to build a lot of libraries to shuttle the (non-interoperable) data from their backend servers to the browser due to the lack of binary data types in JSON.

Web Authentication Level 3 proposes additional API to handle serialization of the objects to and from JSON in a browser-consistent manner. I do not yet know of a polyfill for this, but eagerly await seeing one.

[This issue](https://github.com/bitwarden/server/pull/2487) also suggests SQLite was added as a database driver last December.

https://news.ycombinator.com/item?id=34434877

I’m not convinced Bitwarden will go down the drain quite so quickly…

This sounds good, except how would it actually work?

I register in on my iPhone, it uses a key kept on that phone/iCloud. I log in via Safari on MacOS and it works because of iCloud sync.

Now I go to login using Edge on Windows. How can the website find out that I'm the same user as the iPhone/Safari user since I can't sync my key, and I can't enroll my MS Hello ID (or whatever Windows uses) on my Mac or iPhone?

And thats verifiable because their clients are open source.

This is also the case for anyone using unique passwords per site, which is the standard for password vault users. Not much of a win there.

> Additionally, private keys are stored on secure storage in client devices (or need to be decrypted themselves using a second factor)

Also exactly the same as password vaults, but we still stress about Lastpass losing their encrypted vault DB.

I agree that Passkeys appear to bring the benefits of Password Vaults to people not currently using them in a fairly easy way. However, I worry about access to those passkeys when access to the Passkey provider is lost/revoked.

Now, while 1P encrypted vaults are not brute-forceable the way LP's are, that doesn't mean it's impossible to hack 1P (e.g. malicious code injection in any of their apps or plugins), but I don't like the "everything turns out to be a false promise" broad-brushing when there are real and verifiable differences in how these companies secure your data.

The MSSQL database seems a bit heavyweight (RAM wise) given the tiny amount of data it needs to host for a handful of users, and isn't acceptable to some people on principle, since it isn't open source.

That experience sent me back to just letting Bitwarden host for me, I know it's all free and I can't expect anything which is fine, but I can't be without my passwords either.

I'm not a yubikey expert, but I don't believe that losing your Yubikey will open up your company to a breach.

For a typical passwordless solution, losing your phone isn't a risk, given that no one can reproduce your face or thumbprint.

If you are truly paranoid that your major device accounts are subject to termination without recourse (which if that happens you generally have lots of other problems and should maybe cause you to rethink your other trust relationships with such vendors and which devices you are buying), you can build your own Passkeys with WebAuthn standards and roll your own recovery/backup strategy. (Most FIDO compatible WebAuthn keys already work today anywhere Passkeys are supported, Passkey is just the "brand name" for those standards plus a soon-to-be-standard Bluetooth LTE handshake plus Vendor-guided backup and recovery plus whatever cross-device ecosystem "interop" standards the Big 3 eventually settle on.)

Not sure why the web extension doesn't. Might have something to do with autofilling or adding credentials to HTTP Basic Auth?

The expectation is that websites will allow you to register multiple passkeys, and that these may correspond to different devices. For instance, I may have both my iPad, android phone and windows desktop registered as three separate passkeys on an account.

There is a cross device flow that works across ecosystems, based on QR codes and wireless proximity. So the expectation is that websites could (if they desire) see that you authenticated using your phone onto your Windows Hello capable desktop, and ask if you want to register a new passkey from your Windows desktop to make things more convenient in the future.

Before platforms added backup to cloud sync fabric, you would lose your credentials when you lost your security keyfob or upgraded your phone. It was a user's responsibility to register additional credentials, such as remembering to go back after-the-fact to use a security key they kept at home in their firesafe to register their 'backup' credential.

This strong hardware binding made it more useful for secure environments (which typically have MFA requirements and staff dedicated to account recovery) and a lot less useful for consumer environments (which want to prevent breaches but not at the expense of additional user friction or support costs)

Web Authentication is effectively saying to let the user utilize whatever they want to authenticate, and let a relying website determine how to react to the capabilities or limitations of that choice. What is considered a capability or liability will depend on the particular deployment business requirements, and that will determine how they adapt. For example, an enterprise might decide to just reject everything except the exact security key they issued to an employee or contractor. For most other verticals, that is not a viable strategy.

Anyways, it depends on the app you use. Some Keepass apps haven't even been audited for example, so security of those apps may be questionable.

If he had a sustainable business and took the VC funding it means he has grander ambitions. That will mean change as well.

No matter how you look at it there will be change coming. Fueled by people who want a return on their investment.

1Password 8 has greatly improved security architecture compared to the previous versions. Just one example of many: when rendering the item details, the Rust core would not send the password value to the UI layer until the user clicks "Copy" or "Reveal" password.

In addition to that, 1Password 8 has better integration with the operating system that any other version in the past — Touch ID, Windows Hello, Secure Enclave, macOS Accessibility services, etc, etc.

1P would allow you to have a password like "1234" and still have the same key entropy as that 10 word password alone.

Trusting trust

Honestly, if they don't, they may find themselves under significant government regulation. The DMV in most states is hard to work with, but they work with everyone, regardless of disability, felony record, reprehensible views, everyone. If we're going to allow these companies to take this authoritative role in our systems, they should necessarily lose the right to refuse service. If they don't want that trade-off, then they should hand the whole thing to login.gov and other Government Identity schemes.

The best hinge point I would use in conversation with these players is to plan for third-party access from the beginning. Systems like Lastpass and Bitwarden have built robust systems for emergency access in the event of hospitalization or death. They've done so because its needed, often. If the Big 3 commit to allowing some access-for-transfer-out when accounts are closed or access is lost, even in non-ideal situations, that would go a long way.

How will Passkeys work for users who don't have or want a smartphone? There are plenty of people who carry no electronic devices on their person, and who primarily access the Internet through library access stations, other public Internet services. or multiple desktops. Will they be unable to use a site that is passkey-auth-only until they get such a device?

With respect to your confidence in 1Password's code and encryption methodology, would you be willing to send me your 1Password vault so that I can have a look at it?

Want to just encrypt everything on a node with no network access? Sure. That doesn't work for a "real" host but that is fine if you mostly use your phone and need to just occasionally sync your passwords back at home.

You don't need the things that make hosting hard. You can have a few hours of downtime. You password vault is gigabytes, not hundreds of terabytes. You don't need to arm guard your backups, just pass them (encrypted) to a friend with a safe.

I run it as a Docker instance on my home Synology NAS. This turned out to be pretty easy to do. The only part that was a slight hassle was buying a cert, creating an FQDN and making the DNS entries to get an SSL connection to the NAS. Also, I wish updating to a new version of Vaultwarden was a little more straightforward.

When I am at home, my devices with Bitwarden all sync to the Vautwarden instance on the NAS without issue.

My router is a Ubiquiti UDMPro. I have an L2TP VPN configured with a shared-secret and user passwords that are ridiculously long and complex. When I'm out and about and need to sync with the NAS from my laptop or mobile device, I activate the VPN and do the sync.

My Ubiquiti account does have 2FA.

I implemented all this when 1Password informed me that in order to continue using their service, my vault would have to be hosted on their server and I would have to pay them every month for the privilege. That was a nonstarter.

I'm sure my router and NAS are not impenetrable, but I don't feel like I'm low-hanging fruit either. And if someone went to the trouble of breaking in, their reward would be one guy's vault and not the vaults of millions of customers. I'm hoping that makes me a less attractive target. Of course the vault itself has a very long and complex password as well.

This is working out quite well for me so far, knock on wood.

Not necessarily. I wouldn't have felt compelled to redo all my passwords if 1Password's encrypted vaults were stolen the way LastPass's were, given that 1P's vaults are uncrackable with brute force but LastPass's critically depend on the entropy of the master password. This was discussed recently:

https://news.ycombinator.com/item?id=34359251

I’ve been wanting to switch from 1Password to Bitwarden for years, but each year I try it I’m just flummoxed by how atrociously behind the UX / UI still is.

Unless you (or whoever you’re getting to switch) are an absolute open source absolutist: do yourself a favor and go for 1Password.

[1] https://www.wsj.com/articles/password-manager-1password-rais...

I selfhost and use Vaultwarden myself and it is fantastic, so I wanted to support it on Nimbus fairly quickly (it’s going to jump the queue).

Deciding never to take VC funding is a big step but I’m definitely open to it as I’m trying to build a “lifestyle” competitor to AWS.

[0]: https://nimbusws.com

[0] https://github.com/keepassxreboot/keepassxc/issues/99

Where does this sentiment come from? I know very few applications I use that are VC funded or haven't gone through acquisitions...

If you want to gate it, you can just periodically update the local git repo after you reviewed it (or just follow up to main minus a few days).

https://github.com/dani-garcia/vaultwarden/issues/3082

Sorry, I don't mean to sound like an ass, they look like very well put together features. They just remind me of when Dropbox decided to start offering document editing. Not what I go there for.

But more importantly, I don't think VC or VC money is always bad, but I get extremely wary when a relatively small company gets a shitload of money that they'll then be forced to grow into a way that means they'll lose focus on their core product.

I remember when I told a friend of mine that Postman raised nearly half a billion dollars in total funding, and his jaw dropped "You mean that browser plugin that allows you to make REST calls???" And sure enough, postman got filled with more and more "enterprise-y uselessness" to the point that I just stopped using it.

The article above talks about them being shutdown

I agree, and I wish we had more power in these things than just forking. Now that I know Bitwarden took VC money, I'm also fucking out of this mess, and here I was about to renew for the 5th year in a row.

Fuck VC's, they ruin everything good. Can I say that here? It's true.

As a thought experiment, let's say there are 1000 people who get annoyed when a software product they use takes VC funding. For those 1000 people to sustain a software product with a team of 5 for 10 years at 150k average per head. you'd need 7.5MM dollars just to break even. That's $7,500 per user, or $750 per year. I doubt many people would be willing to pay that just to have a product that never takes VC funding.

And note that's just to cover labor costs. If you want it audited, that's a solid 25k per audit. Operating costs for website and infrastructure, etc. Now if the product was exceptional and beat out other products in the space and generally had a slice of the pie, the number of users would increase and per user cost would decrease. But also doing as much with a team of 5 is no small feat.

There are iOS and Android clients, too. Not especially polished, but they do the job.

I'm sure I'm not the only one who's tired of the bait-amd-switch of companies who are all about freedom until they get acquired by a giant and then start hastily walling their garden.

Right now I am hunting for a non-subscription note taking setup that will replace SimpleNote.

So I’ll move to the next option from BW, just like I moved to it from LP.

I think that a worker-owned cooperative is not really in line with what I would consider to be the traditional cooperative spirit.

Customer-owned has a clear mission to deliver value to its owners. That value would be to provide various services essentially at cost. Workers are paid market rate to get the work done. Profits are given back to the owners (customers).

Worker-owned also has the mission to deliver value to the owners. The workers are going to value making as much money as possible, though being careful to not go past the point where they would find themselves without a job. So this type of co-op will be trying to extract maximum value out of the customer. This is a significantly different proposition. This type of co-op seems more like a company with an ESOP.

I could see either type choosing to sell out. I guess either the workers or customers would think they have better places to invest the capital. So I guess co-ops too have up and down lifecycles like a standard company. As the co-op becomes ineffective or no longer needed, the capital invested in it would be re-deployed.