51–60 of 61 posts
What alternatives do you recommend?
KeepassXC. https://keepassxc.org/ Recently switched over from a premium Bitwarden account to it. Import from Bitwarden was a breeze. Note that KeepassXC only writes to a local encrypted db file. Syncing that across devices is left to you. I used Syncthing for that.
Earlier quoted context omitted.
Notably though, Keepassium from the App Store is licensed differently than the version on GitHub. Only the Keepassium team can ever actually submit to the App Store as GPL software is banned, and so they do not accept contributions so that they have the ability to submit under a proprietary license.
My reading from the License section[1] of the Keepasium README and this Stack Exchange post[2] is that the author of KeePassium wishes to license KeePassium under GPLv3. Accepting applications licensed under GPLv3 would require that Apple provide certain forms of source code alongside App Store downloads which they are unwilling to do. As such the App Store terms of service has terminology stating that you give Apple…
I'm paying for BitWarden because I want to support them. But it's pretty clear that they're backsliding. This is understandable, the password manager market is saturated and implementing new features like Passkeys is far from trivial. Still, they are the only real option for a one-click mostly open source password manager that works across all the major platforms and that supports modern features.
I'm paying for BitWarden because I want to support them. But it's pretty clear that they're backsliding. This is understandable, the password manager market is saturated and implementing new features like Passkeys is far from trivial. Still, they are the only real option for a one-click mostly open source password manager that works across all the major platforms and that supports modern features.
Enpass is supported on all platforms and you can decide how and where you want to store your passwords (local up to cloud infras)
Enpass is open source? Since when?
Earlier quoted context omitted.
I wouldn't trust passkey myself [0] [0]: https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shatt...
I'm using passkeys in BitWarden, and they so far work everywhere, except for the Apple Developer website. That doesn't _have_ a passkey enrollment option, and instead automagically creates it in the keychain somehow. I checked the way they are implemented in BitWarden, and it's straightforward. BTW, the blog is disingenuous. The removal of device attestation from PassKeys was a great boon for compatibility. And the e…
Did they remove attestation? The blog implies they didn't when it says: "a security key ... fail to register ... since the IDP rejected the device attestation." What they removed was a browser API that allowed the IDP to filter the available passkeys, so they could tell the user which of the available keys they would accept before they tried to enrol it.
I gather attestation is rarely used by IDP's. That makes sense - why force a low security web site like a forum to keep a list of acceptable token models. However some sites like banks and my Federal Government absolutely need guarantees on how well the secrets are managed. Without it, they will remain with their current "roll their own" solutions. Providing an API that lets their web page say "no we won't accept your North Korean made phone as an authenticator" seems perfectly reasonable to me. That would be the API that Chrome refused to implement.
I left Bitwarden as soon as they started using dark patterns in their UI. They got in the way instead of enhancing the user experience.
What dark patterns have you observed that I should keep an eye out for?
Earlier quoted context omitted.
I'm using passkeys in BitWarden, and they so far work everywhere, except for the Apple Developer website. That doesn't _have_ a passkey enrollment option, and instead automagically creates it in the keychain somehow. I checked the way they are implemented in BitWarden, and it's straightforward. BTW, the blog is disingenuous. The removal of device attestation from PassKeys was a great boon for compatibility. And the e…
> The removal of device attestation from PassKeys was a great boon for compatibility. Did they remove attestation? The blog implies they didn't when it says: "a security key ... fail to register ... since the IDP rejected the device attestation." What they removed was a browser API that allowed the IDP to filter the available passkeys, so they could tell the user which of the available keys they would accept before t…
Attestation is still in the standard, and some vendors support it.
However, Apple removed it from their Keychain-synced keys: https://x.com/rmondello/status/1545085197250482176 and this effectively means that most sites will be forced to deal with non-device-bound keys.
Banks can still require device-bound keys, just like they do now. But this effectively makes it impossible to sync these keys across devices. You'll have to use the same hardware token every time, and if you lose it, then you have to re-enroll the keys on every site.
Earlier quoted context omitted.
> The removal of device attestation from PassKeys was a great boon for compatibility. Did they remove attestation? The blog implies they didn't when it says: "a security key ... fail to register ... since the IDP rejected the device attestation." What they removed was a browser API that allowed the IDP to filter the available passkeys, so they could tell the user which of the available keys they would accept before t…
> Did they remove attestation? Attestation is still in the standard, and some vendors support it. However, Apple removed it from their Keychain-synced keys: https://x.com/rmondello/status/1545085197250482176 and this effectively means that most sites will be forced to deal with non-device-bound keys. Banks can still require device-bound keys, just like they do now. But this effectively makes it impossible to sync the…
Right. Because a non-device bound key means you are now trusting not just the device, but the management of those keys, how they are moved between devices, and what devices the manager of the keys allows them to be stored on. Some parties are going to better at that management than others. For example you might trust Google but not Bitwarden.
I gather from what you say attestation doesn't of a passkey doesn't include about information about who is managing it. If true, I can just generate my own passkeys, store them in plane text on my laptop and manage them with a home grown shell script and copy them to any device I please. Maybe someone can write a Firefox extension that does all that for me. Have it auto sync between my devices, put a long enough password on it, and I could replace Bitwarden with it.
Them being phishing resistant I guess means they are still an improvement on passwords, but my they are a major compromise on the original WebAuthn vision.
Earlier quoted context omitted.
> Did they remove attestation? Attestation is still in the standard, and some vendors support it. However, Apple removed it from their Keychain-synced keys: https://x.com/rmondello/status/1545085197250482176 and this effectively means that most sites will be forced to deal with non-device-bound keys. Banks can still require device-bound keys, just like they do now. But this effectively makes it impossible to sync the…
> this effectively means that most sites will be forced to deal with non-device-bound keys. Right. Because a non-device bound key means you are now trusting not just the device, but the management of those keys, how they are moved between devices, and what devices the manager of the keys allows them to be stored on. Some parties are going to better at that management than others. For example you might trust Google bu…
That is correct.