[hannofcart]

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.

[yaomtc]

Bad news there. https://forum.syncthing.net/t/discontinuing-syncthing-androi...

[miloignis]

I've used this long-running fork and been pleased, and it's on F-Droid. https://github.com/Catfriend1/syncthing-android

[lordofgibbons]

> Syncing that across devices is left to you. I used Syncthing for that.

So it doesn't really solve my problem

[LinAGKar]

That works fine for a single user, but it doesn't work for sharing secrets between multiple users

[godelski]

I think the thing we need to learn about security is that usability matters.

I think this is easy for pretty much anyone that's an active HN user, but is it for your parents or grandparents? It's they who matter a lot. It's why WhatsApp was so successful, it passed the Grandma check. Signal might, but onboarding is "hard" (and the nerds argue and that's all others hear and then do what... Use telegram? Lol). But it's why Matrix isn't gaining popularity, because frankly until creating servers is a one click install it's not going to get mass appeal (same for any federated app).

It's the old PGP joke: how do you decrypt a PGP email? You email the sender "I can't decrypt, can you send it without encryption?"

[ValentineC]

> Signal might, but onboarding is "hard" (and the nerds argue and that's all others hear and then do what... Use telegram? Lol).

I refuse to use Signal because their message history functionality is too restrictive for me.

Telegram strikes a good balance, and wins at the UI/UX game.

[godelski]

  > message history functionality is too restrictive for me.

At least a way you can get around this is to do the backing up by desktop. I'm assuming you're on an iPhone because Android supports backup.

If you are Android, see Molly: https://github.com/mollyim/mollyim-android

  > Telegram strikes a good balance, and wins at the UI/UX game.

Telegram gets the "lol" because it's not default E2EE. They advertise themselves as E2EE but most people are not using this feature because it's opt in. If you're going to seriously position yourself as a security app, the defaults have to be secure. It's the bare minimum.

And E2EE isn't even available for group chats... WhatsApp is more secure (telegram also gathers metadata)...

I do think signal has stagnated while there are many things that could really be improved, including low hanging fruit like just being able to search for stickers (people do in fact care). But for the most part, I'm not sure there's anything major missing. It seems like we're willing to pay high costs to avoid small thorns. But I guess it's better to have a rock on your shoulders than a needle in your finger.

[ValentineC]

> Telegram gets the "lol" because it's not default E2EE.

I use Telegram mostly for group chats, pretty much as an IRC replacement. I think that's where it really shines. :)

Agreed that even WhatsApp is more secure, but if I remember correctly, they do not promise that metadata is E2EE (if that's even possible), and Meta harvests that.

[godelski]

But just to be clear, telegram is not a privacy nor security app. It's just a communication app. It's fine that you use it, but just making sure you aren't calling an orange an apple (eat whatever fruit you want, I'm not a cop).

  > they do not promise that metadata is E2EE (if that's even possible), 

Sure it's possible. Signal does do this as well as many VPNs, things like encrypted DNS, tailscale and so on.

It's important to remember that it's also not binary. There's a whole range of metadata is. You can leave a footprint that's a very clear image of your shoe or you can leave a footprint that's a smudge that's only approximately in the size of your shoe. If you're concerned then the difference matters a lot.

While you won't leave zero trace the aforementioned apps (like signal and mullvad) do minimize the collection to the point where it isn't very useful. I mean it's metadata that you're a person, but that's not going to be helpful to identify you. Even knowing your gender probably won't but metadata's power is in it's accumulation.

[hannofcart]

This is fair, though in my answer, I wasn't answering the question from the perspective of applicability for a general audience.

For a general audience, even Bitwarden doesn't pass the "grandma check". If you've used Bitwarden for a while you have probably been met with a stern warning about "KDF Iterations too low".

So I pitched the answer assuming "able to use Bitwarden" as a base level of tech savvy.

Also, seeing as I am on HN, I assumed the following:

1. Security matters, even if it comes at a slight cost in convenience

2. User can figure out their own syncing mechanism

[godelski]

That's totally fair and I actually do agree.

I'm willing to give up convenience for security. But I do like to stress that we should try to have both as much as possible. It's a thing that is often forgotten and many times matters.

I'd definitely agree that it's not a big issue here, as password managers are more personal, though my general frustration is with things like communication where I need the other person to also be willing to make the same compromises. Though back with password managers, I do need things that at least pass the parent test (retiree but not old folks home) because their information leakage leads to my leakage regardless of my actions. So I still do think it's worth turning up the heat to push things this way.

As a different point (which I'm not trying to argue but point out) is that we also need to recognize momentum and the challenges it brings, especially to the less tech savvy. We can jump ship easily when tides change because we know how to sail on our own, but what about those that don't? I am sympathetic to those who think we just jump ship to ship because even when they follow when they look back it looks like everyone is fine. I think it's a really unfortunate issue and I think a much more difficult challenge to solve. I'm not sure if anyone has any ideas. OSS only makes it easy to jump ship, but it doesn't reduce the need to jump in the first place

[neonsunset]

You can use Vaultwarden. And official server implementation is open-source still.

[cyberax]

No support for passkeys, either.

[trinsic2]

I wouldn't trust passkey myself [0] [0]: https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shatt...

[cyberax]

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 experience with resetting key storages or not having enough slots are simply bugs and/or limitations of hardware. Which was to be expected from a new technology.

[rstuart4133]

> 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 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.

[cyberax]

> 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 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.

[rstuart4133]

> 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 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.

[zeofig]

It does support passkeys.

[cyberax]

iOS application doesn't: https://github.com/keepassium/KeePassium/issues/297 Neither does the Android app: https://github.com/PhilippC/keepass2android/issues/2099

[zeofig]

Well that SUCKS!