I love the idea of having privacy in independence from all the tech giants’ services. I have a server at home that hosts my storage, media, synchronization, and backups, along with some other random services. Since all these services are basically my life, I sometimes read about better security practices to replace whatever I do. Although sometimes, I feel like I can’t figure out what practices are actually bad and really put me in a bad spot, and if they are good enough for me.
For example, I use a Keepass database to store my passwords. I want to sync them across all of my devices immediately. So I saved it in my VPS, and made the android client fetch it every time I sync. I also made a script that uploads the local database every time it is changed. However, I don’t want it to override remote changes that I may have not saved on my local machine. To solve that, I made the script download the remote database and compare it to the local one before uploading. To compare, I made the script read from a PGP encrypted file that has the password to my database, and input that to keepass-diff. However, I read that using PGP is bad from this article. I can’t say I completely understand what the author is saying, but I trust that they know their stuff. However, I feel like this is a bit nitpicky. Would using GPG make me exposed to massive risk as opposed to using any other service? I guess it’s not that hard to move over to something like ccrypt or whatever, but why bother? Besides, I can tell GPG to keep my key in the session for a long time so that I don’t have to input it every time. I don’t know if ccrypt can do that.
Another example is using F-Droid. I came across this article and this one went way over my head since I’m not really well versed on android. But the gist I got is that F-Droid is not only insecure but is also bad for getting timely updates. I checked and some apps are something like 7 patches behind which is unacceptable for me.
One last example and this one is kinda petty no lie. The fact that RSA is trash. I read here and there that RSA is an old and deprecated encryption algorithm that no one should use this is another article that (surprise surprise) also went over my head. But what I could understand is that it is too easy to make mistakes using RSA and it should be in the history books. But I already made many SSH keys without choosing the encryption algorithm, so it’s gonna be a bit inconvenient to change all of those.
So my question to yall is that, how do I find the line between using an acceptable albeit non optimal practice, and using an unacceptable practice for security?
Of course, I also have to put in mind the convenience, so I can’t just change up my practices every 8 seconds when I find out that whatever program I’m using is a ticking time bomb.
I went through a similar dilemma. My solution (take with a grain of salt) was to take a 1 month break and learn all of the stuff that I didn’t understand. When I came back, I found that less articles went over my head, and I actually understood them. Just some advice :)
It’s a balance between convenience against privacy and security. The more private and secure you become, the more inconvenient. If something is too inconvenient, people will just work around it: writing passwords on a sticky note because the requirements were too high. It’s impossible to strike the perfect balance. Threat modeling is important. Threat modeling is where you determine what is OK and what isn’t. I have an Instagram account because my girlfriend likes to send me funny videos. I only use it to watch what she sends me, and I have it isolated from the rest of my apps. I could delete it, but my threat model allows it.
Side note: anything cryptography and computing is basically magic.
Stopped reading at “storing my passwords on a db”. Even if you encrypt the data, is it not just plain better to use a generative algorithm for passwords instead that needs no cloud? Why would you even introduce the vulnerability yourself of storing passwords somewhere in the first place? Keep it simple, you don’t want to over-engineer yourself to death, especially if you are actually downgrading your security by building too far ahead of what you actually need.
Stopped reading at “storing my passwords on a db”. Even if you encrypt the data, is it not just plain better to use a generative algorithm for passwords instead that needs no cloud?
There are quite a few reasons why we don’t recommend deterministic password managers and I have been meaning to write an article about it. There is a summary and further discussion in that thread.
With these 2 password managers, if I know your master password, all I need to do is to find your username/email address(which is trivia cuz usernames are public and email addresses are not confidential), and I can derive every single password you have and completely mess you up
But you clearly must not use your email as your “user”, and you can also salt your “website” too, eg:
I am James Wililiams, email: jimmyw@gmail.com, I want a password for lemmy.world, if your spectre usage is: user: jimmyw@gmail.com, masterpassword: mydogsname99, site: lemmy.world, your masterpassword leakage might be dangerous. But if you generate your passwords in the form of: user James MyMagicSalt Williams, password: ASuperCrazyMasterP455w0rdW1th1337, and website: anotherOfMySalts.lemmy.world, there is nothing wrong with someone getting your master password, good luck getting any real passwords from it. You would need to straight up be keylogged and be inputting the 3 settings while somebody knowing you are doing it in order to make sense of the keylog.
Using a KDF for stateless passwords is a interesting concept. It isn’t prefect tho. What if you want multiple passwords for one site, lack of any 2FA, KDF has to be somewhat fast (bcrypt or scrypt what takes under a second) & once your master password gets leaked your screwed (compared to cloud stored passwords with 2FA, key rotation etc)
Realistically stateless password managers suffer from the same attacks cloud based ones do, MITM attacks. If the client is open to being tampered with, your keys can always get leaked.
It’s not the legal name, it’s whatever you want it to be, or your name with a salt. There is no requirement for the “user” and “site” fields to be: your name or your webpages name, you just need to remember your pattern. Your User could be a complex password too . Your sites could have another complex password preceding them. Your website format could even be preceded by another generative password. eg getting my lemmy creds would look like: pwd sup3rs3cure%, user w0ntc4tchm3^ , website: Naqm3~KinoZiju.lemmy , not my actual email, or my display username here, nor the actual plain url of the website . Good luck getting any other website password if “sup3rs3cure%” is leaked, which is hardly possible as it is never uploaded anywhere .
Another example is using F-Droid. I came across this article and this one went way over my head since I’m not really well versed on android. But the gist I got is that F-Droid is not only insecure but is also bad for getting timely updates. I checked and some apps are something like 7 patches behind which is unacceptable for me.
F-Droid allows you to add any repository, not just the one managed by them. So you don’t have to trust the platform to take advantage of F-Droid.
F-Droid build/sign cycles are a lot faster that Google Play in most cases. Google claims updates are proccessed from several hours to 7 business days. But basically if do anything more than fix a typo it’s always days before it gets processed.
If apps are out of date it’s due to a developer, not F-Droid.
Fundamentally F-Droids design and infrastructure is outdated (admitted by F-Droid developers too.) F-Droids security scanning may be faster but also less robust then Google in terms of detection of harmful apps.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !privacyguides@lemmy.one
In the digital age, protecting your personal information might seem like an impossible task. We’re here to help.
This is a community for sharing news about privacy, posting information about cool privacy tools and services, and getting advice about your privacy journey.
You can subscribe to this community from any Kbin or Lemmy instance:
Check out our website at privacyguides.org before asking your questions here. We’ve tried answering the common questions and recommendations there!
Want to get involved? The website is open-source on GitHub, and your help would be appreciated!
This community is the “official” Privacy Guides community on Lemmy, which can be verified here. Other “Privacy Guides” communities on other Lemmy servers are not moderated by this team or associated with the website.
Moderation Rules:
We prefer posting about open-source software whenever possible.
No soliciting engagement: Don’t ask for upvotes, follows, etc.
Surveys, Fundraising, and Petitions must be pre-approved by the mod team.
Be civil, no violence, hate speech. Assume people here are posting in good faith.
Don’t repost topics which have already been covered here.
News posts must be related to privacy and security, and your post title must match the article headline exactly. Do not editorialize titles, you can post your opinions in the post body or a comment.
Memes/images/video posts that could be summarized as text explanations should not be posted. Infographics and conference talks from reputable sources are acceptable.
No help vampires: This is not a tech support subreddit, don’t abuse our community’s willingness to help. Questions related to privacy, security or privacy/security related software and their configurations are acceptable.
No misinformation: Extraordinary claims must be matched with evidence.
Do not post about VPNs or cryptocurrencies which are not listed on privacyguides.org. See Rule 2 for info on adding new recommendations to the website.
General guides or software lists are not permitted. Original sources and research about specific topics are allowed as long as they are high quality and factual. We are not providing a platform for poorly-vetted, out-of-date or conflicting recommendations.
I went through a similar dilemma. My solution (take with a grain of salt) was to take a 1 month break and learn all of the stuff that I didn’t understand. When I came back, I found that less articles went over my head, and I actually understood them. Just some advice :)
It’s a balance between convenience against privacy and security. The more private and secure you become, the more inconvenient. If something is too inconvenient, people will just work around it: writing passwords on a sticky note because the requirements were too high. It’s impossible to strike the perfect balance. Threat modeling is important. Threat modeling is where you determine what is OK and what isn’t. I have an Instagram account because my girlfriend likes to send me funny videos. I only use it to watch what she sends me, and I have it isolated from the rest of my apps. I could delete it, but my threat model allows it.
Side note: anything cryptography and computing is basically magic.
Stopped reading at “storing my passwords on a db”. Even if you encrypt the data, is it not just plain better to use a generative algorithm for passwords instead that needs no cloud? Why would you even introduce the vulnerability yourself of storing passwords somewhere in the first place? Keep it simple, you don’t want to over-engineer yourself to death, especially if you are actually downgrading your security by building too far ahead of what you actually need.
I said a keepass db but whatever homie
There are quite a few reasons why we don’t recommend deterministic password managers and I have been meaning to write an article about it. There is a summary and further discussion in that thread.
Third party blog article which is still relevant https://tonyarcieri.com/4-fatal-flaws-in-deterministic-password-managers
It says about spectre:
But you clearly must not use your email as your “user”, and you can also salt your “website” too, eg: I am James Wililiams, email: jimmyw@gmail.com, I want a password for lemmy.world, if your spectre usage is: user: jimmyw@gmail.com, masterpassword: mydogsname99, site: lemmy.world, your masterpassword leakage might be dangerous. But if you generate your passwords in the form of: user
James MyMagicSalt Williams, password:ASuperCrazyMasterP455w0rdW1th1337, and website: anotherOfMySalts.lemmy.world, there is nothing wrong with someone getting your master password, good luck getting any real passwords from it. You would need to straight up be keylogged and be inputting the 3 settings while somebody knowing you are doing it in order to make sense of the keylog.Using a KDF for stateless passwords is a interesting concept. It isn’t prefect tho. What if you want multiple passwords for one site, lack of any 2FA, KDF has to be somewhat fast (bcrypt or scrypt what takes under a second) & once your master password gets leaked your screwed (compared to cloud stored passwords with 2FA, key rotation etc)
Realistically stateless password managers suffer from the same attacks cloud based ones do, MITM attacks. If the client is open to being tampered with, your keys can always get leaked.
Once you master password gets leaked, attackers would also need to know:
Your legal name & website pattern is not a secure password.
It’s not the legal name, it’s whatever you want it to be, or your name with a salt. There is no requirement for the “user” and “site” fields to be: your name or your webpages name, you just need to remember your pattern. Your User could be a complex password too . Your sites could have another complex password preceding them. Your website format could even be preceded by another generative password. eg getting my lemmy creds would look like: pwd sup3rs3cure%, user w0ntc4tchm3^ , website: Naqm3~KinoZiju.lemmy , not my actual email, or my display username here, nor the actual plain url of the website . Good luck getting any other website password if “sup3rs3cure%” is leaked, which is hardly possible as it is never uploaded anywhere .
Bitwarden password manager is secure, easy to use and syncs across devices on its own.
Most F-Droid apps you can probably download from the developer’s GitHub. Use the app Obtainium to download and update them fast.
Have you looked into Syncthing? It sounds like it might be a solution.
I use it and it’s great, but it’s not immediate a lot of the time.
F-Droid allows you to add any repository, not just the one managed by them. So you don’t have to trust the platform to take advantage of F-Droid.
F-Droid build/sign cycles are a lot faster that Google Play in most cases. Google claims updates are proccessed from several hours to 7 business days. But basically if do anything more than fix a typo it’s always days before it gets processed.
If apps are out of date it’s due to a developer, not F-Droid.
Fundamentally F-Droids design and infrastructure is outdated (admitted by F-Droid developers too.) F-Droids security scanning may be faster but also less robust then Google in terms of detection of harmful apps.