Show more

and require signature verification, and is built on top of 's APK signing. This improves things a lot but does not mean they are immune. Debian and F-Droid repos can still override packages lower priority repos. It could make sense to have a "no overrides allowed" setting, but that would restrict useful features. Maybe F-Droid could implement "no new signing keys when overriding" rule by default, I wonder how much that would break what people are doing now? 2/2

Show thread

repository systems like etc have key issues that make them hard to decentralize properly: solid verification is optional, one repo can override packages from another, and the tooling makes it hard to see which repo was actually used. has additional measures which make it more trustworthy, but if devs add repos, those can still override it. verification helps a lot when using Maven repos but does not solve everything 1/2

“Imagine if you use a phone for twice as long…that means you only have to produce half the amount of phones and you have half the amount of waste”. 🌍 💚 #Fairphone Founder, @basvanabel@twitter.com, spoke to the team at @WhatDesignCanDo@twitter.com: youtu.be/LYhQji59dGY

EU countries are stepping up the fight for digital sovereignty for their citizens, in their schools, and in government.

See how France, Denmark, the Netherlands, and Germany do this in our blog!

nextcloud.com/blog/europe-step

People from all over Europe want the right to install any software on any device! New signatures to our open letter:

🇮🇹 Italy

Wikimedia Italia @wikimediaitalia

LinuxTrent @linuxtrent

🇩🇪 Germany

Do-FOSS @do_foss

Werkkooperative der TechnikfreundInnen @HackerGeno@chaos.socia

🇪🇸 Spain

Pangea @pangea_org

🇳🇱 Netherlands

Open Nederland @opennl

🇫🇷 France

Fédération des Fournisseurs d'Accès Internet Associatifs @ffdn_channel

Sign now! fsfe.org/activities/upcyclinga

#righttorepair #UpcyclingAndroid #freesoftware

@Gargron is providing a shining example of the new breed of "startup" culture that is arising. We want impact in the public interest, and just to make a living doing it. Getting rich is besides the point, and it is certainly not a reason to compromise the goals of the project. I believe is another example of this.

arstechnica.com/tech-policy/20

What a neat little christmas surprise 🤶 🎄 Oneplus 6 running #postmarketOS 🎉 Bye bye Apple, welcome #Linux 👋

@epixoip @sc00bz password managers need to be or at least so they can be publicly inspected. Then it would have been trivial to point out all these flaws years ago.

I recently wrote a post detailing the recent #LastPass breach from a #password cracker's perspective, and for the most part it was well-received and widely boosted. However, a good number of people questioned why I recommend ditching LastPass and expressed concern with me recommending people jump ship simply because they suffered a breach. Even more are questioning why I recommend #Bitwarden and #1Password, what advantages they hold over LastPass, and why would I dare recommend yet another cloud-based password manager (because obviously the problem is the entire #cloud, not a particular company.)

So, here are my responses to all of these concerns!

Let me start by saying I used to support LastPass. I recommended it for years and defended it publicly in the media. If you search Google for "jeremi gosney" + "lastpass" you'll find hundreds of articles where I've defended and/or pimped LastPass (including in Consumer Reports magazine). I defended it even in the face of vulnerabilities and breaches, because it had superior UX and still seemed like the best option for the masses despite its glaring flaws. And it still has a somewhat special place in my heart, being the password manager that actually turned me on to password managers. It set the bar for what I required from a password manager, and for a while it was unrivaled.

But things change, and in recent years I found myself unable to defend LastPass. I can't recall if there was a particular straw that broke the camel's back, but I do know that I stopped recommending it in 2017 and fully migrated away from it in 2019. Below is an unordered list of the reasons why I lost all faith in LastPass:

- LastPass's claim of "zero knowledge" is a bald-faced lie. They have about as much knowledge as a password manager can possibly get away with. Every time you login to a site, an event is generated and sent to LastPass for the sole purpose of tracking what sites you are logging into. You can disable telemetry, except disabling it doesn't do anything - it still phones home to LastPass every time you authenticate somewhere. Moreover, nearly everything in your LastPass vault is unencrypted. I think most people envision their vault as a sort of encrypted database where the entire file is protected, but no -- with LastPass, your vault is a plaintext file and only a few select fields are encrypted. The only thing that would be worse is if...

- LastPass uses shit #encryption (or "encraption", as @sc00bz calls it). Padding oracle vulnerabilities, use of ECB mode (leaks information about password length and which passwords in the vault are similar/the same. recently switched to unauthenticated CBC, which isn't much better, plus old entries will still be encrypted with ECB mode), vault key uses AES256 but key is derived from only 128 bits of entropy, encryption key leaked through webui, silent KDF downgrade, KDF hash leaked in log files, they even roll their own version of AES - they essentially commit every "crypto 101" sin. All of these are trivial to identify (and fix!) by anyone with even basic familiarity with cryptography, and it's frankly appalling that an alleged security company whose product hinges on cryptography would have such glaring errors. The only thing that would be worse is if...

- LastPass has terrible secrets management. Your vault encryption key always resident in memory and never wiped, and not only that, but the entire vault is decrypted once and stored entirely in memory. If that wasn't enough, the vault recovery key and dOTP are stored on each device in plain text and can be read without root/admin access, rendering the master password rather useless. The only thing that would be worse is if...

- LastPass's browser extensions are garbage. Just pure, unadulterated garbage. Tavis Ormandy went on a hunting spree a few years back and found just about every possible bug -- including credential theft and RCE -- present in LastPass's browser extensions. They also render your browser's sandbox mostly ineffective. Again, for an alleged security company, the sheer amount of high and critical severity bugs was beyond unconscionable. All easy to identify, all easy to fix. Their presence can only be explained by apathy and negligence. The only thing that would be worse is if...

- LastPass's API is also garbage. Server-can-attack-client vulns (server can request encryption key from the client, server can instruct client to inject any javascript it wants on every web page, including code to steal plaintext credentials), JWT issues, HTTP verb confusion, account recovery links can be easily forged, the list goes on. Most of these are possibly low-risk, except in the event that LastPass loses control of its servers. The only thing that would be worse is if...

- LastPass has suffered 7 major #security breaches (malicious actors active on the internal network) in the last 10 years. I don't know what the threshold of "number of major breaches users should tolerate before they lose all faith in the service" is, but surely it's less than 7. So all those "this is only an issue if LastPass loses control of its servers" vulns are actually pretty damn plausible. The only thing that would be worse is if...

- LastPass has a history of ignoring security researchers and vuln reports, and does not participate in the infosec community nor the password cracking community. Vuln reports go unacknowledged and unresolved for months, if not years, if not ever. For a while, they even had an incorrect contact listed for their security team. Bugcrowd fields vulns for them now, and most if not all vuln reports are handled directly by Bugcrowd and not by LastPass. If you try to report a vulnerability to LastPass support, they will pretend they do not understand and will not escalate your ticket to the security team. Now, Tavis Ormandy has praised LastPass for their rapid response to vuln reports, but I have a feeling this is simply because it's Tavis / Project Zero reporting them as this is not the experience that most researchers have had.

You see, I'm not simply recommending that users bail on LastPass because of this latest breach. I'm recommending you run as far way as possible from LastPass due to its long history of incompetence, apathy, and negligence. It's abundantly clear that they do not care about their own security, and much less about your security.

So, why do I recommend Bitwarden and 1Password? It's quite simple:

- I personally know the people who architect 1Password and I can attest that not only are they extremely competent and very talented, but they also actively engage with the password cracking community and have a deep, *deep* desire to do everything in the most correct manner possible. Do they still get some things wrong? Sure. But they strive for continuous improvement and sincerely care about security.

- Bitwarden is 100% open source. I have not done a thorough code review, but I have taken a fairly long glance at the code and I am mostly pleased with what I've seen. I'm less thrilled about it being written in a garbage collected language and there are some tradeoffs that are made there, but overall Bitwarden is a solid product. I also prefer Bitwarden's UX. I've also considered crowdfunding a formal audit of Bitwarden, much in the way the Open Crypto Audit Project raised the funds to properly audit TrueCrypt. The community would greatly benefit from this.

Is the cloud the problem? No. The vast majority of issues LastPass has had have nothing to do with the fact that it is a cloud-based solution. Further, consider the fact that the threat model for a cloud-based password management solution should *start* with the vault being compromised. In fact, if password management is done correctly, I should be able to host my vault anywhere, even openly downloadable (open S3 bucket, unauthenticated HTTPS, etc.) without concern. I wouldn't do that, of course, but the point is the vault should be just that -- a vault, not a lockbox.

I hope this clarifies things! As always, if you found this useful, please boost for reach and give me a follow for more password insights!

@matthew_d_green The solution to the problem posed in that piece is referenced in it: got messages when they had a legitimate reason to have them. End-to-end encryption stops mass surveillance, but clearly did not stop the Jan 6th investigations. I think its pretty clear that phones should be treated like one's house in terms of search and seizure. Courts can compel people to give info, and can compel people to unlock their phones. My guess is that's how FBI got info from Signal.

Today’s social media status quo isn’t cutting it, so Mozilla is exploring an alternative here on Mastodon. In early 2023, Mozilla will be testing a publicly accessible instance in the Fediverse at Mozilla.Social. We will keep you updated, but for now learn more here: mzl.la/3BNXQMQ

Targeted advertising based on online behavior doesn’t just hurt privacy. It also contributes to a range of other harms. eff.org/deeplinks/2022/03/ban-

Happy to have our last version of "The Android Platform Security Model" now included in the official August 2021 edition of ACM Transactions on Privacy and Security: dl.acm.org/doi/10.1145/3448609.

Fully open access - download, read, share, feel free to use however it's helpful ;-)

"A passionate and bipartisan legislative effort to rein in the country’s largest technology companies collapsed this week, the victim of an epic lobbying campaign by Amazon, Apple, Google and Meta"
bloomberg.com/news/articles/20

When is built into a ROM, like , for , etc there is no popup warning with fdroidclient. That comes from "Play Protect", which is proprietary software that flags things based on automated rules, it does not point to real world security concerns for apps like . I have nothing against the sandbox, I just think it is important to note what it is good for, and what it cannot do well 2/2

Show thread

As lead maintainer of the official client, I hear a lot of criticism that is still at 25. fdroidclient is , publicly audited, with , written in memory safe languages, with a proven record of respecting and delivering . The source and binaries also receive human and machine review. is designed around untrusted proprietary software with non-memory safe code where the binary only gets machine review. 1/2

@guardianproject @lauren And of course is a key part of this whole picture, allowing anyone to confirm that the exact binary that is running on their device matches the source code as published and audited.

We may never be able to match the incredible achievements of #JohnMastodon, but the European Union still plays its part!

We are proud funders of Mastodon through the Next Generation Internet initiative (@EC_NGI).

Open,
Interoperable,
Decentralised,
Trust based.

More info: ngi.eu/blog/2022/11/24/how-ngi

@lauren and audits are the only way to provide trustworthy . Apps like , with /#Megolm, with , , provide trustworthy E2EE because they are built on open standards, free software, and have been publicly audited. That is the standard all services should be held to in order to be labeled trustworthy. Anything else just means you have to trust the service operator. 2/2

@lauren It is important to describe the limitations here. E2EE here would be useful when emailing with third parties. Since is proprietary software, users just have to trust to do the right thing. Technically, it is easy to build E2EE where the service can get the private keys and decrypt as they like. Given participation in etc, proprietary Gmail cannot provide trustworthy E2EE, especially considering most emails stay within Gmail 1/2

Show more
Librem Social

Librem Social is an opt-in public network. Messages are shared under Creative Commons BY-SA 4.0 license terms. Policy.

Stay safe. Please abide by our code of conduct.

(Source code)

image/svg+xml Librem Chat image/svg+xml