🇮🇹 🇪🇪 🖥

  • 0 Posts
  • 158 Comments
Joined 6 months ago
cake
Cake day: March 19th, 2024

help-circle
  • Looking at keepassXC doc I couldn’t find such setup. Maybe it’s possible, but maybe it also leads to trouble down the road. The “official way” seems to use cloud storage.

    You keep saying external server for syncthing, but again: syncthing does direct data transfers, encrypted end to end, between devices.

    I mention that but with a specific context.

    • people with certain ISPs will need to use the relay transfer feature because direct connections can’t be established. Similarly, if you work in an office and you use the corporate network, you usually can’t have device-to-device working (can be both from a technical POV and from a policy POV).
    • even with 0 data transfers, servers still have some trust in establishing your direct connections. I know that syncthing uses keys to establish connections, but that’s why I mentioned CVEs. If there is one, your sync connection could be hijacked and sent elsewhere. It’s a theoretical case, I don’t think it’s very likely, but it’s possible. The moment you have a server doing anything, you are extending trust.

    In those cases then yes, you are extending a bare minimum trust, and you fully encrypted data would temporarily pass on the relay’s RAM

    And from my (consumer) PoV this is functionally equivalent to have the data stored on a server. It might not be all the data (at once), it might be that nobody dumps the memory, but I still need to assume that the encrypted data can be disclosed. Exactly the same assumption that should be made if you use bitwarden server.

    If this makes you paranoid

    Personally it doesn’t. As I said earlier, it’s way more likely that your entire vault can be taken away by compromising your end device, than a sophisticated attack that captures encrypted data. Even in this case, these tools are built to resist to that exact risk, so I am not really worried. However, if someone is worried about this in the case of bitwarden (there is a server, hence your data can be disclosed), then they should be worried also of these corner cases.

    I just get nothing from Bitwarden that syncthing and KeePass don’t offer more easily.

    You can say many things, but that keepass + syncthing is easier is not one of them. It’s a bespoke configuration that needs to be repeated for each device, involving two tools. bitwarden (especially if you use the managed service) works out of the box, for all your devices with 0 setup + offers all features that keepass doesn’t have (I mentioned a few, maybe you don’t need them, but they exist).

    I don’t know how or why you would have vault conflicts, but it really does sound like something fixable

    At the time I did not use syncthing, I just used Drive (2014-2017 I think), and it was extremely annoying. The thing is, I don’t want to think about how to sync my password across devices, and since I moved to bitwarden I don’t have to. This way I don’t need to think about it, and also my whole family doesn’t have to. Win-win.

    That said, if you are happy with your setup, more power to you. I like keepass, I love syncthing, I have nothing against either of them. I just came here to say that sometimes people overblow the risk of a server when it comes to a password manager. Good, audited code + good crypto standards means that the added risk is mininal. If you get convenience/features, it’s a win.


  • Agree on the versioning issue. In fact I mentioned that the issue is convenience here. It is also data corruption, but you probably are aware of that if you setup something like this. Manually merging changes is extremely annoying and eventually you end up forgetting it to do it, and you will discover it when you need to login sometime in the future (I used keepass for years in the past, this was constantly an issue for me). With any natively sync’d application this is not a problem at all. Hence +1 for convenience to bitwarden.

    However KeePassXC’s sync feature does sync the vault.

    How does it work though? From this I see you need to store the database in a cloud storage basically.

    For mobile I just give syncthing full permission to run in the background and have never had issues with the syncing on the folders I designate.

    I use this method for my notes (logseq). Never had synchronization problem, but a lot of battery drain if I let syncthing running in the background.

    Nothing else passes through it unless you opt into using relaying in case you have NAT issues.

    I guess this can be very common or even always the case for people using some ISPs. In general though, you are right. There is of course still the overall risk of compromise/CVEs etc. that can lead to your (encrypted) data being sent elsewhere, but if all your devices can establish direct connections between each other, your (encrypted) data is less exposed than using a fixed server.

    If you are paranoid, the software is open source and you can host your own relays privately,

    This would also defeat basically all the advantages of using keepass (and family) vs bitwarden. You would still have your data in an external server, you still need to manage a service (comparable to vaultwarden), and you don’t get all the extra benefits on bitwarden (like multi-user support etc.).

    To be honest I don’t personally think that the disclosure of a password manager encrypted data is a big deal. As long as a proper password is used, and modern ciphers are used, even offline decryption is not going to be feasible, especially for the kind of people going after my passwords. Besides, for most people the risk of their client device(s) being compromised and their vault being accessible (encrypted) is in my opinion way higher than -say- Bitwarden cloud being compromised (the managed one). This means that for me there are no serious reasons to use something like keepass (anymore) and lose all the convenience that bitwarden gives. However, risk perception is personal ultimately.


  • Few reasons, with the most important being convenience. Syncthing is going to see just a binary blob as the password storage is encrypted. This means it is impossible for syncthing to do proper synchronization of items inside the vault. Generally this is not a problem, but it is if you happen to edit the vault on multiple devices and somehow syncthing didn’t sync yet the changes (this is quite common for me on android, where syncthing would drain the battery quite quickly if it’s always actively working). For bitwarden on the other hand the sync happens within the context of the application, so you can have easy n-way merge of changes because its change is part of a change set with time etc.

    Besides that, the moment you use syncthing from a threat model point of view, you are essentially in the same situation: you have a server (in case of syncthing - servers) that sees your encrypted password data. That’s exactly what bitwarden clients do, as the server only has access to encrypted data, the clients do the heavy lifting. If the bitwarden server is too much of a risk, then you should worry also of the (random, public, owned by anybody) servers for syncthing that see your traffic.

    Keeshare from my understanding does use hosting, it uses cloud storage as a cloud backend for stateful data (Gdrive, Dropbox etc.), so it’s not very different. The only difference would be if you use your private storage (say, Synology Drive), but then you could use the same device to run the bit/vaultwarden server, so that’s the same once again.

    The thing is, from a higher level point of view the security model can only be one of a handful of cases:

    • the password data only remains local
    • the password data is sync’d with device-to-device (e.g. ssh) connections
    • the password data is sync’d using an external connection that acts as a bridge or as a stateful storage, where all the clients connect to.

    The more you go down in the list, the more you get convenience but you introduce a bit of risk. Tl;Dr keepass with keyshare/syncthing has the same risks (or more) than a Bitwarden setup with bitwarden server.

    In addition to all the above, bitwarden UX is I would say more developed, it has a better browser plugin, nice additional tools and other convenience features that are nice bonuses. It also allows me to have all my family using a password manager (including my tech illiterate mom), without them having to figure out anything, with the ability to share items, perform emergency accesses etc.

    Edit: I can’t imagine this comment to be deemed off topic, so if someone downvoted simply to express disagreement, please feel free to correct or dispute what I wrote, as it would certainly make for an interesting conversation! Cheers





  • Most of Italian recipes are very simple. The focus usually is on quality on the ingredients and if they are good, a pizza with just mozzarella and tomatoes is already delicious. That said, even in Italy there are plenty of types of pizzas, but most of them don’t have 20 ingredients, I suppose the point is that you actually want to taste what you eat, which is not the case when you mix many different things. There is a very messy and rich pizza (capricciosa) with a lot of toppings though (more than one obviously, but this is the most common).

    Personally I am a margherita person, simple and boring is perfect, as long as it tastes great.

    P.s. Giuseppe :)




  • For what is worth, that’s not how (most?) Italians think about pizza. It’s not a “container” in which you put a bunch of things, but each pizza type is basically a separate dish.

    I personally don’t care what people put on their pizza, I simply avoid places that make “pizzas” in a non-italian fashion, like the american (supposedly NY style) ones where you get crust, 2 fingers of industrial cheese and a whole plant of oregano.

    It’s very similar for pasta, which many people think as a bread replacement.


  • I can’t really make an exhaustive comparison. I think k3s was a little too opinionated for my taste, with lots of rancher logic in it (paths, ingress, etc.). K0s was a little more “bare”, and I had some trouble in the past with k3s with upgrading (encountered some error), while with k0s so far (about 2 years) I never had issues. k0s also has some ansible role that eases operations, I don’t know if now also k3s does. Either way, they are quite similar overall so if one is working for you, rest assured you are not missing out.





  • You should definitely be! I take backups every 6h for my self hosted vaultwarden (easier to manage and to backup, but not official, YMMV). You can also restore each backup automatically and have a “second service” you can run elsewhere (a standby basically), which will also ensure the backup works fine.

    I have been running bit/vaultwarden now for I think 6 years, for my whole family and I have never needed to do anything, despite having had a few hiccups with the server.

    Don’t take my word for it, but the clients (browser plugin, desktop app, mobile app) are designed to keep data locally I think. So the term cache might be misleading here because it suggests some temporary storage used just to save web requests, with a relatively quick expiration. In this case I think the plugin etc. can work potentially indefinitely without server - something to double-check, but I believe it’s the design.


  • Interesting! That’s very close to this blog post I read long time ago (unfortunately medium.com link)! Are you actually sending emails from those addresses? Like if you need to drop an email to your bank, do you use the banking one or your personal (or something else)?

    Fwiw, I do something similar. I use a mix of domain aliases without address (e.g. made-up-on-the-fly@domain.com) and actual aliases. Since I have proton family (and the same when I used ultimate) I have unlimited hide-my-email aliases, so I have it integrated with my password manager, and I generate a random password and email for everything I sign up now. These though are receive-only addresses. In fact, with this technique I probably use 3-4 addresses in total, but I have probably 30 domain addresses that go to the catch-all one.

    Spam on these addresses are basically non-existing and you can still create folders based on recipient without having a full address (e.g. bank1@domain.com, bank2@domain.com). You can make folder categorization based on recipient regex and this way you also have the “stop bothering me” option: if some email gets into the wrong hands, you can create a spam rule for that dedicated address. However, my approach is that all of these are used just to receive emails, to send I have just a handful of actual addresses or -if really needed- I can create on-the-fly an address from a catch-all one, send the email and then disable it again (so it doesn’t count towards the limit, but I still get inbound email to the catch-all).

    Nice setup anyway!


  • Your requirements are totally fair tbh.

    That said, I think you can use aliases for the use-case you have, you don’t need full addresses. Proton supports “+ aliases” as well, so name+service@domain works, and most importantly they support catch-all addresses if you have your own domain. I now use actual aliases (the ones from simplelogin), which I generate on the fly, but if you can use whatever@domain and it will be redirected to your configured address. You don’t even need to create this beforehand, so many times I was around and had to give an email address for some reason and I just made up an address on the fly. As long as you use your domain, the catch-all will get the email.

    So the 10 addresses only include actual addresses, the ones you can write from. You can have as many as you want to receive emails (which is generally the use case for signing up to services, right?). Just a FYI in case tuta supports the same and you are making more effort than needed!



  • Encrypted or not, the fact that someone else has it stored somewhere in their computers is dangerous.

    Of course. You are simply over-representing this risk, though. Besides, regular people realistically don’t need to worry about Proton being backdoored, because their device is 10-100x more likely to be breached instead. Security is not a binary, it’s a shade. Performing a software update is also “dangerous”. Do you check every time you update the software its code, to verify no malicious backdoor is there? No, exactly, you trust the maintainers and the package infrastructure.

    The only recommended way to store private keys are offline and encrypted.

    So you don’t store them on your device(s) (encrypted)? I store my GPG keys that I use to sign software on my yubikeys. That said, email is something I check from my phone and multiple computers (as most people). Do you really use a hardware key to do on-the-fly decryption, every time someone sends you a message, from each device?

    As a security engineer, I also generally discourage such absolute “recommendations”. My threat model is different from a regular Joe threat model, and both are different from Snowden’s. There is no such thing as “only recommended way”, because this is not a religion, it’s a risk decision. Most people use Gmail, where the content of their email is literally available server side. Those same people can gain privacy and security using GPG via Proton, and in their threat model “provider gets compromised and software backdoored” is completely irrelevant. Is it relevant in your threat model? Good, then yes, you should only store keys offline and encrypted. Actually, you shouldn’t use email at all, and you should use dedicated tools and protocols that are meant for security, where metadata is not transmitted in clear text, for example. You should also have virtually no session duration and perform a full login with 2FA every time, you should probably access the software that you use to communicate only from a secure machine dedicated for the purpose etc…

    I think you trust Proton a bit too much.

    I simply have clear in my mind what my threat model is and what risks are acceptable. I perfectly fit in the “Anyone with privacy concerns” category in the threat model they built. What about you?