Live data from Hacker News

Bitwarden adds support for passkeys

bitwarden.com

91–100 of 172 posts

Re: Bitwarden adds support for passkeys

#91
post #51

Earlier quoted context omitted.

I hope they get over that. It's a blob of data. It's no more special than a TOTP secret or a conventional password, and I am completely uninterested in pretending otherwise because of a slick marketing campaign. It's a "thing I know" whether anybody likes it or not and you can't turn it into a "thing I have" just because you won't let me export it from this particular software. (Proof that it is a "thing I know": It…

I see this common refrain from people. How is writing something down so that you don't have to remember it a "thing you know"? You literally don't know it. A "thing you know" never leaves your brain, otherwise it becomes a "thing you have".

It comes from the fact there are three fundamental ways to authenticate: a thing you know, a thing you have, a thing you are. You may not "know" a passkey or a TOTP token, but you are using computers in their most fundamental role as bicycles for the mind to "know" them for you. This means they still fit into "thing you know".

Clearly a TOTP token is not a thing you are.

Less clearly, it is not a thing you have. Passkeys and TOTP tokens "want" to be a thing you have, but in the end they aren't. My little proof in my parent post may be small, but I'm quite serious... if you can store it in a password manager, that is proof that it is a thing you know, not a thing you have.

It turns out making a "thing you have" be a true thing you have is very difficult. It may even be impossible, in some sense. Everything that is a "thing you have" seems to be a thing you know masquerading as a thing you have through some security-through-obscurity.

Between that and the fact that "thing you are" has incredibly poor, if not outright dangerous characteristics if you try to scale it up, I'm actually not on board with the "passwords suck because things-you-know suck and we must replace them immediately!" I think they whole argument stinks of a classic engineering mistake of considering only the pros of one option and only the cons of another. I think when you take a holistic view, "thing you know" is the only practical, scalable option of the three basic options. If passkeys make it easier, fine, I'm up for some improvement, but I'm not on board the "passkeys must be a thing you have" and I fully intend to use them as things I know as much as I can and have no intention of letting anyone make my passkeys into objects.

Re: Bitwarden adds support for passkeys

#92
I've been waiting for this ever since Apple locked passkey support behind their existing (and infuriating) password autofill implementation. It irritates me so much that I refuse to use passkeys on iClould anymore, which is a shame becuase I really enjoyed the UI (for passkeys) and biometric auth built in to their products.

Re: Bitwarden adds support for passkeys

#93
post #39

From the FAQ [1]: > Q: Are stored passkeys included in Bitwarden imports and exports? > A: Passkeys are not included in imports and exports. I think it's the same for iCloud [2]. That is why I don't love it. I prefer a very long password, and Bitwarden "Device login" that will prompt in my iPhone that will require FaceID (So essentially I have bio login). And 2FA to lower hacking chances. I'm aware I'm still vulnerab…

> But essentially it's a certificate... I'll put upfront that I'm no expert in any of this, but ... unlike passwords and certificates, attestation is a thing for passkeys. The thing being attested to is "the private key of this cert is being secured by X". X might be YubiKey in the case of a FIDO2 key, or Google or Apple in the case of passkeys. This aspect of passkeys made me uncomfortable with them. If Google is go…

Yep. The end game of this is that web applications will, either through laziness or a sense of 'better security', only accept passkeys attested by Google/Apple/MS and/or those backed by TPM with non-exportable keys. You have to register with the FIDO Alliance to obtain an attestation GUID, and unsurprisingly, only the big guys are on the list: https://github.com/passkeydeveloper/passkey-authenticator-aa...

This move by Bitwarden clearly shows that they believe products that allow you to export/backup your keys will be blackballed, so they played it safe and blocked that.

Re: Bitwarden adds support for passkeys

#94
I'm missing something.

Webauthn puts a private key into a firewalled section of hardware onto your device - which is extremely prickly to work with in my experience - for your security.

For passkeys to be transferable the private key cannot be locked to your device.

Is bitwarden somehow able to "spoof" this hardware and have your browser generate private keys in it instead?

Re: Bitwarden adds support for passkeys

#95
post #94

I'm missing something. Webauthn puts a private key into a firewalled section of hardware onto your device - which is extremely prickly to work with in my experience - for your security. For passkeys to be transferable the private key cannot be locked to your device. Is bitwarden somehow able to "spoof" this hardware and have your browser generate private keys in it instead?

> Webauthn puts a private key into a firewalled section of hardware

This is not true. In general, Webauthn doesn’t care where and how the keys are stored. There is attestation feature, but AFAIK e.g. Apple intentionally doesn’t implement it for unmanaged devices.

Re: Bitwarden adds support for passkeys

#96
post #49
post #28

Does the code in Vaultwarden mimic the code in the self hosted version of Bitwarden? Or a code audit in Bitwarden has no bearing on vaultwarden?

In theory the Bitwarden server (and Vaultwarden) shouldn't have any access to the passwords, so a data breach of the server should never disclose any contents of the vault. Vaultwarden "feels" safe to me, but I would also be interested if there is some possibility it could introduce some degraded security compared to the official Bitwarden server. My Vaultwarden instance is "hidden" on a subdomain that probably nobod…

1. If an attacker got your credentials, they'll probably also have the server URL. Reasoning: They probably infected your machine with infostealer malware and keylogged the password. Or are you using the exact same credentials someplace else?

2. If they can figure out your domain name, they can check crt.sh for "mysecrectvaultwarden.domain.tld". If that only reveals wildcard certs and they're really interested in you or your company, they could try bruteforcing the DNS name.

3. If they breach the vaultwarden server and in case you're using the web UI, they can try to inject some JS to steal the credentials.

What I do to mitigate this: 1. Vaultwarden only reachable via VPN (e.g. wireguard on OpnSense) 2. Custom CA on all devices (e.g. step-ca with name constraints and local ACME [careful to put DHCP clients on a subdomain!]) 3. DNS for my LAN+VPN is not public. This massively reduces the external attack surface, compared to having a bunch of services available behind traefik.

Re: Bitwarden adds support for passkeys

#97
post #93

Earlier quoted context omitted.

> But essentially it's a certificate... I'll put upfront that I'm no expert in any of this, but ... unlike passwords and certificates, attestation is a thing for passkeys. The thing being attested to is "the private key of this cert is being secured by X". X might be YubiKey in the case of a FIDO2 key, or Google or Apple in the case of passkeys. This aspect of passkeys made me uncomfortable with them. If Google is go…

Yep. The end game of this is that web applications will, either through laziness or a sense of 'better security', only accept passkeys attested by Google/Apple/MS and/or those backed by TPM with non-exportable keys. You have to register with the FIDO Alliance to obtain an attestation GUID, and unsurprisingly, only the big guys are on the list: https://github.com/passkeydeveloper/passkey-authenticator-aa... This move…

It does say it will come in a future version now. The FAQ has been edited since the comment with the original quote.

Re: Bitwarden adds support for passkeys

#98

Earlier quoted context omitted.

> what's the phishing risk if bitwarden autofills only on the correct domains stored in the vault? The whole point of passkeys is that they should be tied to a specific domain, and thus be nonphisable. If Bitwarden allows reuse for different domains, that would be (as I understand it) a violation of the spec and a bug in their implementation.

Silly question perhaps, but what happens if a certain website changes to a different domain. E.g. a takeover of Company B by Company A who then decides to migrate all Company B passkeys to Company A and removes assets hosted under the Company B domain. This is easily sorted with existing tools but with passkeys... how?

If they had time to prepare I'm sure they could develop a flow to get you a passkey on the new domain first. Similar to how YouTube used to do a bunch of cross-domain redirects (to plant cookies) to get Google+ login support back in the day.

Re: Bitwarden adds support for passkeys

#99
post #51

Earlier quoted context omitted.

I hope they get over that. It's a blob of data. It's no more special than a TOTP secret or a conventional password, and I am completely uninterested in pretending otherwise because of a slick marketing campaign. It's a "thing I know" whether anybody likes it or not and you can't turn it into a "thing I have" just because you won't let me export it from this particular software. (Proof that it is a "thing I know": It…

It is special - it should be a reference to an asymmetric key stored in hardware. But it's not clear whether they are actually doing this.

A big part of passkeys is that they are (often) not in hardware, so they can be synced.

Re: Bitwarden adds support for passkeys

#100
iOS inhibits solving the cross platform problem, due to lack of browser extensions for all browsers.

I get to use iOS built-in password manager, sync only on Apple devices and then no where else; or I get to use Bitwarden everywhere but on iOS no browser integration, I have to copy and paste (separately) user and password. Or even more lovely, maintain separate managers.

Post reply on HN