Bitwarden Acquires Passwordless.dev
bitwarden.com
bitwarden.com
That's great, since AFAIK all existing passkey implementations are tied to a specific browser or OS, and have no way to export the keys, which isn't great for a program designed to own the keys to your digital life. I'm hopeful Bitwarden will solve that problem, and that their example will encourage other popular password managers to do the same.
(...or at least, I think "passkey support" means they plan to support storing passkeys in Bitwarden itself. I hope it doesn't just mean they want to let you use a passkey to log in to Bitwarden. That'd be really disappointing, and probably a poor choice strategically given that passkeys aim to eventually render traditional password managers obsolete.)
It’s shaping up to be a cool year for password management!
One of the big challenges to passkeys right now is that they aren’t as versatile as passwords, but this doesn’t have to be the case. Passkeys should be able to be exported and stored anywhere you want (ideally in an open source solution). Bulwark Passkey supports that right now, but I’m glad that other products are also providing solutions to users for the same problem.
Hence FIDO2 and Passkeys feature 'attestation' that allows them to only accept 'trusted' implementations. This accreditation is a crypto process so it can't be faked.
So, you can't just put your keys in any app you wish, like you can with TOTP. There will be strong pressure to just 'go with the flow' eg mainstream OS implementations and us with niche OS or cross platform requirements will be ever more marginalized.
Any complaints will be simply rebuked with "For security reasons" or "We only certify implementation X, Y and Z".
My work is already doing this, they only support Yubikey and one other brand through their Identity Provider, if you have one of the open source tokens you're straight out of luck. Passkeys don't work yet either but I'm sure they will only 'certify' Apple and Microsoft and leave the rest hanging. They love quoting the pareto principle / 80/20 rule as an excuse.
Something that we're looking to solve at Stytch[1] from the developer's perspective. We're finding that the different platforms have their own twist on Passkeys implementation and all have different UX suggestions.
Google said they plan to play nice and support 3rd party implementations. When I asked Apple during their Slack Q&A event on Passkeys they said that have no plans to support 3rd party implementations at the moment. I don't know how Microsoft and Mozilla feel. I would be a lot more optimistic about the whole thing if platform players would come out and commit to allowing 3rd party Passkey managers. Otherwise you'll never be an option in the system "choose which credential to use" dialog when some website/app wants to actually do webauthn.
1Password and Dashlane have both announced support for generating/using passkeys via their browser extensions.
It is a good thing that bitwarden is looking at this too.
The tech for password vaults is so simple, I use keepass + icloud syncing and get free end-to-end encrypted password syncing, without sharing any data with anyone.
Outlined in more detail here: https://magoop.substack.com/p/how-to-manage-500-passwords-se...
KeepassXC to be specific: https://keepassxc.org/
And thats verifiable because their clients are open source.
You raise a good point that their open source clients are _verifiable_, but they're not often _verified_. I'm certain that you verify the checksums of all your updates or exclusively build from source, but the distribution channels on most platforms encourage users to trust updates from BitWarden inc. If those channels are compromised, most users are one unchecked automatic Play Store update away from a problem.
Not disagreeing, just noting that Open Source is not a silver bullet given BitWarden's default architecture is centralised web service with centralised client distribution channels.
It's not materially different than storing your KeePass vault in the cloud.
The code they are running does have to be the code they are publishing.
And if someone compromises their cloud servers, they could also modify it to log the passwords entered.
Trusting trust
Basically, your master password is never sent, and everything is encrypted and decrypted locally.
You can't audit the server side code, but you can audit the client (and compile it from source) to make sure that the encryption is local and the master password is not sent.
As long as the client and cryptography are uncompromised, the server only gets metadata.
Basically, your master password is never sent, and everything is encrypted and decrypted locally.
You can't audit the server side code, but you can audit the client (and compile it from source) to make sure that the encryption is local and the master password is not sent.
https://apps.apple.com/us/app/strongbox-password-manager/id8...
On my devices, keyfiles and a KP client are stored locally. The DB rests in the cloud.
I think one distinction between services like KeePass and 1Password is end user perception of how easy it is for an attacker to acquire an encrypted vault to begin with. For many, they consider a KDBX database sitting in their Dropbox account to be less likely to be stolen than an encrypted vault being held by a company like 1Password, a high value target to the most sophisticated attackers including state actors.
That's just not accurate:
1. First off, all the encryption happens client-side. It is possible for anyone so inclined to validate how 1P and LP are doing their encryption.
2. The deficiencies in LP's encryption approach were well known for years.
My point it, yes, companies will spin things how ever they want, which is why you should completely ignore what they say and only evaluate what is verifiable. And 1P's and LP's approaches are verifiably different.
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?
It's Javascript running in a browser.
> 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?
Yes, absolutely (note I don't actually know how to get the encrypted version of the vault standalone). Are you willing to send banking information over HTTPS? It's the same level of security.
I believe that, given that it's just JavaScript in the browser, that the encrypted vault should be available as a blob in one of the network requests when you are making a change to the vault.
> Are you willing to send banking information over HTTPS? It's the same level of security.
Maybe I'm being irrational, but I just think there is a fundamental difference in the risk profile between a breach of my banking credentials and having every stored set of credentials across my entire digital life exposed through a password vault breach.
If my banking details were compromised somehow, I at least have a bank I can work with and real people I can talk to. Both the bank and myself have a strong mutual interest in addressing the acute security issue. Government banking regulations come into play. Insurance comes into play.
If my password vault is compromised and credentials for every service and website are exposed, I would argue that is a far graver matter. And who do I turn to in that case? I have to imagine that any of these password management companies would just point to me being somehow negligent with my master key and tell me to pound sound.
With their very comprehensive whitepaper and Charles Proxy you can verify all their claims. Their whitepaper is one of the best resources I have found on E2EE in general. With that, you should be able to write your own 1P vault parser. Then you can verify that traffic to their server is exactly what they claim it to be.
In another comment you are criticizing that their product is proprietary - that's IMO not quite true. Yes, 1P is closed source, but their crypto strategy is documented extensively - they list the exact cipher algos and settings.
> not only with respect to vault encryption but vault storage and operational security
That's a valid argument, BUT, if you read their whitepaper, you'll likely arrive at the conclusion that even a full leak of the encrypted vault is currently not that problematic. I wouldn't post it online, but I'm not worried if they announce a leak tomorrow.
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.
Are you waiting for Snowden 2.0 to explain how things work a decade later?
My only point is, if 1Passwords decides to share the private key with [whichever cloud service] the user should at least be notified, or get a choice.
Can you elaborate what the issue would be? I see that the AppleID password could be a weak link, but that's mostly mitigated by 2FA.
> if 1Passwords decides to share the private key
I'm not aware that they could do that. Their servers have no knowledge of either the password or secret key. Authentication happens via a zero-knowledge proof.
I'd rather use an extremely high entropy master password by itself.
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.
How would you remember a password of 128bit of entropy?
1P would allow you to have a password like "1234" and still have the same key entropy as that 10 word password alone.
Also see: https://xkcd.com/936/
Do you have a browser extension that offers username/password autofill using keepass as datasource or do you alttab copypaste / rely on a program made by someone else to clear your clipboard?
If apple gets too greedy with iCloud, you can sync your kdbx with 1000 other clients.
There are a few basic features missing, such as that if I search for something I wrote in the notes of password, that the client shows the according password. I get that the open-source model implies that everyone can contribute and fix this issue, but if I look at the repo and see 108 open PRs, I don't even bother to check if that's a feature that would be easy to add.
It doesn't take me many seconds to swap accounts. LastPass allows you to be signed into two accounts at the same time in the same browser?
I'm using that on my VaultWarden server to share data between different accounts and it works well for me. This may not work in your specific situation if your company manages your Bitwarden account, though.
Not sure why the web extension doesn't. Might have something to do with autofilling or adding credentials to HTTP Basic Auth?
Folder management in particular seems to have been an afterthought. You create a subfolder by setting its name to its full path in the hierarchy, including all its parents. And thus, in order to rename a folder you have to manually go through every single subfolder and rename the particular parent in its name.
Other annoyances off the top of my head are things like the inability to change the type of a custom field from e.g. text to hidden without deleting it and creating a new field. Or the browser extension forgetting everything you just typed into the new item form (unless you remember to pop out the window) when pasting a generated password on the site you're trying to register to.
After switching from KeepassXC to Bitwarden for its better auto-fill detection and convenient synchronization, I can't help but feel that it's also been a downgrade in more ways than expected.
https://community.bitwarden.com/t/persistent-bitwarden-ui-an...
A recent response to this issue was that "it's a feature, not a bug". I've been waiting to see it added to their roadmap, but it's missing from the 2023 roadmap. So I guess I will have to wait another year
It might be that your search term is a partial of a word. This is fine when searching some fields, but for finding entries with that word in the notes section, the search term needs wildcards. You can read more about it here: https://bitwarden.com/help/searching-vault/
But to paraphrase: "notes: Item's notes. Only full-word matches will be listed unless you use wildcards."
Hope it helps.
1Password does, and is much easier to use (though I use both)
Anders Åberg (@andersaberg) who is the founder behind this is a really enthusiastic and inspiring coder. I've always enjoyed his mashup hackathon ideas and meetup presentations. :-)
This page is a good starter:
As for how "passwordless" plays into this, Passkeys are generally better than passwords simply because it's PGP instead of a shared secret you send to the website, so even if a website is compromised, there's effectively 0 way the compromised database will enable password stuffing attacks on other websites.
Another cool thing is QR codes via caBLE (cloud assisted BLE), you can scan a QR code on a browser (on a bluetooth-enabled computer) to have your phone connect to that computer and present its passkey to the computer, without needing to actually plug in your device to the computer. This is not strictly a passkey thing, it just aids in making them usable.
It makes sense to approach this new paradigm with a healthy dose of skepticism, but there is evidence your concerns have solutions.
However passkeys depends on a yet to be published standard for QR codes + bluetooth + websockets for doing WebAuthn from a second device. But that is planned to be published soon.
The developer UX was also pretty bad, ArrayBuffers was a poor design choice for passing around what ultimately becomes JSON.
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.
Passkeys don't rely on this mechanism (although being able to authenticate your desktop using your cellphone is a very valuable user experience!)
This upcoming mechanism is also meant to be used between platforms (or at least, a platform and an extremely robust authenticator). It is not meant to be used by a website or native application which want to just rely upon/consume credentials. If the browser/platform supports this mechanism, it will be presented to the user as a choice of how to authenticate.
[Edit]: An important feature of "Passkeys" is that browsers and operating systems have a special API that allows an app to pre-start a sign in with a known user/email/etc. which if there is a passkey for that user it'll automatically start the FaceID or similar confirmation process. Which Passkeys are checked is controlled by the OS/Password Manager which checks which website is asking and what username it's checking. This is just to make it so it seamlessly logs you in. It does a fall-back to just asking what your user is which is the initial workflow.
This[0] is a good podcast to listen to with Adam Langley from Google about how Chrome supports Passkeys and why they're a good thing. It includes the details of how/where/why there are some proprietary bits needed to implement "Passkeys".
[0]: https://securitycryptographywhatever.buzzsprout.com/1822302/...
FIDO Alliance Press Release https://fidoalliance.org/apple-google-and-microsoft-commit-t...
Chromium Blog on Passkey support (Dec 8, 22) https://blog.chromium.org/2022/12/introducing-passkeys-in-ch...
WebAuthn is the short name for the "FIDO Alliance Web Authentication Protocol".
"Passkey" is the trade name (that Apple tries to own) for the "stuff" that results from using the WebAuthn protocol. At it's root, a passkey is really the private key portion of that "stuff" that is kept. So yes, in practice, a passkey is the result of a WebAuthn implementation.
MS, Apple, and Google don't implement WebAuthn. Companies like mine do. Each website out there that wants to use passkeys needs to employ WebAuthn, whether via build or buy. What the "Big Three" do is leverage their OS's and platforms to enable the storage and migration of passkeys within their eco-system. WebAuthn is implemented in their browsers, and they enable the use of passkeys (which websites make happen via implementing WebAuthn).
One thing to note is that the Big Three also make a small adjustment to the WebAuthn protocol to allow passkeys to shared inside their cloud infrastructure. This every so slightly reduces the security of passkeys (which start out as very, very many orders of magnitude more secure than passwords).
You can read about Passkeys here: https://passage.id/post/a-look-at-passkeys
More on WebAuthn: https://passage.id/post/what-is-webauth
> Here are some guidelines for how to refer to passkeys in your apps and websites. "Passkey" is a generic, user-visible term. This video focuses on Apple's implementation, but as I've just shown you, other major platforms have already started building their own support for passkeys. "Passkey" is also a common noun, like "password." In English, this means it's lowercase and gets pluralized like "password" would. I have a passkey for my account, and I can go to Settings to view all of my accounts with passkeys.
> What the "Big Three" do is leverage their OS's and platforms to enable the storage and migration of passkeys within their eco-system. WebAuthn is implemented in their browsers, and they enable the use of passkeys (which websites make happen via implementing WebAuthn).
That was really helpful, I think that was the bit I was missing.
I am strongly opposed to any authentication system that makes my authorization workflow for unrelated third-party sites dependent on any company whose terms of service allow them to suspend or terminate my use without reasonable recourse or recovery.
Passwords have problems, but I can print them out on a piece of paper in a fire safe.
Currently, you cannot move them to other devices without the cooperation of some cloud service, or the like. At some point you'll have to trust someone to move passkeys between devices.
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.
Or are MS+Google+Apple doing an "embrace, extend and extinguish" on webauthn?
Are the "small adjustements that ever so slightly reduces the security" sufficient to effectively kick security keys hardware vendor out of the game?
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.
Web Authentication is a standard from the W3C, with original contributions from FIDO Alliance and a lot of collaboration with members. It is very much not a FIDO standard.
FIDO has their own branding, marketing, and certification, as well as the CTAP protocol which builds on top of WebAuthn and describes how to communicate to an externalized authenticator (e.g. a USB or NFC security keyfob). They also work on several standardization efforts in other areas, such as IoT device onboarding and identity verification for documents.
> "Passkey" is the trade name (that Apple tries to own) for the "stuff" that results from using the WebAuthn protocol.
A passkey is a non-trademarked term (at least by Apple/Google/Microsoft) for a Web Authentication credential that has been registered with a site, that provides user verification, discoverability, and (optionally) backup eligibility characteristics.
In layperson terms, it is "a more secure alternative to a password" provided by their password manager. In particular, that security is strong phishing resistance as well as breach-resistance (e.g. greatly limits the impact of a copy of a website credential data dump)
Now Google killed U2F in Chrome (and hence Chromium etc.) but you can migrate your webserver to use webauthn instead of U2F and your users' old U2F keys shall keep working.
For the "new" webauthn, called passkeys, which is a modified webauthn: I've got no clue.
It's not clear to me if old hardware security keys shall keep working or if we'll all be forced to use software keys protected by Google/Apple/Microsoft.
The authenticators allow for this registration and proof via generated public key pairs. These key pairs along with other configuration are referred to as Web Authentication Credentials.
There are several modes you can request, such as user verification (perform an additional non-possession factor, such as prompting for a PIN or biometric). You can choose between a model where you challenge authenticators based on previous registration handles, or "ask into the void" if any authenticator thinks there's a valid credential registered for the site. That second mode is called a discoverable credential.
A passkey is a discoverable credentials which supports user verification.
The term isn't trademarked, and just is meant to describe 'a more secure alternative to passwords', but there are a minimal set of features supported. The hope is, like passwords, society will get to a point where we don't have to explain what a passkey is. Support is typically provided by the same software and integration as a password manager.
It doesn't require any capability which was not in Web Authentication Level 2, the prior spec. That said, the platform vendors appear to be taking a much more opinionated idea on how things should be used, and what sort of capabilities (and security posture) should be exposed via the authenticators exposed by their browsers/operating systems.
Most particularly, passkeys are expected to be backup-eligible - e.g. that there is some sort of back-end storage and recovery mechanism. This likely is tied to some sync fabric provided by the platform.
This provides a better user experience in many cases, and reduces the burden on websites to do account recovery (say, if you lose your security key or buy a new cellphone). An authenticator like a Yubikey 5 which supports the other features but does not support backups generates credentials called "single device passkeys" to distinguish this behavior.
Web Authentication Level 3 should eventually expose this backup information to websites, as it is likely a relying party will want to know that the user credential is somewhat 'robust' before they take any sort of migration step like offering to delete any password-based credentials previously used on an account.
In terms of how it is most commonly used - there is significant established usage of WebAuthn, which also supports the functionality of old U2F keys as second factors to a password-based login, such as on sites like Google and Github.
In terms of the 'usernameless and passwordless multi-factor' authentication provided by passkeys, it is expected that the commitment by Apple/Google/Microsoft to support this system will drive adoption, and that it will become the dominant mode of operation. This is all relatively new though - Apple and Google launched toward the end of last year with new backup-capable passkey implementations and new platform-level UX.
That said, the backup eligibility concerns more traditional organizations who are concerned about having Apple/Google/Microsoft clouds as part of their attack surface. The cloud synchronization means that it is debatable whether it meets their needs of considering the phone as a physical factor. And Apple at least offers the ability to 'share' passkeys with contacts over proximity wireless, which interferes with some regulatory requirements. A certain amount of evolution may be needed for them to accept a credential from an authenticator with these characteristics as a sole factor.
Technically a Passkey is just a multi-device FIDO credential that is compatible with WebAuthn (which is an official W3C and FIDO spec).
However, vendors implementations of Passkeys/FIDO credentials differ quite widely. The Apple implementation of Passkeys, as an example, doesn't provide attestation information which reduces the ability to do device verification. Similarly, even though it's not technically part of Passkeys, Apple removed the possibility to create device-bound WebAuthn keys which significantly weakens the security guarantees you'd normally get with WebAuthn.
Apple's changes do degrade security, but I think it is important to note that even with those degradations, Apple passkeys are still many orders of magnitude more secure than passwords.
Please correct me if I'm wrong on any of this.
Apple already supports Keychain sync with Edge on Windows and I believe that already supports Passkey access.
Also, I believe I heard rumor that "Sign in with Apple" (their existing OpenID Connect account system) will also eventually support helping you enroll non-Apple devices to Passkeys in apps that support both Passkeys and "Sign in with Apple", though I don't know if there is yet a timeframe on that sort of support.
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?
Once the user has signed in, a modality check shows that they logged in with another device, while a capability check shows that they _could_ have authenticated with the local device if it had been registered. This may trigger the site to prompt them to register the local device as a second mechanism (or they may just go to the self-service account management tab to do it themselves).
But any level of that may take responsibility - for instance, 1Password and Dashlane replace the browser/platform support by default by altering the implementation of the javascript API via their Web Extensions.
There are ramifications to this approach, such as having to fall back to the browser/platform UX to support hardware security keyfobs.
The platforms (and browsers using their API) also support or plan to support a cross-device option, where you should be able authenticate within a desktop browser using your cellphone via QR code and radio proximity checks. The vision is that some websites will see that the location browser _could_ have supported authentication directly, and offer to help the user register it as a second (more convenient) option.
Also wondering if anyone knows why this device [1] doesn't work during the "passwordless" sign-up/sign-in process on dogwarden1.passwordless.dev. Am I going to have to buy yet another hardware key if I want passwordless logins?
I believe the goal for Bitwarden would be the same, to allow for seamless login through a secondary device using WebAuthn and friends. Apple and Google are already working on cross-device FIDO2 login support, but for Firefox I haven't seen much announced as of yet. Bitwarden filling in for Apple's/Google's proprietary services would be a way to log in securely without giving up even more security features to browser companies.
However, I'm curious what y'all think about the cost. A digitalocean droplet for the recommended specs (4 GiB memory) is $24/month. This is hard to stomach when you compare with Bitwarden Premium which is <$1/month. I guess it depends on how much you value your own data.
DO inflates prices for their systems, sometimes I guess it’s worth it but you can get a great dedi with FAR better performance from Hetzner auctions for $32/mo. 64GB RAM, proper CPU, large HDD, could probably host a thousand Vaultwarden instances. Definitely don’t use that for just Vaultwarden, it’s just an example, but yeah.
[This issue](https://github.com/bitwarden/server/pull/2487) also suggests SQLite was added as a database driver last December.
discussed when it was announced: https://news.ycombinator.com/item?id=31098608
Pedantry aside, yeah that seems expensive given the amount of convenience offered. But much more convenient than setting up a server in your basement with a UPS and external backup drives and such.
It also seems like a way companies like Google would lock people into their browser.
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.
The stress was because Lastpass databases were only partly encrypted and the encryption was not based on random keys.
The current legal climate is mixed but we have court cases that claim biometrics are not covered by the 4th and 5th. We also have the opposite. The reasoning being that producing biometrics is not testimonial. Until decided by the Supreme Court, I'll assume that anything that can be produced without my mind is not covered and that includes this.
I am not a lawyer and this is not legal advice.
You should be having third one - backup token stored securely in the safe or vault. That is $150 investment just to do it right.
And then - not all webapps allow to register more that one FIDO2 device, which totally cancels the above best practises.
Theoretically, your Passkeys should still be on your iPhone/iPad/Mac/iThing, and QR authentication will work. (And then you provision another key on another device, since Passkeys' intention is like SSH keys, allowing multiple on a single account)
Unlike TOTP, the base case for passkeys is multiple key enrollment so websites are more likely to support it well whereas with TOTP so many implement it as having one-and-only-one TOTP configured. Even when enrolling just a single device that device generally enrolls a small key-chain, not just a single key, because that's how recovery systems work even for using just a single "owner" account. Plus most people use 2 or more devices regularly and Passkey has to work with that. So much more websites in practice should actually support N passkeys where N > 1 (versus half-baked single-option-only TOTP implementations).
At least in theory, in practice we'll see how well Passkey gets implemented at large, there's always lots of ways for companies to get practice wrong.
Are Passkeys exportable and re-importable by another service, site, or system? As described above, if my Google Account is terminated by Google without recourse (which absolutely happens), do I lose access to all sites that I used solely a Google Account Passkey for once my phone stops working?
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.)
If this is the case, then maybe there will be some solution through Google Takeout. Apple and MS seem less interested in this, but if one of them can generate an export, I can see services appearing that can work with that exported data.
> you can build your own Passkeys with WebAuthn standards and roll your own recovery/backup strategy.
This....or I can stick with passwords, print them out annually and put them in my fire safe. The KISS principle works here, and I can't imagine a non-techie person who works in a socially-risky field being able to do so.
> 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)
Complaints by users who have Big 3 cloud accounts closed for unspecified "violations" are common enough to make it a concern. I take other protections against something like this, but I absolutely do consider it a risk, and would generally advise people not to keep all their digital services under one roof. If you use Gmail for email, then use Microsoft or Apple for Passkey, Bitwarden or 1Password for Password Vaults, etc., etc.
So far as I'm aware none of them are planning key exports any time soon. Keeping keys to the various secure enclaves of user's devices is a key part of the security footprint they are trying to establish. That's why multi-key enrollment is the base case in all Passkey systems: recovery, multi-device support, etc all hinge on continuously expiring old keys and auto-enrolling new ones. There's no export, and cloud backups aren't "backups" but different, Vendor escrowed keys (often themselves in hardware cloud secure enclaves that cannot be exported, only new keys added to keychains) and ways to attest for (sign) new keys in recovery situations.
As I said way above, the theory is that enrolling all of your devices and all of your top-level recovery accounts will be easy and convenient enough on every website, not just your bank (given how many banks still don't even support proper TOTP, hopefully better than some banks today), and enough so that everyone does it by habit. I agree, there's huge practical risks that someone gets it wrong and there's all sorts of ways what should be easy turns into complicated soup that never works right. That's the brief glimmer of hope here offered by the Big 3 alliance on this and making it a major marketing endeavor. They've put a lot on the line for this.
> This....or I can stick with passwords, print them out annually and put them in my fire safe. The KISS principle works here, and I can't imagine a non-techie person who works in a socially-risky field being able to do so.
The hope is that with the Big 3 all in agreement here on passwords needing to be entirely replaced and the only way that happens is if what replaces them is as easy and uncomplicated as possible for non-technical to use every day, Passkeys will see strong implementations everywhere and that cross-vendor multi-device interop will be strong enough for everyone to rely on (even if you distrust one or all three of the Big 3).
> Complaints by users who have Big 3 cloud accounts closed for unspecified "violations" are common enough to make it a concern. I take other protections against something like this, but I absolutely do consider it a risk
I consider it a risk too, but as with all things security every risk needs to be evaluated within the template of a larger threat model. Email is already the de facto chokepoint for recovery of almost any account (and passkeys don't necessarily change that, "Forgot Password" flows still probably exist in passkey worlds, just differently). You have a ton of eggs in whatever basket is your email provider (and for the majority of people often one of the Big 3). Phones are already the de facto chokepoint for account access (whether because of TOTP or single ecosystem "apps" or all sorts of other lock in mechanics). Passkeys don't substantially change these existing deep trust relationships (and weren't really designed too), most people in most threat models the amount they are trusting their various relationships with the Big 3 doesn't substantially shift with a switch to Passkeys. (For good and bad. Absolutely some people are underestimating exactly how much they trust one vendor or another and how much they have to lose if their account is suspended for any reason without warning or easy recourse.) (Your threat model is your own and will vary, of course.)
On top of that, other vendors will be playing ball in this space. Mozilla isn't a direct part of the "Passkey Alliance" but has stated their interest in Passkeys and cross-platform/cross-device interoperability. There will be more, too, over time. Possibly enough paranoid people will roll their own that good self-hosting and open source options will roll out eventually, even if most people won't use them and most people won't need them in their personal threat models, having more options is always a good thing (and Plan B if your threat model changes for any reason). All of this is in a cloud of enough open standards that vendor lock-in, while maybe not impossible, should be unlikely.
You are right to be worried. You are right to be questioning all of this. I appreciate your concerns here (I know I have an uneasy relationship at best with at least one of the Big 3 myself). I hope I've offered at least some reasoning on where some of your concerns may be mitigated by the ecosystem as a whole.
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?
I think the immediate answer is that something like a Microsoft Account-based login system and Cloud-based key escrow becomes more unavoidable in situations like that. But I'm not sure and hopefully there are smart minds exploring some of these scenarios in the long term. Relatedly, I know there are some long-term creatives trying to figure out if "smartphone" is becoming a required utility for the modern world (TOTP has already made that a recently strong requirement in plenty of areas; soon you may not be able to bank without a mobile device, for instance) and the "phoneless" may be its own evolving economic crisis on top of homelessness to deal with in the long term. "Give everyone phones" may sound like a curt, dumb answer, but it may end up being something close to the answer; go to your local DMV and get a secure phone as your digital ID to go with your physical ID. I don't know if that is the plan, I just know it is a plan I've heard we need to consider, that "baseline personal hardware" may be an ever-increasing need.
This is probably testable as it is. They sync to iCloud Keychain, as is my understanding anyway.
How are the rest of your passwords stored in iCloud Keychain when your account is hosed? Do you lose those or does it just turn off syncing? I'd imagine it turns off syncing but keeps the keychain around unless you delete the iCloud Account from the device. That's a whole different ballgame of potential bad decisions though.
I’d say we’re going to see polished libraries soon that will abstract all the details away, but services like this may help less experienced developers to quickly get secure auth working.
You have really good newer methods of auth. Instead of selling them as good MFA alternatives security vendors decided to replace passwords because that differentiates them more. But in reality, the layer of defense "what you know" should be complemented not replaced. A reduction in security being sold as a feature is dishonest and harmful.
2FA>1FA
The threat surface of a passkey based solution is like a small puddle after a rain.
How is there a "reduction" in security here?
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.
Or more correctly: I got so far but stopped because I prefer to have my keychain locally :)
Currently, if you use an iPhone, you will have the passkey stored in iCloud keychain. Your "account" is a private key held within iCloud keychain, along with some metadata mapping that private key to the site you visited.
Anyway this really needs to be exportable, otherwise its in the ultimate platform lock.
[0] https://github.com/FiloSottile/passage [1] https://passwordstore.org
Granted this is Bitwarden acquiring rather than being acquired, but I still worry it leads to a trend of building "portfolio value" rather than focusing on the product. I sincerely hope I'm wrong.
https://github.com/dani-garcia/vaultwarden
Though I fear it’s only a matter of time before the VC gods demand the client apps remove compatibility and they have to be forked too.
[1] https://www.wsj.com/articles/password-manager-1password-rais...
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.
Did you check 1Password developer tools, like SSH-agent server, git commit signing, and CLI? https://developer.1password.com/
Or the new item and file sharing. https://support.1password.com/share-items/
I put them under the same reliability umbrella (maybe even a touch higher) than Fastmail, which is high praise IMO.
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.
We have a lot of 1Password customers with families and team members that require more than a single vault, need an option to recover team/family member access and often have to securely share data with other people, accountants and lawyers. Also, many of developers and admins that want to keep their SSH keys safe.
- Drag a password into a password field
- Drag an attachment from Finder/Explorer into an item
- Drag an item from vault to vault (or collection in Bitwarden parlance)
- Drag an item into a tag or folder to add that item to the folder, or add that tag to the item
- Drag an app to the 1Password icon to create a software license item with the icon of the app as well as name
There are also drag and drop functions, some similar to above, on iOS as well.
Bitwarden is... and I agree with the grand parent here, awful from a UX angle, compared to 1Password. It's certainly functional, but that's about where it ends for me.
If you don't have the app installed it opens the website in a tab to signin and edit.
Until recently I was using it for two different accounts in the same 1Password business account, one account enabled with integration to the desktop app and a second account on another browser profile (for admin purposes) with just the browser extension.
Neither of those necessitated logging in again in another tab.
Still using 1Password, but Firefox containers have removed the need for multiple Firefox profiles.
For a second business I use Bitwarden, and that works well, but I find 1Password superior in so many respects.
The 1Password browser extension and application should sync, but it’s experimental on Linux AFAIK.
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
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.
I wasn’t aware of this, but I’m glad I am now. If that’s the case it’s time to look elsewhere or self host, VC funds and acquisitions are rarely good for users so I’ll assume the worst.
With BW I have never expected the same and I am still hopeful on giving them the benefit of doubt.
The licenses are also confusing — people had to purchase apps separately for every platform: macOS, Windows, iOS, Android. And then they had to purchase upgrades separately as well.
The article above talks about them being shutdown
Where does this sentiment come from? I know very few applications I use that are VC funded or haven't gone through acquisitions...
$100M to develop a new processor or phone or vaccine or search engine or social network that delivers video to everyone worldwide is different than $100M to a password manager or other “simpler” project.
If the user base does not increase at some rate determined by the investor, then growth comes in the form of advertising, partnerships, or similar that negatively affect the _product_ existing customers signed up for.
When investors get involved in software, you end up with winners and users.
1. Totally agree with the comments that VC funding absolutely killed LastPass.
2. Twitter is probably another good example. Twitter was a really large business, but they were constantly wringing their hands about what they could do to get as big as Facebook or Instagram. What if the answer was always just "No, you'll never be that big, just don't even try". So instead of improving their core bread-and-butter (and fine, easy to argue they didn't even do that super well), they wasted a ton trying to get users who were never going to use Twitter in the first place.
3. Very closely related to this idea about "When large sums of money become toxic", the private equity consolidation in US health care is another ongoing disaster. PE comes in with the promise of "streamlining operations", but instead they are just vampires, cutting stuff to the bone so that the health care system isn't able to respond to spikes in demand (e.g. Covid): https://www.statnews.com/2022/12/14/moodys-private-equity-he...
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.
Irrationally so. That's my point. There isn't a strong indicator that correlates to a company being a craigslist vs a company being a Postman. The median is somewhere in between and its not as dire as you pose it to be.
What's a good OSS alternative that works with iOS and Linux? Anything that's audited? (perhaps that's asking for too much)
Lots of more "modern" password managers (as well as generally other software) kinda suffer from having this weird mixed mobile and desktop interface, inheriting all the downsides of each interface while gaining the advantages of neither. (Not to mention all the issues with porting stuff between two different OSes; Mac and Windows have completely different ideas on what an interface should look like.)
KeePass's official client being windows-only is a blessing in disguise since it means that each client developer can specifically focus on making it look good on whatever specific platform they're targeting.
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.
It's almost like the interests of those who want to get fabulously wealthy -- whether founders or investors -- become misaligned with the interests of the users, even steeper/faster than when you "just" have a "lifestyle business".
Not VC billions, but fuck you money is certainly doable.
How much do you need to take a, say, $130K income for the rest of your life? (Which is still not really enough to live at a wealthy luxury standard). Depends on how old you are and how long you'll live, as well as anticipated rates of investment return. But it's almost definitely more than 2 million.
https://www.thekickassentrepreneur.com/never-have-to-work-ag...
See John Goodman in the Big Lebowski for a full definition.
> But all the established money seeking rent parked at VC firms can't get a cut if you don't play ball with them.
OK, but why does a founder care about that? Either they think their business model can't get them to a sustainable lifestyle business without external capital investment... or they want to get more-than-lifestyle-business wealthy, right?
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.
Customers are members/owners.
Examples: Tessitura, NISC
Is it true that they couldn't sell out though? I imagine if the buyer offered a pile of money then the majority of the owner-workers would go for it, even at the expense of the users.
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.
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.
But once you get into VC funding or acquisitions, businesses tend to want to grow and bloat their products by adding features no one asked for to increase their perceived value. I know I'm tired of seeing this happen to beloved software time and time again.
That being said: it's unclear if anyone really understands how to build an open source product with cloud hosting covering the bills. Almost everyone either makes a deal with the devil (VC funding) or upsells too aggressively anyway.
Cloud storage and CPU usage is basically negligible per-user for a password manager. I imagine you could service hundreds of millions of users on just a couple of capable machines, similar to HN's setup. Even with hundreds of passwords, most users total mere MB's of usage -- it's even simpler than email! I think this is one of the rare cases where corporate users can pay for big accounts with special sharing features and completely subsidize a free product for individual users. Or you could charge individual users $5 a year to cover cloud costs (more than enough), with self-hosting as an option for highly technical users to save a buck.
All of those are true of Bitwarden, except for the non-profit part...
> Or you could charge individual users $5 a year to cover cloud costs
And who pays for the development?? Bitwarden already charges only 10€/year, so they're basically doing exactly what you're proposing, but paying for development with VC money.
Even if servers were literally free (they're far from it!), do you have any idea how many users they'd need to cover just the minimal amount of developers, one business person and either an in-house or external security auditor? And who would pay for all of that during the time it took them to build up that user base??
I hate the VC culture as much as the next guy, but unless the founder is already crazy rich, you need external capital to start up any large decently company - or even a non-profit.
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.
VCs ruin everything.
https://news.ycombinator.com/item?id=34434877
I’m not convinced Bitwarden will go down the drain quite so quickly…
If someone creates new tech and it fits with Bitwarden then I'm more than happy to see what they can do together.
OTOH I wouldn't want to self-host because I know I'm not going to spend the same amount of time and effort a full security staff would, even if my self-hosted box would make a much less attractive target.
It's quite a pickle.
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.
My other concern, which may be unfounded is that Vaultwarden [1], which is an unofficial Rust rewrite, may also be developed to different, or lesser security standards than the official client. However I don't have any real reasons to suspect this.
Note that Synology DSM has built-in Let's Encrypt support
Yes... I tried going down that route. In my scenario, I'm accessing the NAS via its internal IP which is in an RFC1918 subnet. Let's Encrypt insists that you use a globally routable IP. If I used the public IP issed to me by my ISP, then I would have to map a port on my router and expose the NAS directly to the Internet. No way am I doing that.
I bought a cert through Namecheap and got 5 years for $29.95. That seemed quite reasonable to me. There was no problem getting it to work when I mapped the hostname to the NAS's internal IP. The only downside is that I have to go through a renewal process every year and install the updated cert on NAS. Not a huge deal; just one more thing I have to do.
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:
It is now growth at all costs until an eventual acquisition of Bitwarden. So I won't be surprised to see price increases on some plans soon.
[0] https://bitwarden.com/blog/accelerating-value-for-bitwarden-...
I do worry about VC pressure on Bitwarden for hypergrowth. However in my personal opinion, the benefits outweigh the cons (for now).
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).
I did not notice anything, maybe the break happened during the night in Europe. Or the Android app did not want about problems.
Vaultwarden is much easier to set up and manage, I use it myself, and I heard that the official build is a little bit more tedious to go with.
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.
Vaultwarden is a compatible but 3rd party software.
There are decent apps for android and iOS (eg Strongbox)
I’m going to migrate off 1Password to it soon
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.
Some keepass compatible apps even offer full iOS integration (FaceTime unlock, Password AutoFill), so you don't lose these features you're used to with LastPass.
There are multiple users who, post-breach, are checking the Iteration Count the number of PBKDF2 iterations for their vault, and discovering that even though LastPass had been slowly increasing the number of iterations for new customers in line with industry best practices, they were never going back and upgrading the old users. So if you created a LastPass account in the past few years, your iteration count was 100,000. But if you were an older user, it may have only been 5,000. Or 500. Or, in the case of many old users: 1. One iteration. That's all that was protecting their encrypted vault--now in the hands of attackers--from brute forcing.
I can say with certainty that I’ve continued to get value out of 1Password both personally and professionally. I can even say with a degree of certainty that I’ve gotten value out of the changes that have come post-acquisition. Were I starting from scratch, I’d still probably pick 1Password. This isn’t me arguing that 1Password is better. More saying that it’s been a…little bit of time now, and I’m still happy with the product and how it’s improved.
I appreciate that acquisitions or taking on funding feels like more of a kick in the teeth because it’s a distinct event, is publicised, and even publicised as a good thing. Having just gone through my first acquisition (as an employee in an entirely bootstrapped small business) I’ve realised that this has to be weighed up against the risks associated with whatever was in the no-funding no-acquisition future, i.e. the thing just going away entirely, which happens slowly (and then all at once) and mostly in private.
I’ve little doubt that over time 1Password will get comparatively worse than whatever else is around. Either because it’s neglected or because it gets juiced and dark patterned by VC incentives. Ignoring the VC bit, I’m just as sure the same will still happen to Bitwarden obviously. But this shifting playing field just feels like an inevitability regardless of which path any product takes.
No autocomplete on username, slow initial load, search function is sticky on desktop client but not on the rest. No way to easily add folders or reorganise multiple items.
I won't renew my subscription, not that they care anymore
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.
I know my blob is encrypted, because I did it. Did you audit your password manager's source control? No?
That is the difference.
>If
And, if you get infected, it is all moot anyway.
For a technical person I would advise a better solution, but the reason these solutions are being pushed is for widespread adoption of better password practices.