Not sure if this is new information or not, but this post mentions that Bitwarden is planning to support passkeys starting in 2023.
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 easy enough (not to belittle efforts that have done so) to store Passkeys in a password manager. The part that kills the flow and where it gets nefarious, though, is whether platform and browser players (Apple/Google/Microsoft/Mozilla) will allow 3rd party Passkey implementations to be selected/configured by the user as their preferred WebAuthN backend so that you can use your 3rd party implementation at login time when the website or app the user is using wants to begin a webauthn flow and lookup or create credentials.
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.
Shameless plug to my own passkey manager, which is 100% open source: https://bulwark.id
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.
The problem is that big companies don't want them to be as versatile. They don't trust us to manage our credentials.
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.
> 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.
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.
I really dislike the idea of giving complete access to my digital life to any company, particularly one that needs to grow quickly.
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.
There's still trust there. You're writing the key to decrypt everything into their web interface if you ever use it (vault.bitwarden.com). If they wanted, they could really get access to everything in your bitwarden vault.
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.
Yes we can degenerate into inordinate amounts of rabbit holes. For 1, you can audit the JS that runs on your browser, it's not hiding (so it's not strictly fair to say that just because you loaded a webpage in your browser from their server it can't be trusted). And anyway, generally, your argument holds for any software interaction ever. GH doesn't have to ship you the repo that you browsed on the web client. A malicious actor could have compromised their infra and be serving fake code in the web UI but have added all sorts of malware to the stuff you download. Apple app store doesn't eve ship you the exact binary the developer uploaded. Scary. At some point you have to decide which threat vectors you actually care about. Give me a scenario and I can tell you how someone can theoretically attack it and why you're not safe. The only thing you can be 100% sure about is manually auditing every single release at the source level and building it yourself.
Well even then you have to make sure your compiler isn’t playing tricks on you. So compile your compiler from source … oh wait.
Then you have your cpu microcode, firmware, security coprocessors.
If you run keepass in a cgroup with no networking (or blocking in/outbound traffic in windows firewall) or extra disk access, your attack vector shrinks considerably. That's not particularly difficult to do, while it is to audit js on every single bitwarden page load
I can't audit their server-side code. Even if it's open source, it's impossible to verify that the software which the server is running is identical to the open source version, or that there's no proxy in between you and the sever which logs the passwords, or some debugger attached which inspects the passwords in memory as people log in.
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.
The proxy would only see encrypted blobs; the client (which afaiui can be compiled and run locally despite using their hosted service) never sees the passwords in clear.
As long as the client and cryptography are uncompromised, the server only gets metadata.
Services like 1Password are often more secure than your solution because they need to harden vaults against full leaks. In the case of 1Password, a secret key in addition to the password ensures that brute forcing is (at the moment) not feasible, even if your password is really crappy.
LastPass would have also led their customers to believe that "brute forcing was not possible" and that they were taking extraordinary measures to keep vaults and data safe.
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.
Doesn't necessarily matter what LastPass "would have also led their customers to believe", the mathematical reality is still that LassPass vaults are crackable in a way that 1P vaults fundamentally are not.
Yes, according to what 1Password is telling us. But as we've seen, what these companies say and what they actually do in practice are not always aligned. And oftentimes customers are inserting a lot of their own assumptions into the mix, not only with respect to vault encryption but vault storage and operational security.
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.
> Yes, according to what 1Password is telling us. But as we've seen, what these companies say and what they actually do in practice are not always aligned.
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.
1Password's client side encryption is occurring within it's proprietary, closed-source product, so I'm not sure how the end to end process can be completely validated.
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?
> 1Password's client side encryption is occurring within it's proprietary, closed-source product
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.
> Yes, absolutely (note I don't actually know how to get the encrypted version of the vault standalone).
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.
9-10 words chosen at random from a list of 10k common words in you native language will get you to 128 bits. Sure not trivial to memorise, but far from impossible.
You're not wrong of course - this would come with heavy UX issues though. E.g. it's hard to type 10 words into a password field without messing up. And _really_ hard on a mobile device.
1P would allow you to have a password like "1234" and still have the same key entropy as that 10 word password alone.
A mobile app could easily facilitate that by storing a "passphrase prefix" (or suffix, etc) using biometrics/device key and requiring users to enter the remainder if you don't trust the device to store the entire thing.
But in the context of a strong master password, the additional benefit of the secret key is of neglible benefit, while the hassle and dangers of having to synchronise the secret key remain.
I'd rather use an extremely high entropy master password by itself.
> And no, because it depends on how users setup and use their AppleID and its passwords/security/devices.
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.
That's not a fair comparison. The differences in LP and 1P encryption approaches have been well known for years, and they are fundamentally different.
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.
So is LastPass, but we users changed our passwords in December anyway as a precaution. Bitwarden is still a central entity that needs to be trusted to manage the zero knowledge platform with competence, e.g. not storing unencrypted metadata in a backup.
Because LastPass is a bad actor that falsely claimed to have a "zero knowledge architecture" that couldn't be compromised if they were hacked, and kept their code secret so nobody could independently assess their implementation, and then proceeded to store critical user data unencrypted, which was promptly hacked and leaked, that means the risks must be identical with Bitwarden, which publishes client and server code in public, so anyone can inspect their implementation.
That specific fault applied to LastPass, I used it as an example of a flaw in a system advertised as zero knowledge, to demonstrate that not all systems are created equal. It is true that BitWarden's Open Source nature helps prevent silly things like that.
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.
Bitwarden can be self-hosted, it's fully open source so you can be safe that way, never giving a single byte to the company.
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?
I kind of want to point out the discrepancy in saying "I get syncing without sharing my data with anyone by sending my password database to Apple". If your argument is that the database is encrypted, how is Bitwarden different?
What this highlights in my humble opinion is that many users seek security signals and are less concerned with the actual security implementation. In the password management space, the signals are "local vault", and "not VC backed", at least on HN. It's quite odd since you'd think people would be more concerned with the application architecture, key derivation, key transport backup and recovery, etc. But it seems security is more synonymous with "company doesn't store my vault on their servers" than it is with "company helps me securely encrypt my passwords".
Slightly offtopic, but I really find the Bitwarden Clients to be lacking in the feature department. I switched to Bitwarden a few month ago and the client has evolved (for me) ever since.
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.
I agree, it's a little weird that some very basic quality of life features are missing from such a popular and relatively mature product.
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.
KeepassXC and/or strongbox have a very similar workflow to the older file based 1password one. I switched from 1password once they went to the centralized subscription model and I have been very happy with it for years now.
I tested Bitwarden recently and found the UX really disappointing. Some basic operations are so counter intuitive that I felt completely lost. This is definitely not the application I would recommend to non tech-savvy people. 1Password has much smoother UX.
Adding on to this. I've watched Bitwarden with interest, but I won't be moving to it anytime soon. Nor can I recommend it to others in good conscience since there's a basic UX issue that makes it easy to accidentally lose generated passwords.
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
> 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
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."
I just switched password managers from LastPass, and Bitwarden's lack of multiple accounts on their browser plugin was a dealbreaker for me. Such a basic feature, especially if they want to get widespread adoption. Otherwise, anyone whose work uses Bitwarden basically can't also use it for their personal stuff without jumping through hoops.
Aren’t you supposed to have your personal Bitwarden account and get work passwords shared to your account? I thought that’s how Bitwarden for organisations worked.
Ideally I'd want to keep my _personal_ personal stuff separate from my "work personal" (ie my personal logins, but the one for work accounts) separate from my shared work stuff. So I'd want two accounts, one for my truly personal accounts, and then one for my work-personal and have the work-shared connected to that.
Lastpass allows you to link your personal-personal account into your work account, so that you can access your personal-personal data while logged into a work account. Work-personal accounts should be stored in a personal folder in your work account, then work-work accounts are in shared folders that cross multiple users.
I forget if LastPass does — 1Password does (though I haven't actually used it in practice, because my work doesn't use 1Password). Idk, maybe it's not actually a problem, but it's how I like to organize things. ::shrug::
I don't know how well this works across business and personal accounts, but you can use "collections" to share passwords between accounts.
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.
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. :-)
Could someone clarify what the relationship between passkeys and WebAuthn is? Is it that Passkey is the Apple, Google, Microsoft implementation (commercialization?) of WebAuthn? If so, does it add anything on top of WebAuthn that makes it differ in some fundamental way? Also, are passkeys how WebAuthn is most commonly actually used in practice? Apologies for the noob questions.
Passkeys is the "normal" name for a FIDO2/WebAuthn credential that basically lives within a phone or password manager. It does add a few things. Namely the ability to store many passkeys per device per app/site, the ability to sync those passkeys (e.g. via iCloud or similar), and the ability to use QR codes and Bluetooth to do a local-only authentication on a device which doesn't have the passkey (which is what often requires some proprietary implementation).
[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".
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).
> 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.
> WebAuthn is the short name for the "FIDO Alliance Web Authentication Protocol".
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)
> 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.
Are Passkeys exportable and re-importable by another service, site, or system?
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.
Passkeys aren't limited to cloud-synced service. Something like an existing Yubikey is also considered to be capable of creating single-device passkeys (e.g. ones which are tied to physical hardware and do not have recovery capabilities).
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.
Okay, can they block access to those keys and/or the the backups of them? Assume that my account is terminated or that it's compromised to the degree that I cannot re-claim access to it. Can I move those keys to my new device/system without the cooperation of Google/Apple/MS?
They cannot block access. The passkeys are actually stored on your devices in a Trusted Platform Module. When moved to the cloud, they are E2E encrypted, and the transferring platform has zero knowledge of your keys.
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.
> Do old Yubikeys and similar U2F devices, which do still work for webauthn, still work for sites that a going to require a "passkey"?
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.
Passkeys are effectively software security keys, stored in whatever keychain you're using (Chrome or iCloud Keychain or otherwise); for the major implementations you're hearing about, the goal of their implementation is improving the UX by syncing your passkeys between devices, so as long as you can access your passkey keychain, you won't have to worry about losing your security key for that website.
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.
Firefox should have a platform entitlement that lets them just delegate to Apple's implementation when available. This is I believe what they do on Windows.
Yeah but only being about to login to something if you’re on a certain ecosystem is horrible lock in. It’s why I always choose email sign in over Apple.
The standard has portability mechanisms, both for ad hoc authentication across ecosystems (I logged into login.gov yesterday on Chrome browser using my iPhone passkey) as well as exporting passkeys to ecosystem independent vaulting systems.
It makes sense to approach this new paradigm with a healthy dose of skepticism, but there is evidence your concerns have solutions.
Passkeys is what Apple decided to call their implementation and the benefits are within their ecosystem, such as storing these in your Keychain to be used on multiple devices.
it's just WebAuthn with an easier to understand name.
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.
Just recently tried to add WebAuthn to an app and was shocked at how complicated the spec is and how quirky the implementation ends up being. The biggest thing I couldn't easily figure out is how to use it properly. It seems like hybrid auth with your phone or FIDO gives you sign in, and local could be used for sessions? It's hard to make heads or tails from it.
The developer UX was also pretty bad, ArrayBuffers was a poor design choice for passing around what ultimately becomes JSON.
> Just recently tried to add WebAuthn to an app and was shocked at how complicated the spec is and how quirky the implementation ends up being.
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.
A passkey is just web authentication credential registered to have certain pre-existing capabilities so that you can have a particular user experience.
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.
We wrote a long post on Passkeys, in particular how they are implemented by Apple[0] that might be interesting.
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.
That's a great article, thanks. In fact, it's a fantastic article. I read it a couple of weeks ago, and learned a lot. Thanks.
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.
Thank you! 100% agree - realistically, given their scale, the tradeoff made sense. The UI would have been fairly un-intuitive for users had they left the option to do both device-bound keys and passkeys.
Can't help much but originally webauthn came from Fido2 and old Fido devices, like old yubikeys, which only supported U2F, were de facto compatible with webauthn (as in: webauthn was only an upgrade server side).
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.
Web Authentication works by having devices that provide authentication factors (authenticators), and providing APIs to register some authenticator with a website, or prove presence of a previous authenticator.
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.
Would have preferred to see the cash used for this to be used for things like app QoL improvements, an actual code audit (not just the basic network security assessments they list), or offer actual bounties for their bug 'bounty' program.
Wow this is really cool. I just tried the example on the homepage, that's magic! No email, username or password. Can someone explain what is happening?
On iOS this seems to use the iCloud Keychain which is slick but how would I then login to sites using Firefox or any computer that doesn’t have access to my keychain? The reason I use a 3rd party manager is precisely this reason.
Typically for web authentication the websites rely on the browsers which by default will back into the platform.
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.
Sites should likely let you enroll multiple such passkeys from different vendors (add a Microsoft Account passkey from your PC, a Google one from your Chromebook, etc).
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.
> Sites should likely let you enroll multiple such passkeys from different vendors (add a Microsoft Account passkey from your PC, a Google one from your Chromebook, etc).
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?
There is a cross-device system to sign in, using QR and proximity checks.
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).
A new private-public key pair is generated, the public key is your user identifier (sort of), and the private key is stored on your device (browser or phone). You're logging in by proving you have the private key for the associated public key. I think the device may also be storing a mapping from key to service or something? Not sure.
From my loose skim, this seems to be more for UX than anything else: no-clicks account creation and no-clicks login, but there's still account creation and login happening, presumably with a key provided by BitWarden. But websites can start removing the login prompt as an entity to be interacted with.
Anyone know how Bitwarden fits into the "passwordless" equation here? I tried to log in to Dogwarden (shown in the video demo on passwordless.dev), but the Bitwarden extension/app doesn't seem to do anything during sign-up.
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?
My current setup uses Krypt.co (deprecated) to forward most U2F/FIDO2 requests to an app on my phone. The app has some keys stored in my phone's secure secret storage and verifies/signs the request (after unlocking my phone with biometrics or my phone's PIN). This signed response is then used to log into the website.
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.
Highly recommend using Vaultwarden, API compatible OSS server. It even provides premium features like TOTP for saved sites. I could host it on a small $12/yr VPS but currently host it on a home server. Minimum specs are very low for it as it’s written in Rust.
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.
You can run the open source VaultWarden server (https://github.com/dani-garcia/vaultwarden) on way slower hardware. It takes a while for the project to catch up in terms of API support compared to the official server, but it's great for self hosting.
Aside from the highly relevant cost observations of the sibling comments, one will want to be cognizant of the ... very strange .. opsec that installer uses. It's a lot of curl into bash, self-updating things, url shorteners, and :latest tags
It makes me think (dangerous, I know) ... I find it odd to use the term "self host" when referring to a third-party cloud. It's someone else's servers and network and electric bill, after all.
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.
Self hosting is a scale. But the point is you have the ability to host it how you want. Whether that be on a cloud service that you just throw a docker container at, to a VPS with root, to a bare metal machine co-hosted, to in your basement, the choice is yours.
I’m highly skeptical of Passkeys/Webauthn as it would seem to not have the same legal protections that a password has in the US. Maybe this is me becoming a conspiracy theorist.
I’m in the same boat. Using Passkeys gives the user less control. The last thing I need is another layer of complexity when dealing with credentials. This seems like a solution created for people too lazy to generate and track secure secrets (using a password manager).
It also seems like a way companies like Google would lock people into their browser.
Well, passkeys come with another very interesting property: they make it entirely useless to obtain the database of user credentials from services. It only contains public keys specific to a single service, so you cannot use them anywhere else. Additionally, private keys are stored on secure storage in client devices (or need to be decrypted themselves using a second factor), so there’s pretty much 0% risk of mass credential leakage.
> they make it entirely useless to obtain the database of user credentials from services. It only contains public keys specific to a single service, so you cannot use them anywhere else.
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.
No, you misunderstood me. Passkeys remove the incentive to attack auth infrastructure in the first place, because a database of WebAuthn credentials isn’t useful to criminals compared to a database full of password hashes. This isn’t about the handful of tech-savvy users who know how to protect their privacy anyway, but all the others which constantly reuse their insecure passwords and won’t use password managers.
This is conspiracy theorist talk until it isn't and that date will be not long after this is more commonly used. (I think this is a rational concern, btw)
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 like where passwordless.dev is going. However, I don't think I'd like to build a business on top of that. Is there a similar implementation that's open-source that doesn't depend on a third party?
The idea of FIDO2 with HW tokens is great, but not practical if you don't own atleast 2 pieces:
- one constantly inserted into main working machine
- second somewhere with the keys, ready to be used on other devices
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.
Interesting demo. What happens though if the device holding the private key is lost? Or Apple decides to shut down your iCloud? Is there a backup option, similar to backup codes for OTP?
Just like TOTP (used for most 2FA) the best practice for websites accepting passkeys will be to support as many passkeys as you wish to enroll. So you could enroll into your account some device associated with your Apple ID and some device associated with your Microsoft Account and some device associated with your Google Account and some browser associated with your Firefox Account and use any of those for recovery.
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.
Best practice is unlikely to help here, as people just aren't going to register passkeys from multiple services unless it happens automatically. I might bother to enroll multiple passkeys for my bank, but I'm unlikely to do it often.
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?
It should start to happen automatically. Apple, Google, and Microsoft have all stated the goal that they are hoping for deep inter-operation across all of a user's devices, regardless of ecosystem.
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.)
> It should start to happen automatically. Apple, Google, and Microsoft have all stated the goal that they are hoping for deep inter-operation across all of a user's devices, regardless of ecosystem.
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.
> 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.
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.
Thanks for your comments, and I think I see the ambition of the project. We'll see how far it goes. I hope that the powers that be in this space see the risks they're creating, recognize that they are increasing the blast radius of account loss, and take some efforts to mitigate them.
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.
This is an unrelated question, so I'm putting it in a different thread.
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?
Very good questions and I've been wondering that some myself. I imagine of the Big 3 Microsoft is likely the one to have been thinking about this the most. With Microsoft no longer having a smartphone ecosystem of their own, they will likely have to support both Apple and Android devices and they probably also need to have more answers for the "neither" scenarios as well (de-Googled Android users still sometimes have Windows PCs, for instance; Windows users are said to include a larger share of older "dumb phone" generations; etc). Also, most of those access stations themselves are generally Windows PCs for the intersection of cheapest available hardware and lowest common denominator software. (Though I've heard Chrome OS is shifting that in some places.)
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.
I wonder how iCloud shutdown would affect this route, but: your Passkeys are synced to your devices locally, and the whole "scan QR code on another device with your phone to authenticate" flow is fully local, utilizing key authentication over BLE.
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)
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.
Probably the same thing that happens when you forget your password. Hit the "forgot your password" link, get a confirmation email, create a new passkey
This seems a bit odd to me - is setting up WebAuthn in your main backend so hard that an external service like this for validating credentials is required?
Quoting the docs: it’s “WebAuthn - without reading the w3c spec”. So apparently yes. It does seem very silly that this has to be a third party service instead of open source code you just plug in to Rails or whatever. I guess they had to find some way to get paid for all the expertise they accumulated. Stuff running on external servers is the way tech companies as a whole have decided to remunerate work like that, and now everything looks like a nail. I note that since logging in is such a crucial part of online business, running consulting around open source software would appear to be a a good model. That’s what the people behind the C# OAuth2/OpenID code known as IdentityServer do.
I recently implemented WebAuthn for a toy project, and while it took a bit to wrap my head around the details, it’s fairly straightforward if you know the problem domain a bit.
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.
Passwordless as a concept needs to die along with biometric auth.
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.
Doesn't work that way. Passwords are inferior but still a strong layer of defense. You are putting all your eggs in one basket again. The lesson from passwords is that a single factor of authentication is inherently inferior to multiple factors of authentication. From a threat actor's perspective, even a yubikey is a matter of one well planned attack (physical, compromised host,etc) and by nature newer factors of auth don't get treated with hostility like with passwords. They are better than passwords but what I see is people moving away from MFA to only a yubikey for example. Like you are now one lost yubikey away from your whole company getting owned lol.
Your face and thumbprint can easily be reproduced. There is even a guy that took a photo of a politicians' finger from a mile away and used that to forge their fingerprint. Even without going technical your dopplegangers can bypass face auth lol. You can guess spray pins and push notification codes. The one thing you can count on is someone will find a way around any good passwordless solution. For example, there is a "rdp in browser" phishing where a browser in the attackers vm does the actual auth but the user thinks it is in their browser so most passwordless methods are defeated by cookie theft like that.
They are pointing out that while the "something you have" factor may be stronger than "something you know", multi factor is still better. I agree. Also, passwords are decentralized, whereas passwordless puts the power into fewer hands, so this too reduces complexity for attackers.
The demo on the homepage is available only on chrome. I tried both safari and firefox on macos and I can't see the " Experience Passwordless.dev in action" link there.
I still don't understand how it works.
I went into the website under authenticated using my phones API, where is my account now?
There is nothing in my Bitwarden vault.
Passkeys are stored on your platform keychain. In time, Bitwarden will offer this interface up, so you can sync them through your Bitwarden vault.
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.
I’ve been using the keepass ecosystem for years after switching from 1password. It’s open source, highly portable, and you don’t need a degree to set it up.
Yes, but password sharing in a team is no fun. You could use a completely separated password file, but then you might end up with a lot of password files with different passwords that need to be managed in another Keepass file. In theory there are child databases in Keepass, but using them with different clients and cloud sync never worked for me.
Sounds a bit worrisome to me…
Maybe I'm just overly cautious,
but i guess it's time to look around again.
Has anybody checked out APass yet?
https://github.com/balu-/a-pass
Without looking close at your suggestion, you might want to look at passage [0] by the creator of age. It's a fork of pass [1] using age as the backend.
For my personal passwords and general secure info (it can store notes, files, and TOTP as well), KeePass(XC/DX) has been my password manager of choice. Nothing leaves your device. If you want it to, that's considered out-of-scope, and you have to handle syncing yourself. Whether that be something like Nextcloud, or my personal favorite: Syncthing.
Magic links via email? Email isn't a secure transport, or storage. I think that's only viable for low risk systems. Even software like Slack, which supports magic links via email, will also support username/password/MFA as an option for folks who need better security.
As a recent convert to Bitwarden from LastPass, I start to get a bit nervous when I see acquisitions happening. LastPass getting acquired was the beginning of the end for it, IMO, before stagnating into criminal negligence.
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.
A good note for bitwarden is that it has a self hosting open source version, vaultwarden that is easy to switch to: https://github.com/dani-garcia/vaultwarden I see this as downside protection, as I can quickly migrate if I disagree with bitwarden's direction with minimal changes to my clients.
I do worry about VC pressure on Bitwarden for hypergrowth. However in my personal opinion, the benefits outweigh the cons (for now).
The official server is distributed as docker containers, with a shell script to manage them, and is quite simple to setup and maintain. I could see how trying to deploy it yourself outside of docker could be an undertaking though.
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.
It's easier to manage until it breaks as the recent example last month when Bitwarden updated their client and Vaultwarden had to play catch up and reverse engineer the changes.
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.
To add onto this, if you care about supply chain attacks, bitwarden mobile supports Fdroid builds (albeit not part of the main repo because they rely on xamarin) so you can host your own fdroid repo and run your own builds if so desired.
I think they meant if they don't like the direction that the Android client takes, i.e. they stop allowing you to change the backend url for example in which case, yes you would need to fork or rewrite it
It's fragile if you do that. Bitwarden updated their API last month on the clients so you couldn't connect to Vaultwarden at all until the Vaultwarden team could reverse engineer the change and produce a new release.
In my case I could continue to use the app, it broke the ability to sign into the vault. If you only lock your vault and not fully logout you may not have noticed it.
Thanks. I do not even lock BW, not to mention logging out, and almost never connect to the vault via the web interface - so yes I must have simply missed it.
Sorry probably not the best wording. If Bitwarden changes their API the Vaultwarden team has to act fast enough to get the same changes into the Rust version before Bitwarden updates the clients. In one case they weren't fast enough https://github.com/dani-garcia/vaultwarden/issues/3082
If dev support from the company fades, the UI will start to deteriorate - and wether you are hosting or not, that is also a thing that matters. Like mobile apps, browser plugins, form filling logics and specific site behaviours etc.
Ah for fuck's sake. It keeps happening to all the software I love. I guess I'll have to stop relying on convenience (I was a 1Password user years ago) and go 100% open-source. None of the libre offerings seem to be as convenient and polished, but at least they're not into some VC's pocket ready to squeeze as much profit as possible out of my paid membership.
What's a good OSS alternative that works with iOS and Linux? Anything that's audited? (perhaps that's asking for too much)
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.
The entire finance industry has a disdain for "lifestyle businesses", that just generate enough profits for the founders and employees to live on, but will never generate an exit beyond that. I get why, but for utility products, a solid lifestyle for the employees and a useful product for users is enough, and should be enough.
And can be enough if you don't need large quantities of investment capital. If you don't _need_ it, but _want_ it to get fabulously wealthy... well, "lifestyle business" is not the path to that, by definition.
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".
The thing is, founders can get fabulously wealthy with a lifestyle business or at least very wealthy, but it might take longer. But all the established money seeking rent parked at VC firms can't get a cut if you don't play ball with them.
> 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?
I'm sure that's what they think. I don't know if the data really indicates that going to VC route will make you richer. It could certainly make you more publicly successful.
I don't know if a couple million is "fuck you" money in 2023 (enough to never work again and eventually retire while living a fairly luxurious lifestyle?), but point taken.
I can say "fuck you" with no money at all, since I can still talk for free!
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.
FU money has nothing to do with living a wealthy lifestyle. It's having all your basic needs taken care of so you don't have to do things you don't want to do to earn money.
See John Goodman in the Big Lebowski for a full definition.
Lifestyle businesses have a big flaw in American culture though; our safety net is not enough to make "meets expenses" a tenable long-term approach. We basically have to aim for a big wad of savings for later in life, which incentivizes going for exits and cash-outs.
VueScan (hamrick.com) is a very good example of a successful lifestyle business (first release in 1998). The founder and his son work on the product full-time. I don't think they have any other staff, but I could be wrong.
Perhaps, I would hope that a sustainable lifestyle business would be able to pay employees and founders enough to build a comfortable retirement nest egg through savings, investments, and compound interest.
I feel so happy that we have created "billion dollar global platforms" instead of universal healthcare or ensuring everyone was sleeping indoors. Woo-hoo!
You can definitely say that here. To me the problem isn't exactly VCs, it's the expectation of rapid, open-ended growth that ruins good products and companies. Of course, the driver for that is often VCs, but it can come from other places too.
Upvote for keepassxc. I've been using it and its predecessor with the same database file for something like 15 years and have seen many of these services come and go in the meantime. It will outlive Bitwarden for sure.
In your opinion, what would the ideal password management business model be? A non-profit like Signal? (Not rhetorical, actually curious what people want here.)
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.
I'm not sure if there is a good business model in password management. I can't answer that question. What I do know is, a good password manager is the type of software that should strive to be feature complete. And at that point resources should be used for maintenance, security, and software/OS compatibility updates. In other words, a low-if-any growth, but profitable business assuming the software is good.
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.
Non-profit like Signal that sells cloud hosting to pay the bills, standard protocol with self-hosting option for the server like email/browsers agreed upon decades ago, anyone can create an interoperable desktop/browser/mobile client. Fully encrypted such that even the non-profit doesn't have the decryption keys.
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.
> sells cloud hosting to pay the bills, standard protocol with self-hosting option for the server like email/browsers agreed upon decades ago, anyone can create an interoperable desktop/browser/mobile client. Fully encrypted such that even the non-profit doesn't have the decryption keys
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.
Another advantage to KeePass is that there's about half a million clients and most are actually written to be used for their platforms.
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 use cloud storage to store the kdbx file and sync it across a PC and my phone. It’s pretty awesome 99% of the time and just works. Once in a while you get a merge conflict and it’s not so good.
Even merge conflicts have been a lot better for me in recent years. My only worry with KeePass is that I have to rely on potentially sketchy client applications but I'm also fortunate enough to have the skills to make my own if I really felt the need. It's one of the few "not-my-solution" pieces of software which continually gives me a sense of data ownership.
I love Bitwarden. I've been a customer for years. Great product. Great team. However, I recently quit for this exact reason (evil VC influence), and migrated all of my secrets to KeePass. Yes, a slight inconvenience to manually sync across devices, but I sleep better at night knowing my secrets are no longer in the hands of some VC suit.
If a simple git-based CLI solution is appealing to you, then try https://www.passwordstore.org/. I wouldn't recommend it someone non-technical, but personally, I've never looked back.
There are iOS and Android clients, too. Not especially polished, but they do the job.
Love passwordstore, been using it for almost 6 years with zero issues while watching my friends run frantically from one compromised or greedy password manager to another.
As mentioned in other comments, BitWarden has both OSS client and server implementations. You can keep using it and if something goes wrong (or earlier, if you wish) you can always run it yourself.
I haven't seen, but would love to, a tech startup that is guaranteed not to sell out. I don't mean a promise from the founder on a blog, but a legal structure. I'm not sure what what form this would take or if it's such anathema that it could never be but it would be great to see.
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.
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.
Interesting how your list focuses on worker-owned cooperatives. I had mostly thought about customer-owned cooperatives up until this point. Most of my exposure is with customer-owned ones, perhaps due to living in an agricultural area (grain elevator co-ops, fuel co-ops, rural electric co-ops, rural broadband co-ops). And working for one!
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.
bitwarden is opensource. you can self host. the apps in the store are compatible with the self hosted options just change the url to your server. you can also fork any of the projects and build it yourself if you don't trust them.
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.
It comes from a concern that VC backed investments demand a constant level of revenue growth, causing a company to add features or integrations that do not improve the base product. Organic growth is usually insufficient for stockholders, whose demands become a priority over stakeholders.
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.
This does not stem from VC but from the “C” itself - capital. In order to function in capitalism, production must facilitate the creation of surplus value that can then be appropriated. Over time, with the tendency of the rate of profit to fall and with inflation of prices, you will see a race to the bottom.
The issue is that there are a large number of products/companies (I think the vast, vast majority) whose addressable market size isn't that big, but when they take VC money they do all types of unnatural things to try to grow instead of focusing on the couple things they were really good at. Couple cases in point:
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...
craigslist famously rejected taking outside money for years.
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.
> 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.
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.
Or it could be that the probability of having to do anti user things to earn an ROI for a $100M investment into a password manager is too high.
$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.
My guess is they will follow 1Password and have more strategies to monetize users. I wonder what the difference between the two services will be at the end of the day.
1Password in my experience was the biggest scum of bait and switch I ever faced.
They used to do "lifetime" licenses which I bought into, but wouldn't support it beyond one year of release and stop giving me updates.
Later, they invested heavily into the cloud side of things, and brought in confusing subscription-based pricing which made it expensive and difficult to understand. All they're doing as of now is trying to increase prices and tear into your pockets.
With BW I have never expected the same and I am still hopeful on giving them the benefit of doubt.
1Password NEVER had lifetime licenses. We made this decision since day one because we had a product before that died because it was a "lifetime" purchase. The 1Password license is valid for the major version of the app. The license purchased would still work with that version today. If you look at the release history of 1Password apps — every version had a ton of updates made long after the app was no longer on sale. For example, 1Password 7 was updated just a month ago: https://app-updates.agilebits.com/product_history/OPM7
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.
They did? Oh JFC I just switched from 1Password to avoid using a VC backed service. At least there's always Vaultwarden, now all I need is a service I can pay to host an instance for me. ...and to not take VC funding.
I switched from 1Password to Bitwarden, imported my vault, and then realized that their client doesn’t even support drag ‘n drop.
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.
Bitwarden is the first password manager I ever used. Where would it use drag and drop and for what? I wish it would be better controllable vie keyboard-only. That is, when you use the Firefox add on and tab out of the Bitwarden popup and tab back in again it remembers the focus on e.g. the copy password button, you just have to hit space again and tab back to the terminal window where you need to use the password. But Brave doesn't remember the focus so annoyingly I have to grab the mouse.
In 1Password there's at least a half dozen ways that drag and drop could be used:
- 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.
You must be on mac, because my 1pw experience is horrible on Linux. Edit a password in the browserextention opens an new tab in n which i have to login all again. Ugh. Bitwarden at least doesn't do that. Drag and drop? Nope.
I use 1Password on Linux and this isn't my experience.
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.
Technically it does the same thing on Mac, it opens the Mac app. But on a Mac there's universal unlock, so if you have the extension unlocked, the app will unlock, so it opens the item you want to edit in edit mode.
If you don't have the app installed it opens the website in a tab to signin and edit.
I did try to switch a year or so ago and got really frustrated. Tried again a week ago and Bitwarden does seem a little better. It helps that it feels like 1Password's app has been getting more bloated over time (though I have no data to support that assertion).
I have no interest in those things, they're good examples of what I don't want in my password manager.
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.
Fair enough, everyone has their own requirements. I'd argue that all modern operating systems have password management already built-in.
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.
I refuse to use a cloud-based password manager, they will all be hacked eventually. I will continue to use and pay for the standalone 1Password as long as possible, and then be forced to self-host vaultwarden.
Doesn’t necessarily mean change will come to the current offering; acquisitions can happen because new or enhancing existing product lines (like enterprise) are in the future.
This is true, but LastPass proved that by the time the worst case occurs it's already too late. A security breach means, at minimum, redoing all your passwords, and these sites are a very compelling target.
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.
You have security options self hosting that a big host does not.
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.
Does bitwarden work if server is offline? I know the client works without internet connection but server outage had an issue earlier last year https://news.ycombinator.com/item?id=32782386
I self-host Vaultwarden. I'm sure someone will be happy to explain to me how foolish my implementation is, but I'm comfortable with it from a security perspective.
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.
I have a very similar self-hosted Vaultwarden set up, for the same reasons.
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.
Agreed. I know I'm taking it on faith that this implementation is robust and secure when it might not be. However, I feel okay about it knowing that it would be very difficult for anyone other than me to access this Docker instance in the first place. And if I'm outside my home network, I'm interacting with it via the VPN.
> 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.
That all makes sense. Wanted to point out to others that there's potentially less of a hassle to set this up (if you're fine with opening port 80, as has been pointed out to me).
Unfortunately, HTTP challenge only. I.e. you have to open port 80 to your Synology, which is handled by the same nginx instance, as all the other services on the device.
> A security breach means, at minimum, redoing all your passwords
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:
So too have some clients (e.g. rbw CLI). So just need an independent browser extension and then my use of Bitwarden does not need Bitwarden LLC (and the browser extension is not great, so that's not a high bar)
I’d bet on KeePass 2 longer term. KeepPassCX has been around 10 years (forked from a project started 8 years before that). Actively developed, cross platform.
There are decent apps for android and iOS (eg Strongbox)
Bingo, me too. I like that keepass is file based so I can use any storage medium to make multiple layers of security to access the vault. Even if cloud providers have access to the file or my cloud storage account gets hacked they still have to crack the file to get the passowrds. Also I have been using strongbox pro for a few years now and been very happy, in fact I like it better than what 1password used to be. Worth every penny. KeepassXC has also been great.
I've been considering a switch from 1Password to KeepassXC myself, but the last time I tried it, I couldn't find if KeepassXC has some equivalent to the "quick access" feature of 1Password.[0] In short, a way to open a small window, search for a service name or URL, and then quickly copy username, password, or a TOTP code. As far as I could tell, I had to open the entire KeepassXC app every time to find something. Has this changed, or did I miss something somehow?
The "containerized web app" is not a correct description here. 1Password 8 on macOS, Windows, and Linux is a full-fledged desktop app. It is built in Rust with Electron/React providing the UI. It can work completely offline and does not require a network connection.
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.
Electron providing the UI is exactly what most people are referring to when they say "containerized web app", only because this paradigm of split backend for electron apps is less common.
Like docker? They made huge profits but docker itself has made practically no improvements. It's still using iptables when many distros switches to nftables causing a huge mess and the documentation is still really poor.
I'd like to remind you that Bitwarden is becoming completely VC backed with the way it is going [0] and there is always a possibility that it can be acquired to give investors a return. The same happened with Keybase as soon as they took VC cash.
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.
I’ve never used Bitwarden, but I’ve used LastPass in the past, and I’ve used 1Password for ages. AgileBits took on a big chunk of VC some time ago. This upset a bunch of people, too. Slightly different circumstances due to the different user base and source availability, but whatever.
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.
I know this dead horse has probably been beaten beyond recognition, but I think the safest option that still preserves some convenience for password management is to stick a keepass database in your cloud storage provider (icloud/dropbox/whatever).
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.
Honestly since I bought bitwarden premium two years ago, there hasn't been a single relevant improvement to the client. It is basically not getting any UX love.
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
The concern with Bitwarden started a few months back when they did a round of venture capital funding. Now, they have to turn profits instead of just being great.
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.
This push is because there's a lot of people using weak, reused passwords out there, who are not willing (or capable in cases) of a self-managing a password manager. For the people in my life in this position, I would much rather them use lastpass or bitwarden or anything over continuing their current practice. The risk of a lost password from one of those services is much lower than of them getting hit by password stuffing or getting a password brute-forced.
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.
Keeping your passwords on your device (and also in Gmail?) might work for you, but a password store that I can't conveniently access from both my computer and phone isn't useful to me, and I suspect, many others.
If the key to decrypt the vault never leaves your device, then the security implications are minimal. Well worth the convenience in my eyes, and many others apparently.
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.)