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. Also, their secret key feature ensures that if anyone does obtain a copy of your vault, they simply cannot access it with the master password alone, making it uncrackable.
- 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!
[moved] Floppy 💾
in reply to Izzy • • •Before I checked the Readme in the repository, I wondered how adbsync compares to adbfs and Syncthing. I checked and I'm pleasantly surprised!
I'm in the process of migrating all my devices to use Syncthing (via Wireguard). But I will give it a think! Sometimes I wondered whether some faster, more controlled, and direct means might be easier for some use cases. adbsync looks like it has potential here! (I used USB-cable-based data transfer and like the idea for various reasons.)
Izzy
in reply to [moved] Floppy 💾 • • •Izzy
in reply to Izzy • • •[moved] Floppy 💾
in reply to Izzy • • •Thank you a lot for the detailed explanation!
I was bothered by similar issues (installing Syncthing, lack of SSH server). Will definitely try out! Also I'm curious how well it performs on non-rooted devices (that performant, but pesky Fire HDX).
I like the rationale behind Adebar! Will have a closer look soon!
Izzy
in reply to [moved] Floppy 💾 • • •(1/2)
Izzy
in reply to Izzy • • •@floppy (2/2) but then, high performance is not on the top of my list, reliability is. Once I'm satisfied all is working as it should (which meanwhile seems the case, hence the tag; I even dared enabling deletion with one-way syncs) I'll set up a nightly cron job at e.g. 4 am. No need to watch it live. Devices connected at the time will be synced, and I can watch the logs anytime later if I wish to.
Adebar: great, take a look at the example docs it generated: izzy.codeberg.page/adebar/
Adebar DeviceDoc Examples
Izzy’s Codeberg Pages[moved] Floppy 💾
in reply to Izzy • • •I think it's a pretty elegant solution to use adbfs for elaborate syncing. I tried to go that direction in the past, but I think my old hardware got in the way in the end.
I had a look at adbsync and I like it a lot! I had some minor issues (details follow), but it seems to be working nicely. Pretty impressive you went all the way through directory tree traversal and working around the timestamp limitations!
[moved] Floppy 💾
in reply to [moved] Floppy 💾 • • •I had problems with spaces and special characters in filenames when syncing and could get it fixed by adapting sync2dev() a little.
termbin.com/w1ls
I still get some strange rsync errors, but they don't seem to impact anything.
rsync: [sender] readdir("[local-path]/[android-path]/."): Input/output error (5)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1326) [sender=3.2.4]
Izzy
in reply to [moved] Floppy 💾 • • •2) could you please put that into an issue in the repo, or a PR?
3) yes, those errors happen when syncing TO the device, Guess why I had to work around that with some special rsync options and manual timestamp adjustments 🙈 That's caused by adbfs, see github.com/spion/adbfs-rootles…
Timestamps are lost when copying to device · Issue #59 · spion/adbfs-rootless
GitHub[moved] Floppy 💾
in reply to Izzy • • •2) Will try! But setting up a Codeberg account is on my list of a while and not sure when I will get to it.
Izzy
in reply to [moved] Floppy 💾 • • •[moved] Floppy 💾
in reply to Izzy • • •That is really true, at least as far as only the actual account creation is concerned.
But before that I wanted to settle on some kind of way of handling my online identities. For privacy reasons I want to keep different interests, stuff to be put online (so much), and social interactions deliberately dissociated. As for in this case, I haven't completely settled on e.g. a proper online name for the nerdier interests. ("floppy" is nice, but wasn't intended to be final. 🙂)
[moved] Floppy 💾
in reply to [moved] Floppy 💾 • • •I haven't made it to Codeberg yet, so in the interest of not delaying it until I forget, I'll drop some thoughts here quickly. I hope that's ok. :)
In terms of documentation, I think it might be good for people less familiar with rsync to point out that in the config's .devices[].sync[].{devdir,pcdir} should keep the trailing slash. (Or some handling in the script might be nice.)
Izzy
in reply to [moved] Floppy 💾 • • •@floppy Sorry, but here those hints get lost. If you don't want to make an account at Codeberg, you can find my mail address in the imprint of my website 😉
And good point with the trailing slash – had that in mind but always forget…
[moved] Floppy 💾
in reply to Izzy • • •[moved] Floppy 💾
in reply to [moved] Floppy 💾 • • •I prefer to log to stdout only, which afaict is the unspecified option. If you think this might be interesting to others, this functionality could be documented explicitly. :) (Alternatively maybe logging to a file, but really these are just some pointers without acute need.)
I'm pretty swamped at the moment, so I might need a few more days, but I'll give adbsync a more thorough test and get back to you in a while!
Izzy
in reply to [moved] Floppy 💾 • • •@floppy log to stdout only: "logfile":"none" – and maybe 2>&1 if you really want to re-route errors there too. And yes, that is documented explicitly – see inside the doc/ dir 😉
Logging to a file: Sure, same thing and also documented: "logfile":"/path/to/logfile". Everything that's not just empty, "none" or "syslog" is expected to be a file name.
Izzy
in reply to [moved] Floppy 💾 • • •@floppy with the latest commit, adbsync makes sure devdir & pcdir have a trailing slash (if not it adds it), so docu must only point out it must be dirs (not a file name) – so it's your last wish I just implemented
Further, no longer adjusting timestamps on push. Guess what I just discovered: "adb push" supports a `--sync` parameter only pushing newer files & taking care for timestamps. "adb pull" unfortunately does not support that or rsync+adbfs would only be needed for "--delete"…
[moved] Floppy 💾
in reply to Izzy • • •I am not subscribed to many issues or projects, but incidentally I am for adbfs-rootless (for a long time actually) and incidentally I found your comments in my email inbox today. :)
Thank you for the update also! adb's parameter sounds like good news, at least partially. Maybe they fix the "pull" sub-command too some time.
Thanks for taking care of the trailing slashes! 😉 I think other people checking out the project will benefit greatly there. :)