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.)
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.
One of the big challenges to passkeys right now is that they aren’t as versatile as passwords, but this doesn’t have to be the case. Passkeys should be able to be exported and stored anywhere you want (ideally in an open source solution). Bulwark Passkey supports that right now, but I’m glad that other products are also providing solutions to users for the same problem.
Hence FIDO2 and Passkeys feature 'attestation' that allows them to only accept 'trusted' implementations. This accreditation is a crypto process so it can't be faked.
So, you can't just put your keys in any app you wish, like you can with TOTP. There will be strong pressure to just 'go with the flow' eg mainstream OS implementations and us with niche OS or cross platform requirements will be ever more marginalized.
Any complaints will be simply rebuked with "For security reasons" or "We only certify implementation X, Y and Z".
My work is already doing this, they only support Yubikey and one other brand through their Identity Provider, if you have one of the open source tokens you're straight out of luck. Passkeys don't work yet either but I'm sure they will only 'certify' Apple and Microsoft and leave the rest hanging. They love quoting the pareto principle / 80/20 rule as an excuse.
It’s shaping up to be a cool year for password management!
1Password and Dashlane have both announced support for generating/using passkeys via their browser extensions.
It is a good thing that bitwarden is looking at this too.
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.
The tech for password vaults is so simple, I use keepass + icloud syncing and get free end-to-end encrypted password syncing, without sharing any data with anyone.
Outlined in more detail here: https://magoop.substack.com/p/how-to-manage-500-passwords-se...
It's not materially different than storing your KeePass vault in the cloud.
I think one distinction between services like KeePass and 1Password is end user perception of how easy it is for an attacker to acquire an encrypted vault to begin with. For many, they consider a KDBX database sitting in their Dropbox account to be less likely to be stolen than an encrypted vault being held by a company like 1Password, a high value target to the most sophisticated attackers including state actors.
On my devices, keyfiles and a KP client are stored locally. The DB rests in the cloud.
I'd rather use an extremely high entropy master password by itself.
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.
And thats verifiable because their clients are open source.
https://apps.apple.com/us/app/strongbox-password-manager/id8...
Do you have a browser extension that offers username/password autofill using keepass as datasource or do you alttab copypaste / rely on a program made by someone else to clear your clipboard?
If apple gets too greedy with iCloud, you can sync your kdbx with 1000 other clients.
KeepassXC to be specific: https://keepassxc.org/
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.
Folder management in particular seems to have been an afterthought. You create a subfolder by setting its name to its full path in the hierarchy, including all its parents. And thus, in order to rename a folder you have to manually go through every single subfolder and rename the particular parent in its name.
Other annoyances off the top of my head are things like the inability to change the type of a custom field from e.g. text to hidden without deleting it and creating a new field. Or the browser extension forgetting everything you just typed into the new item form (unless you remember to pop out the window) when pasting a generated password on the site you're trying to register to.
After switching from KeepassXC to Bitwarden for its better auto-fill detection and convenient synchronization, I can't help but feel that it's also been a downgrade in more ways than expected.
https://community.bitwarden.com/t/persistent-bitwarden-ui-an...
A recent response to this issue was that "it's a feature, not a bug". I've been waiting to see it added to their roadmap, but it's missing from the 2023 roadmap. So I guess I will have to wait another year
It might be that your search term is a partial of a word. This is fine when searching some fields, but for finding entries with that word in the notes section, the search term needs wildcards. You can read more about it here: https://bitwarden.com/help/searching-vault/
But to paraphrase: "notes: Item's notes. Only full-word matches will be listed unless you use wildcards."
Hope it helps.
1Password does, and is much easier to use (though I use both)
Not sure why the web extension doesn't. Might have something to do with autofilling or adding credentials to HTTP Basic Auth?
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. :-)
[Edit]: An important feature of "Passkeys" is that browsers and operating systems have a special API that allows an app to pre-start a sign in with a known user/email/etc. which if there is a passkey for that user it'll automatically start the FaceID or similar confirmation process. Which Passkeys are checked is controlled by the OS/Password Manager which checks which website is asking and what username it's checking. This is just to make it so it seamlessly logs you in. It does a fall-back to just asking what your user is which is the initial workflow.
This[0] is a good podcast to listen to with Adam Langley from Google about how Chrome supports Passkeys and why they're a good thing. It includes the details of how/where/why there are some proprietary bits needed to implement "Passkeys".
[0]: https://securitycryptographywhatever.buzzsprout.com/1822302/...
FIDO Alliance Press Release https://fidoalliance.org/apple-google-and-microsoft-commit-t...
Chromium Blog on Passkey support (Dec 8, 22) https://blog.chromium.org/2022/12/introducing-passkeys-in-ch...
WebAuthn is the short name for the "FIDO Alliance Web Authentication Protocol".
"Passkey" is the trade name (that Apple tries to own) for the "stuff" that results from using the WebAuthn protocol. At it's root, a passkey is really the private key portion of that "stuff" that is kept. So yes, in practice, a passkey is the result of a WebAuthn implementation.
MS, Apple, and Google don't implement WebAuthn. Companies like mine do. Each website out there that wants to use passkeys needs to employ WebAuthn, whether via build or buy. What the "Big Three" do is leverage their OS's and platforms to enable the storage and migration of passkeys within their eco-system. WebAuthn is implemented in their browsers, and they enable the use of passkeys (which websites make happen via implementing WebAuthn).
One thing to note is that the Big Three also make a small adjustment to the WebAuthn protocol to allow passkeys to shared inside their cloud infrastructure. This every so slightly reduces the security of passkeys (which start out as very, very many orders of magnitude more secure than passwords).
You can read about Passkeys here: https://passage.id/post/a-look-at-passkeys
More on WebAuthn: https://passage.id/post/what-is-webauth
> Here are some guidelines for how to refer to passkeys in your apps and websites. "Passkey" is a generic, user-visible term. This video focuses on Apple's implementation, but as I've just shown you, other major platforms have already started building their own support for passkeys. "Passkey" is also a common noun, like "password." In English, this means it's lowercase and gets pluralized like "password" would. I have a passkey for my account, and I can go to Settings to view all of my accounts with passkeys.
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.
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.
Or are MS+Google+Apple doing an "embrace, extend and extinguish" on webauthn?
Are the "small adjustements that ever so slightly reduces the security" sufficient to effectively kick security keys hardware vendor out of the game?
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.
This page is a good starter:
However passkeys depends on a yet to be published standard for QR codes + bluetooth + websockets for doing WebAuthn from a second device. But that is planned to be published soon.
The developer UX was also pretty bad, ArrayBuffers was a poor design choice for passing around what ultimately becomes JSON.
Yes the spec is horribly complex unfortunately.
In my own project I send the assertion and attestation as multipart/form-data. Which means I can just directly send the ArrayBuffers over the wire.
PublicKeyCredential.prototype.toFormData = function (this: PublicKeyCredential) {
const formData = new FormData()
formData.append('type', this.type)
formData.append('id', this.id)
formData.append('rawId', new Blob([this.rawId]))
switch (this.type) {
case 'webauthn.get':
if (!(this.response instanceof AuthenticatorAssertionResponse)) {
throw new Error('Unknown type')
}
formData.append('response.authenticatorData', new Blob([this.response.authenticatorData]))
formData.append('response.signature', new Blob([this.response.signature]))
formData.append('response.clientDataJSON', new Blob([this.response.clientDataJSON]))
if (this.response.userHandle) {
formData.append('response.userHandle', new Blob([this.response.userHandle]))
}
case 'webauthn.create':
if (!(this.response instanceof AuthenticatorAttestationResponse)) {
throw new Error('Unknown type')
}
formData.append('response.attestationObject', new Blob([this.response.attestationObject]))
formData.append('response.clientDataJSON', new Blob([this.response.clientDataJSON]))
break
default:
throw new Error('Unknown type')
}
return formData
}
async solveChallenge(challenge: Challenge, credential: PublicKeyCredential) {
const formData = credential.toFormData()
await fetch(challenge.location, { method: 'POST', headers: {'content-type':'multipart/form-data'}, body: formData })
}There are SaaS solutions that implement it for you and make it easy to include in your app.
Yes, the spec has improved somewhat but it is still more about describing and exposing individual capabilities rather than serving as an implementers' guide.
There are also usability differences in how the various platforms behave that can be difficult to navigate. In particular, it can be very difficult to restrict which options are presented to a user.
My hope is that efforts like https://passkeys.dev will serve to promote particular broad usability patterns (e.g. primary authentication) and serve to describe the choices and implementation within that context, as well as point people to libraries/products that may help get that experience.
> It seems like hybrid auth with your phone or FIDO gives you sign in, and local could be used for sessions?
by hybrid and local, do you mean the QR code based flow vs some local presented authentication system by the platform?
Generally - no, they are the same in that they both provide authentication in the manner the user chose.
Trying to say one is used for one authentication purpose and the other is used for a different purpose will just cause you to shoot yourself in the foot once they move from their desktop to their phone and the two roles switch.
Instead, there are two main behaviors - passwordless use as a multi-factor system, and use as an additional factor after some other authentication mechanism. These map to discoverable vs non discoverable credentials, and whether you are requesting user verification.
It is typically better to require these broadly and let the user choose whatever they want to use (their phone, their desktop, a security keyfob over NFC). Then, possibly react to their choice with additional checks. Outright rejection of the user choice is really limited to tightly controlled environments (such as enterprises who issue employees security key fobs).
> The developer UX was also pretty bad, ArrayBuffers was a poor design choice for passing around what ultimately becomes JSON.
Yes, its unfortunate - the guidance was that was the proper choice to make in JavaScript API, while it has made people have to build a lot of libraries to shuttle the (non-interoperable) data from their backend servers to the browser due to the lack of binary data types in JSON.
Web Authentication Level 3 proposes additional API to handle serialization of the objects to and from JSON in a browser-consistent manner. I do not yet know of a polyfill for this, but eagerly await seeing one.
Passkeys don't rely on this mechanism (although being able to authenticate your desktop using your cellphone is a very valuable user experience!)
This upcoming mechanism is also meant to be used between platforms (or at least, a platform and an extremely robust authenticator). It is not meant to be used by a website or native application which want to just rely upon/consume credentials. If the browser/platform supports this mechanism, it will be presented to the user as a choice of how to authenticate.
Technically a Passkey is just a multi-device FIDO credential that is compatible with WebAuthn (which is an official W3C and FIDO spec).
However, vendors implementations of Passkeys/FIDO credentials differ quite widely. The Apple implementation of Passkeys, as an example, doesn't provide attestation information which reduces the ability to do device verification. Similarly, even though it's not technically part of Passkeys, Apple removed the possibility to create device-bound WebAuthn keys which significantly weakens the security guarantees you'd normally get with WebAuthn.
Apple's changes do degrade security, but I think it is important to note that even with those degradations, Apple passkeys are still many orders of magnitude more secure than passwords.
Now Google killed U2F in Chrome (and hence Chromium etc.) but you can migrate your webserver to use webauthn instead of U2F and your users' old U2F keys shall keep working.
For the "new" webauthn, called passkeys, which is a modified webauthn: I've got no clue.
It's not clear to me if old hardware security keys shall keep working or if we'll all be forced to use software keys protected by Google/Apple/Microsoft.
The authenticators allow for this registration and proof via generated public key pairs. These key pairs along with other configuration are referred to as Web Authentication Credentials.
There are several modes you can request, such as user verification (perform an additional non-possession factor, such as prompting for a PIN or biometric). You can choose between a model where you challenge authenticators based on previous registration handles, or "ask into the void" if any authenticator thinks there's a valid credential registered for the site. That second mode is called a discoverable credential.
A passkey is a discoverable credentials which supports user verification.
The term isn't trademarked, and just is meant to describe 'a more secure alternative to passwords', but there are a minimal set of features supported. The hope is, like passwords, society will get to a point where we don't have to explain what a passkey is. Support is typically provided by the same software and integration as a password manager.
It doesn't require any capability which was not in Web Authentication Level 2, the prior spec. That said, the platform vendors appear to be taking a much more opinionated idea on how things should be used, and what sort of capabilities (and security posture) should be exposed via the authenticators exposed by their browsers/operating systems.
Most particularly, passkeys are expected to be backup-eligible - e.g. that there is some sort of back-end storage and recovery mechanism. This likely is tied to some sync fabric provided by the platform.
This provides a better user experience in many cases, and reduces the burden on websites to do account recovery (say, if you lose your security key or buy a new cellphone). An authenticator like a Yubikey 5 which supports the other features but does not support backups generates credentials called "single device passkeys" to distinguish this behavior.
Web Authentication Level 3 should eventually expose this backup information to websites, as it is likely a relying party will want to know that the user credential is somewhat 'robust' before they take any sort of migration step like offering to delete any password-based credentials previously used on an account.
In terms of how it is most commonly used - there is significant established usage of WebAuthn, which also supports the functionality of old U2F keys as second factors to a password-based login, such as on sites like Google and Github.
In terms of the 'usernameless and passwordless multi-factor' authentication provided by passkeys, it is expected that the commitment by Apple/Google/Microsoft to support this system will drive adoption, and that it will become the dominant mode of operation. This is all relatively new though - Apple and Google launched toward the end of last year with new backup-capable passkey implementations and new platform-level UX.
That said, the backup eligibility concerns more traditional organizations who are concerned about having Apple/Google/Microsoft clouds as part of their attack surface. The cloud synchronization means that it is debatable whether it meets their needs of considering the phone as a physical factor. And Apple at least offers the ability to 'share' passkeys with contacts over proximity wireless, which interferes with some regulatory requirements. A certain amount of evolution may be needed for them to accept a credential from an authenticator with these characteristics as a sole factor.
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.
Apple already supports Keychain sync with Edge on Windows and I believe that already supports Passkey access.
Also, I believe I heard rumor that "Sign in with Apple" (their existing OpenID Connect account system) will also eventually support helping you enroll non-Apple devices to Passkeys in apps that support both Passkeys and "Sign in with Apple", though I don't know if there is yet a timeframe on that sort of support.
This sounds good, except how would it actually work?
I register in on my iPhone, it uses a key kept on that phone/iCloud. I log in via Safari on MacOS and it works because of iCloud sync.
Now I go to login using Edge on Windows. How can the website find out that I'm the same user as the iPhone/Safari user since I can't sync my key, and I can't enroll my MS Hello ID (or whatever Windows uses) on my Mac or iPhone?
Please correct me if I'm wrong on any of this.
Also wondering if anyone knows why this device [1] doesn't work during the "passwordless" sign-up/sign-in process on dogwarden1.passwordless.dev. Am I going to have to buy yet another hardware key if I want passwordless logins?
I believe the goal for Bitwarden would be the same, to allow for seamless login through a secondary device using WebAuthn and friends. Apple and Google are already working on cross-device FIDO2 login support, but for Firefox I haven't seen much announced as of yet. Bitwarden filling in for Apple's/Google's proprietary services would be a way to log in securely without giving up even more security features to browser companies.
However, I'm curious what y'all think about the cost. A digitalocean droplet for the recommended specs (4 GiB memory) is $24/month. This is hard to stomach when you compare with Bitwarden Premium which is <$1/month. I guess it depends on how much you value your own data.
DO inflates prices for their systems, sometimes I guess it’s worth it but you can get a great dedi with FAR better performance from Hetzner auctions for $32/mo. 64GB RAM, proper CPU, large HDD, could probably host a thousand Vaultwarden instances. Definitely don’t use that for just Vaultwarden, it’s just an example, but yeah.
discussed when it was announced: https://news.ycombinator.com/item?id=31098608
Pedantry aside, yeah that seems expensive given the amount of convenience offered. But much more convenient than setting up a server in your basement with a UPS and external backup drives and such.
It also seems like a way companies like Google would lock people into their browser.
This is also the case for anyone using unique passwords per site, which is the standard for password vault users. Not much of a win there.
> Additionally, private keys are stored on secure storage in client devices (or need to be decrypted themselves using a second factor)
Also exactly the same as password vaults, but we still stress about Lastpass losing their encrypted vault DB.
I agree that Passkeys appear to bring the benefits of Password Vaults to people not currently using them in a fairly easy way. However, I worry about access to those passkeys when access to the Passkey provider is lost/revoked.
The current legal climate is mixed but we have court cases that claim biometrics are not covered by the 4th and 5th. We also have the opposite. The reasoning being that producing biometrics is not testimonial. Until decided by the Supreme Court, I'll assume that anything that can be produced without my mind is not covered and that includes this.
I am not a lawyer and this is not legal advice.
You should be having third one - backup token stored securely in the safe or vault. That is $150 investment just to do it right.
And then - not all webapps allow to register more that one FIDO2 device, which totally cancels the above best practises.
Unlike TOTP, the base case for passkeys is multiple key enrollment so websites are more likely to support it well whereas with TOTP so many implement it as having one-and-only-one TOTP configured. Even when enrolling just a single device that device generally enrolls a small key-chain, not just a single key, because that's how recovery systems work even for using just a single "owner" account. Plus most people use 2 or more devices regularly and Passkey has to work with that. So much more websites in practice should actually support N passkeys where N > 1 (versus half-baked single-option-only TOTP implementations).
At least in theory, in practice we'll see how well Passkey gets implemented at large, there's always lots of ways for companies to get practice wrong.
Are Passkeys exportable and re-importable by another service, site, or system? As described above, if my Google Account is terminated by Google without recourse (which absolutely happens), do I lose access to all sites that I used solely a Google Account Passkey for once my phone stops working?
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.
I’d say we’re going to see polished libraries soon that will abstract all the details away, but services like this may help less experienced developers to quickly get secure auth working.
You have really good newer methods of auth. Instead of selling them as good MFA alternatives security vendors decided to replace passwords because that differentiates them more. But in reality, the layer of defense "what you know" should be complemented not replaced. A reduction in security being sold as a feature is dishonest and harmful.
The threat surface of a passkey based solution is like a small puddle after a rain.
How is there a "reduction" in security here?
I'm not a yubikey expert, but I don't believe that losing your Yubikey will open up your company to a breach.
For a typical passwordless solution, losing your phone isn't a risk, given that no one can reproduce your face or thumbprint.
2FA>1FA
Or more correctly: I got so far but stopped because I prefer to have my keychain locally :)
Currently, if you use an iPhone, you will have the passkey stored in iCloud keychain. Your "account" is a private key held within iCloud keychain, along with some metadata mapping that private key to the site you visited.
Anyway this really needs to be exportable, otherwise its in the ultimate platform lock.
[0] https://github.com/FiloSottile/passage [1] https://passwordstore.org
Granted this is Bitwarden acquiring rather than being acquired, but I still worry it leads to a trend of building "portfolio value" rather than focusing on the product. I sincerely hope I'm wrong.
I do worry about VC pressure on Bitwarden for hypergrowth. However in my personal opinion, the benefits outweigh the cons (for now).
Vaultwarden is much easier to set up and manage, I use it myself, and I heard that the official build is a little bit more tedious to go with.
The MSSQL database seems a bit heavyweight (RAM wise) given the tiny amount of data it needs to host for a handful of users, and isn't acceptable to some people on principle, since it isn't open source.
That experience sent me back to just letting Bitwarden host for me, I know it's all free and I can't expect anything which is fine, but I can't be without my passwords either.
Vaultwarden is a compatible but 3rd party software.
What's a good OSS alternative that works with iOS and Linux? Anything that's audited? (perhaps that's asking for too much)
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.
https://github.com/dani-garcia/vaultwarden
Though I fear it’s only a matter of time before the VC gods demand the client apps remove compatibility and they have to be forked too.
OTOH I wouldn't want to self-host because I know I'm not going to spend the same amount of time and effort a full security staff would, even if my self-hosted box would make a much less attractive target.
It's quite a pickle.
There are decent apps for android and iOS (eg Strongbox)
I’m going to migrate off 1Password to it soon
1Password 8 has greatly improved security architecture compared to the previous versions. Just one example of many: when rendering the item details, the Rust core would not send the password value to the UI layer until the user clicks "Copy" or "Reveal" password.
In addition to that, 1Password 8 has better integration with the operating system that any other version in the past — Touch ID, Windows Hello, Secure Enclave, macOS Accessibility services, etc, etc.
If someone creates new tech and it fits with Bitwarden then I'm more than happy to see what they can do together.
It is now growth at all costs until an eventual acquisition of Bitwarden. So I won't be surprised to see price increases on some plans soon.
[0] https://bitwarden.com/blog/accelerating-value-for-bitwarden-...
I 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.
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.
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
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.
Chrome's password manager is pushing it.
Everything else should be considered malware.
I don't understand how such a 'techy' crowd here on HN can be so belligerent with this security vs convenience trade off.
KeePass locally, gmail yourself an encrypted backup. That's it. FFS.
I know my blob is encrypted, because I did it. Did you audit your password manager's source control? No?
That is the difference.
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.
>If
And, if you get infected, it is all moot anyway.