LastPass Android app has got 7 trackers in it
reports.exodus-privacy.eu.org
reports.exodus-privacy.eu.org
We had previously actually planned to switch to a paid plan with them by July anyway (to nobody's surprise, management can be extremely slow to approve these things) - but their deadline was March and they way they forced our hand got management to act surprisingly quickly in transitioning us to Bitwarden.
I wonder which, excuse me, brain-dead executive honestly thought waving a pistol in users' faces like an amateur highwayman to force them to pay was by any stretch of the imagination an acceptable way to improve user confidence, especially in such a sensitive area where they store (access to) your most personal and private secrets. The same holds true for these trackers. I mean, I see all these weird decisions and just ask myself, who are these people in positions of significant power of larger companies who make such obvious, crazy bad management decisions? Whenever I meet them, they all seem so normal and well-dressed ;-) Boggles my mind every time.
I must say, for years now I've had the impression all the amazing products that LogMeIn (who own LastPass) touches, get toxic for the end-user quickly. Hamachi was so great in the olden days. GoToMeeting couldn't be rescued even by Covid. They had, at one point, one of the greatest remote desktop solutions around (which you could even completely self-host) but they were basically killed by TeamViewer because of their boneheaded licensing decisions.
Of course, TeamViewer has been going down the same drain and has significantly killed mass appeal since their IPO, which leads me to believe that this is just the "circle of liiiive"...
Apparently the private equity deal was only finalized in August of last year, see:
[1] https://www.nasdaq.com/press-release/francisco-partners-and-...
One who set an expectation ought not be shocked when one's users have that expectation.
I don't think they are evil, but I do think they handled this transition poorly and with messaging that clearly didn't win their users over to their side.
Also, tracking is bad. I wouldn't do business with them on that basis.
I think they've lost focus of that now, their incentives have shifted (maximum cash extraction) and they're also tone-deaf. You just can't add 7 trackers to such a product without losing credibility.
Look, nowadays, some telemetry feedback (aka. trackers) is extremely valuable to iterate quickly and improve your software, also to the benefit of the end-user. What you certainly don't need is seven (7) trackers or to make them compulsory instead of opt-in or at least opt-out. I mean, the amount of "non-evil" stuff you could learn with a tracker in a password manager is certainly so limited that it doesn't justify 7 trackers. Anything above one self-hosted, non-third-party, non-adware telemetry server does seem slightly... evil in this context. ;-)
And if you add 7 trackers AND try to trick me with bait & switch tactics, well then, indeed, you're gonna lose a lot of business. Hope the bit of extra cash they got from people who panicked and didn't have time to set up alternatives was worth it...
Trello is currently evolving into a full-fledged project management tool and they fuel growth by adding new features to business class only. While that's not leaving the best taste either, I can understand.
When they tried to limit Trello Gold further, we retaliated so hard so, they relaxed their policies a bit.
I don't need their new features since it's not well organized for individuals but, they neither change the price of Trello Gold, nor remove features from it. It's a good compromise.
The irony of claiming this is a free service when the service uses 7 trackers. The free service is a product!
Edit: I'm actually not sure about all of them.
Mixpanel and Segment are not ad trackers, they're used for profiling and habit-tracking and essentially to get into people's brains (understand their decision making, interactions etc.). It's not advertising, it's much worse. They're also so-called "first-party customer data collection tools". The raw gold nuggets that get sold on. You could call it "people-data trafficking".
Then they have four (4) Google trackers in it. Again, yes, technically not for advertising. But how we can call anything with the name "Google" in it "not advertising", well come on, seriously, I know we all like to delude ourselves sometimes (I sure know I do) but that might be a bit of a stretch ;-)
A single one of these trackers might be legitimate in a software such as this (privacy-centric, a highly sensitive service that's supposed you keep all your secrets or at least manage access to them), in that it tracks UI issues, errors, crashes etc. and helps developers to quickly improve the product and create a better UX. But the rest is heavy data mining equipment. They're not the ones who'll do the advertising but you WILL be advertised to with the data collected here, make no mistake.
So when you're building a brand you have to ask, how much is the bad press and the millions of disappointed users worth to you? You have to understand, users you're losing this way are never coming back because you have nothing to offer them anymore. And they'll tell their friends, family, colleagues, bosses and just like that you lose a huge userbase.
OTOH, if you treat your free users with respect, chances are they'll recommend you left and right and a percentage of these recommendations is bound to convert to paying customers. Of course if you're greedy and want to milk your customers for all they're worth and you don't really care about the long-term success of your product or your brand, then by all means, go for it.
Another thought experiment: Imagine I gave you a generous gift for your birthday, like a new gaming laptop. You'd be using it for a few months, you'd finally throw out your old desktop PC and create your whole digital life around this laptop, install all your software, configure all your shortcuts etc. Then one morning I'd just show up and say, either you're paying my $$ every month from now until you die or I'll make it so that the left mouse button/half the RAM/the right screen half don't work anymore. You'd be just the tiniest bit pissed about that, wouldn't you? Sure, I'd claim that there was a file in C:\Windows\system32\drivers\etc\giftconditions-eula.txt that said I could do that anytime, too bad you didn't read it. But because while it looked like I was being generous, my goal was to trap you and then force you into a situation where it's ostensibly easier to just give me some money every month than to switch your whole life back to another system and build everything again from scratch. Additionally, even if you agreed to pay me, I'd now hide a few rootkits and trackers on the device, cause what are you gonna do? Sure, I might say, feel free to copy all your files to a USB stick and use them elsewhere (GDPR) but come on...
Yeah okay it's not the same. But can we agree that LastPass's behavior is a great example of how to make people angry at you?
How did they disrespect their users? They even offer CSV export. Perhaps you can offer an alternative way doing it, I'm genuinely interested.
It's expensive to develop, maintain, improve a service that works across devices, operating systems, and browsers. But more importantly, _someone_ has to pay for CPU, RAM and bandwidth. Would you rather that someone be yourself or (eventually) advertisers.
Note that the listed trackers are not really trackers but analytics tools.
Also, you seem to be offering a false choice here, if I may say so respectfully. The way I understand it, the choice is not between Pro and Free with ads. The choice is between Free with highly invasive data mining trackers and Pro with highly invasive data mining trackers.
As for the trackers being analytical tools, well, a distinction without a (significant) difference in this case. I responded to that above. You could easily make a case that these trackers are worse than the addition of a random, not overly invasive ad network.
At this point, if I could advise LastPass, I'd just totally backtrack, apologize deeply, commit to keeping the free tier for the foreseeable future, remove all but one of the trackers, commit to a total privacy-centric policy ("The password safe users will always be able to trust") and take that time to build a convincing value proposition for anyone who pays for Slack, Teams and WinRAR (i.e. professional users and enterprises), not a student or someone's grandma who will now have to pay up or be tracked and have only half the functionality it relied on for years... I'm frankly convinced that (not overnight but in the long-term), revenue will be much higher and more stable. LastPass could still be the first (or second, after uBlock Origin) browser plugin everyone installs on a new system. But next quarter might be a blood-bath compared to the projections their private equity friends did in expectation of finally getting to sell all that preciousss user data. ;-)
I agree that storage cost is completely marginal and I am quite sure they had a sustainable ratio of paying to free users (otherwise they'd have made completely different decisions or shut the service down). In my experience, LastPass had one of the best brand reputations among password managers, and LogMeIn can do "good software" (but not sell it sensibly to anyone but enterprise audiences it seems). That's down the drain now of course, which certainly is a shame.
7 trackers and the purposeful deterioration of the free tier can only be explained by greed, I think. (Unfortunately, we'll likely never know the true decision-making process that went into this but come on, it's a game of probabilities).
So I had it installed on all of my family and friend's computers to use it occasionally when they had trouble.
Then one day they changed license and you couldn't use them anymore.
I had to move to TeamViewer.
So I had to move on to... nothing actually, now I'm using the Windows-integrated "Quick Assist" feature which works fairly well (but requires a Microsoft account unfortunately).
There's any of a dozen possibilities that allows you to monetize your service without antagonizing long-time users (if you believe LastPass really had an unsustainable ratio of free to paying customers, which I actually don't, I think they're just trying to milk it).
Adding spyware/trackers to a privacy-centric app and forcing customers to "pay up or leave" at a moment's notice, nah, there is no good excuse for that.
Not laggy rather than waiting time in the multiple seconds range.
(Some will probably think this was because of encryption but ok the same machine the Girefox extension was snappy.)
These aren't advertising trackers. They're not selling your data.
They're name-brand, industry-standard product analytics, for measuring the usage of app features etc. They're for improving UX and the product generally. I mean, one of them is solely for crash reporting.
This is zero privacy or security risk here. This is standard for essentially any commercial app. There is absolutely nothing unique or different or exceptional about LastPass here. And there is nothing about being a password manager that somehow makes this inappropriate. It's not like it's uploading your passwords to its analytics or anything.
Seriously, this is just spreading FUD. I get that a lot of people hate LastPass for a lot of reasons, but this isn't a good reason.
Not sure how facts are FUD. The submission here is saying "got 7 trackers in it" which are facts. What those trackers are tracking is irrelevant. They are tracking you and your usage, and get more information that way compared to if they only used backend tracking.
"This is standard for essentially any commercial app" sounds more like FUD that this submission, as that statement is obviously easy to check if it's true or not. In this case, I don't think it's true, as many apps don't do client-side tracking. I made a quick check for one competitor of lastpass (1password - https://reports.exodus-privacy.eu.org/en/reports/com.agilebi...) and they have 0 trackers. 1password is commercial and pretty big at this point, so your statement is not necessarily true in all industries/usages.
And I'm not sure you understand the term FUD. You're saying my comment spreads fear and uncertainty? It's literally the opposite, I'm saying this particular thing isn't something to worry about.
Mobile apps aren't like webpages where most actions generate backend calls whose logs can be analyzed as an alternative. If 1password isn't using 3rd-party analytics, they probably rolled their own. No big difference. In any case, my point remains true -- client-side analytics is standard for essentially any commercial app, in order to improve the UX. There are exceptions of course, like for any rule, but it doesn't change the fact it's still standard.
Yeah, my bad. I guess I assumed since you replied to the top-level story and not a specific comment, that you were answering to the story itself and not comments.
> And I'm not sure you understand the term FUD. You're saying my comment spreads fear and uncertainty?
No, I'm not saying that your entire comment is sounding like FUD. I'm saying that the specific part I quoted sounds like FUD, as it's easy to disprove it.
https://reports.exodus-privacy.eu.org/en/reports/com.agilebi...
Not to mention mobile clients even on Sailfish OS.
I keep my locked file mirrored in Google Drive and have an Android app to pull passwords. I really don't see how a casual user would find Keepass harder to use than LastPass.
I don't understand how Keepass is not more popular other than marketing. If you have a file with all your passwords for everything you really want to keep a local copy that won't expire. The current status quo seems like a disaster waiting to happen on the day LastPass closes down.
There is a ton of little polish stuff like that which makes it way harder to use for people with little tech experience, and I've had normal people struggle with more streamlined experiences like BitWarden.
Also, it's open source.
I still use bitwarden for personal use, but I didn't find the product (2 years ago) to be really enterprise ready. [biggest issue, when you share, you aren't sharing, you transfer your password to a group, this password is then no longer backed up, if you make a personal backup.]
The support issue was we had something go wrong with a group, and a dept. lost the passwords entered, but all the shares still pointed to it, so attempting to use it error'ed out.
I do wish we lived in a world where things had gone a bit differently and LAN had gained more of a role in all this, and one could pay for and run their own 1Password server. Of course for that matter passwords and they exist now shouldn't exist at all, it should all be public keys. Password managers themselves are a form of collective madness and horrible path dependency. And in principle 1P could maybe do some form of exclusive first party tracking and simply give up on whomever didn't talk to them. But for now at the least they still have the option to avoid dependencies on them pretty well.
----
I switched approx 2 years ago after the LogMeIn acquisition and haven't regretted it.
Recently, my spouse started using BitWarden on her computer, and she did almost all of the set up and migrating her passwords, and updating weak passwords (we paid the $10/year for the reports) without any help from me. She is above average knowledgeable with software, but having her ask me almost no questions made me think that the software for computer use is ready.
Bitwarden also supports self-hosting their service.
Switched to Bitwarden after Lastpass were bought and started tightening the grip I think (yep, I'm fairly sure they were testing the waters already 4 years ago).
Still pay Bitwarden (why not, the price is trivial for me at this point and they deserve it).
[1] Do these password managers even use their own keyboard, or rely on whatever insecure keyboard is installed on the mobile OS?
Alternatively you can use fingerprint unlock
Fingerprint authentication will work though.
Am I misunderstanding the issue?
I do not trust any android device with my vault for exactly that reason.
Why is this relevant? Even if you do have secure enclave, if you can do arbitrary memory reads a malicious app can simply wait until your database is unlocked and dump your database when it's unencrypted in memory. Moreover, if you have some sort of exploit that gives you operating system level access, you can simply impersonate the password manager app (eg. changing uids, or patching the executable in-memory) and get the secure enclave to do the decryption.
And is this a known problem of Android, that there are keyboards that can log your keys?
Personally, I still like using Simple Keyboard. It's the complete opposite of something like Swiftkey. does one thing and does it well, is super light too.
[1] Also because I deal with work on my own time.
Many of them support biometric authentication using Android's API.
Also, to enter the master password, all of them use whatever keyboard is installed, some of them send a message to them to work in "incognito mode" for what good that it. That said, for Keepass2Android and KeePassDX, they offer their own keyboard to enter secure credentials on sites you log into once your password manager is unlocked. That allows you to circumvent the system clipboard entirely, which is a major attack surface. Some apps also support the android autofill feature.
Without typos? Typing a tweet or text message into your phone, your thumbs hit somewhere near the right characters and your phone figures out what words you meant as you type. The uncorrected characters are often gibberish. This is a very different use case from having to get the case and special characters right for a 40 character password.
Bitwarden is able to produce diceware style passwords too.
Zetetic Codebook [1] is the way to go.
Pros: • It has desktop clients • It has apps • It has secure encrypted sync • It has responsive dev team • No silly subscription model
Cons: • It doesn't have a fancy web app (but do you need one ?)
I've no affiliation apart from being a long term happy user.
In addition, there are open source alternatives that have all the features you mentioned (namely the Keepass/Keeweb family).
> ...silly SaaS services like LastPass or Bitwarden?
...rather off-putting considering Bitwarden is nothing like LastPass in execution. For starters you don't need to pay for Bitwarden and you can run your own backend for self-host. Some of us use our password managers with others and would like to share things. I'm happy to pay for this feature.
So no, you're not required to leverage Bitwarden as SaaS like LastPass. They're not the same in that respect.
I have no affiliation with Bitwarden other than being a customer who dropped LastPass after the acquisition years ago.
I have been happily using Firefox's built-in password manager. Syncs seamlessly with Firefox Lockwise to provide complete integration with Android OS and presumably similar integration with iOS devices.
However, to be clear, Lockwise also ships 2 trackers[0], although one of those appears to be an in-house telemetry tool[1].
[0] https://reports.exodus-privacy.eu.org/en/reports/mozilla.loc...
[1] https://github.com/mozilla-mobile/android-components/blob/ma...
Some more back story. I tried to get help from LastPass when I noticed fields for saved accounts were blank or included strange characters. After 1 week of only getting an automated reply with how to clear your local cache (which did not work) and several more attempts from my side to get help without a response, I decided to cancel. I was locked out of my bank account until I realized that I could log into my web client directly on the LastPass website (stupid panicked me). This allowed me to easily export all my data and move to 1Password. Thanks LastPass.
Combined with an InputStick which emulates a keyboard to type a password from my phone into a computer it's plugged into, and I can efficiently get all my secrets around without involving anyone's cloud in an unencrypted capacity.
EDIT: I will note I've never bothered having browser integration though.
I'm not strictly sure this is entirely necessary these days because Syncthing will do collision detection and make copies, and keepass will prompt to merge if the file changes as well.
https://www.grc.com/sqrl/sqrl.htm
Disclosure: Started looking at it this weekend after hearing about it for a couple of years and starting to help contribute to various SQRL libs
https://sqrl.grc.com/pages/introductory_questions_and_answer...
It says "Using a SQRL app, a master identity is created and shared among the devices. Websites which support SQRL logon trigger the app to securely identify the user."
How does this happen? How can a website talk to an app?
Also where is the source code?
The talking to seems to happen through a custom sqrl: URI-scheme. That's something that's supported by most platforms I know of; Steam uses the same mechanism to start installing a game you purchased in the browser, if I remember correctly.
Source code for several implementations is linked in the explainer document from the home page: https://www.grc.com/sqrl/SQRL_Explained.pdf
I'm not sure if the Windows implementation is open source, but the algorithm itself is.
But I clicked around for a while and only found some videos that might show me what SQRL does, but I didn't actually feel like watching a video, so I still don't know.
Based on what I read, it sounds like snake oil so far. Too good to be true. I don't remember the phrase, but it suggested it would be my last password solution ever, which just sounds like snakeoil.
Also, it seems like only the Windows implementation is mature. All other implementations are by third parties and are marked as not being complete.
EDIT: A user posted a very nice write up of it in another comment: https://news.ycombinator.com/item?id=26314472
Right.
> A major downside is difficulty of backup. The private keys are locked inside the hardware and cannot be accessed in any way.
That's a feature, not a bug. You buy at least 2 keys (1 backup), ideally 3 (2 backup).
As for SQRL, I never took anything serious at grc.com/Steve Gibson. He was all about snake oil 20 years ago, and probably still is.
Why is this better than WebAuthn? It looks almost the same but WebAuthn has much more support. It can use software-defined keys like Krypton though certainly it would be good for browsers to have standard APIs for this stuff.
The problem with the solution chosen here is that this requires yet another app for authentication and yet another account for synchronisation of credentials. If this were to be built into browsers, it might replace traditional passwords in time.
How does SQRL work when it comes to apps? Does the Android app natively support other applications calling it to authenticate? What about authenticating devices that can't run the client application (smart TVs, for example), can they still access the accounts authenticated by SQRL?
Right now, SQRL seems to be competing with Webauthn, which has been built into browsers already, but does so through an external daemon running alongside the browser. I'm not optimistic about its chances here, to be honest.
The SQRL client registers the sqrl:// prefix to pass the login challenge to the SQRL client. The client, after a password or the pin (depending on if the password is present in RAM) is entered, responds to the server using signed credentials which are only valid for the domain being authenticated. That challenge creates a logged in session for the user and redirects back to the website.
There is also a QR code method of logging in, which depends on the user to confirm the domain name of the site being logged into. This is admittedly less secure, however, does provide some handy convenience when on an untrusted system by not requiring a user to give up their password. There are attacks that can be used to gain a session, however, these are thwarted when the on device authentication path is used (which requires some software to be installed on the users device)
> Are there any websites or services actually using this?
To my knowledge, there are not many (if any, besides the SQRL forums) working, live implementations out there. I played around with it and got it working on a couple of hobby projects over a weekend and it showed a lot of promise.
> The problem with the solution chosen here is that this requires yet another app for authentication and yet another account for synchronisation of credentials. If this were to be built into browsers, it might replace traditional passwords in time.
This is very true, but I believe SQRL as an open protocol will have long tail legs over time.
> How does SQRL work when it comes to apps? Does the Android app natively support other applications calling it to authenticate? What about authenticating devices that can't run the client application (smart TVs, for example), can they still access the accounts authenticated by SQRL?
At its core, SQRL is essentially a Challenge/Response mechanism. It would be possible for a device connected to a TV present a QR Code and have its session be authenticated by a device using the out of band HTTP request from the SQRL client scanning the QR Code (there are problems with this, like forwarding the QR code via a MITM attack to gain an authenticated session, however, the attacker only has a single logged in session instead of having access to a password that now needs to be changed, and any problems related to this MITM attack would also affect other user credentials like the email and password).
> Right now, SQRL seems to be competing with Webauthn, which has been built into browsers already, but does so through an external daemon running alongside the browser. I'm not optimistic about its chances here, to be honest.
Short term, I agree with this. However, long term I think WebAuthN is going to suffer from other problems which do not affect SQRL (user adoption of 2FA keys and user inconvenience in managing those 2FA items) SQRL provides some really nifty ways to transfer an identity safely to a host of other devices as well as rekeying an identity with the rescue code in the event an identity is compromised. It also doesn't require the management of those devices on any third party site.
Having now read a lot of their docs, they don't seem to acknowledge basic things at all.
For one, the identity string it generates for a site is static, and is the only thing need to identify/log you in. They never cover that this basically _IS_ a password. If you have a this static string, you have the password for that site.
Further it sounds like the website operators also need to store these strings as plain text. I don't know how their rekeying method would work other wise.
This means to me that if a websites database is stolen, then a person with that database could impersonate everyone immediately! No need to get a password cracker out at all.
A website operator would need to completely disable all the existing keys, requiring everyone to rekey.
They have a global rekey method, but all their single site methods documented are very very manual and only possible if the site accepted you're old key.
The global rekey method is also very scary to me. You need to visit a site for the rekey to happen. They state that after a rekey it will send your current and old key over. However how many keys will it send? What happens if I have to they N times because of different site data beaches. Will sites I haven't visited no longer be usable because their key is no longer available?
> For one, the identity string it generates for a site is static, and is the only thing need to identify/log you in. They never cover that this basically _IS_ a password. If you have a this static string, you have the password for that site.
The identity generated is a public key based on a private key in the identity. You do need one password, the master password for the identity on the device for an initial decryption to make the Challenge Response work.
> Further it sounds like the website operators also need to store these strings as plain text. I don't know how their rekeying method would work other wise.
What the website stores is a public key. Rekeying works via some other cryptographic methods to create new public keys. A server, presented with a previous public key and a new public key will replace the previous key with the new key. The new key can be confirmed as belonging to the previous identity, while not able to be regenerated by the identity without the rescue code. Full disclosure: Didn't really understand the math behind it, but that's the premise of the protocol. Securing that rescue code is extremely important and it should be stored separately from the identity (think at home with you birth certificate in the event your device is stolen while you are somewhere else).
> This means to me that if a websites database is stolen, then a person with that database could impersonate everyone immediately! No need to get a password cracker out at all.
The database only contains public keys of the user for the purpose of authentication. This table could theoretically be published, the compromise of the key does not compromise the identity nor allow a thief to log on (it would obviously not protect other information tied to the user like the email, address, etc. However, its a step in the right direction because it isn't a hash of a password to be rainbow tabled or the like).
> A website operator would need to completely disable all the existing keys, requiring everyone to rekey.
The compromise of all keys in the db would not compromise any identities. If a malicious actor changed identities to their identity, then there would definitely be problem, however, the operator could restore the public keys from backup and keep moving. This is not much different from passwords today, except that the user could no longer trust the password, no trust is lost in the public key.
> They have a global rekey method, but all their single site methods documented are very very manual and only possible if the site accepted you're old key.
This is valid. I'm imagining a perfect world with a correctly implemented spec. We can all work together to make it a reality.
> The global rekey method is also very scary to me. You need to visit a site for the rekey to happen. They state that after a rekey it will send your current and old key over. However how many keys will it send? What happens if I have to they N times because of different site data beaches. Will sites I haven't visited no longer be usable because their key is no longer available?
It would be semi-true that you would lose access in a world where software is the only intervening factor. The reality here is different: The public identity is string in the DB associated with the user. A website operator can have a user come in with their birth certificate and passport or whatever, verify a user, and change their public key in the database. This would be totally out of scope of the spec, not expected behavior, and potentially compromises perfect security, but the reality we live in is imperfect.
Everything, at some level, is going to come down to trust, and anyone with DB access can do anything anywhere anytime.
EDIT: I reread this again and realize what you are talking about is the string of the public key being stored, and potentially providing an avenue for an attacker to replace that string with their own identity in order to gain authorization of that user. I do think that is a risk, however, an attacker with DB access is probably not going to waste time impersonating users: they have access to the DB directly.
This would only be a problem in the instance a users data is encrypted and can only be decrypted by the user. So logging in as the user would grant some special way of seeing their data (though even here, if the server holds all the secrets, this isn't secure).
SQRL has an answer for this, as a private key can be stored with the SQRL identity to allow data to be accessed by the user who can also prove they have access to the identity. This would allow a server to reliably store sensitive information without worrying if the public key of a user got changed to allow a malicious actor to impersonate said user. I can only imagine this being leveraged for medical records or financial transactions, but a way is built into the protocol.
Most of my inaccuracies stem from the fast that I didn't see the challenge response part, it seemed like what the web services received was very static.
It would be very beneficial if there was a easy to digest document of the auth flow. something like this guide for kerberos: https://www.roguelynn.com/words/explain-like-im-5-kerberos/
Thank you for the writing prompt! I appreciate a chance to explain a little bit, which gives me a chance to make sure that I understood it as well :)
On a previous project the company I joined used LastPass as their password solution, we had 2 root admins, me and a senior colleague.
One day my senior colleague tries to log in to check/change a password and is unable to log in to his account. Account recovery/password lost doesn't work either. I log in to verify if his account is blocked or disabled in anyway, and I can't even find his account. The account was completely GONE. I checked the audit logs of the account (which should include user creation, deletion, logins, etc) and there is no mention of the account ever being deleted, it's like it never existed.
We contacted their support but never got a serious reply to this behavior, so we moved over to 1Password the next day and never looked back.
Stay away from LastPass, they just lose data out of nowhere and their support sucks.
https://community.bitwarden.com/t/remove-embedded-trackers-f...
> In the Mobile apps, Firebase Cloud Messaging (often mistaken for a tracker) is used only for push notifications related to sync and performs absolutely no tracking functions. Microsoft Visual Studio App Center is used for crash reporting on a range of mobile devices. In the Web Vault, Stripe and PayPal scripts are used for payment processing only on payment pages.
Compare this to LastPass where it was feeding data to Google Analytics and MixPanel, which do much more invasive levels of analysis in general.
Also, Firebase Cloud Messaging is the only way to have push notifications on Android.
Using either of their products ( outside of Firebase Analytics and maybe Firebase Auth) isn't tracking users and isn't harvesting user data. It's using tools to make apps, that's it.
Google is a malicious actor as a result of their business model and has already demonstrated their willingness to breach the GDPR with the non-compliant tracking consent prompts they use on their services, so it isn't that far-fetched to believe they can also use data from other services in ways you don't expect, especially when they can have plausible deniability.
[1] https://firebase.google.com/terms/data-processing-terms#5.pr...
[0] https://github.com/bitwarden/browser/issues/320
PS - If this issue does not occur for you personally, great but it does not for me and many others. Thus, it is unreliable.
This setup seems fine for me. It seems faster and snappier than Lastpass, but that might just be down to the fact it's hosted on my LAN. All in all, I'm happy I moved and happy I'm now in control of such sensitive information as my passwords.
Autofill is relatively poor (it fails even on HN!). Also, Lastpass has a convenient timed expiry that doesn't work (well) on Bitwarden (BW will expire the login when the browser is closed).
All in all though, I do support the recommendation, in particular, because Lastpass works extremely poorly on Firefox (at least, that's what caused my switch some time ago).
Huh, weird, it works fine for me in Firefox.
Autofill is much more customizable than LastPass afaik. You can both define how (domain)name matching should occur as you can have multiple entries to match.
This means you can have instagram.com (as website) and androidapp://com.instagram.android (as app) which will use the same autofill entry.
If you configure name matching correctly, any site should be able to provide autofill. My HN entry does match with news.ycombinator.com with default matching settings. But matching settings include hostname / domain name / starts with and even regex!
> Also, Lastpass has a convenient timed expiry that doesn't work (well) on Bitwarden (BW will expire the login when the browser is closed).
You can specify BW timeout settings. Even further, you can define if BW should lock the session (only a password is required to unlock) or if a sign-out is required. With a sign-out, you also need to provide your MFA if applicable.
Time outs can happen directly (after autofill), after an amount of time (1/5/15/30 minutes or 1/4 hours) or upon closing the browser.
So tbh, there is plenty to configure Bitwarden to suit your needs.
In what context? I found Autofill poor on Android for FF before I gave it the "draw over other apps" permissions. Otherwise I've only seen it fail on a few sites out of hundreds, mostly with weird login flows.
As for Bitwarden locking (expiring) when the browser is closed, I disable that as my system is secured so locking the vault in the browser is overkill for me.
My only real complaint with Bitwarden is the macOS app lacks TouchID support.
HN Autofill works perfectly well for me with Firefox + Bitwarden extension on macOS (I know it also works with other combinations). If it does not seem to work, select a password field. Does it for me.
https://github.com/bitwarden/desktop/issues/552
The issue has been reported and they refuse to fix it.
This bug renders the Bitwarden encryption irrelevant, as the Bitwarden devs can always access your passwords regardless if they choose.
The Bitwarden devs can always access your passwords at any time if they choose to do so, as a result. This, to me, is as serious a vulnerability as lacking encryption in the first place.
Alternately, brute forcing the client password is straightforward due to their use of a too-fast KDF and low iteration count.
You're also right about the KDF but to be fair to them the devs say they'll accept work from a fork[0] to Argon2, if and when it's done (properly).
[0] https://community.bitwarden.com/t/switch-to-argon2/350/24
I'm not sure where the rest of your questions come from. "Do you not upgrade them ever?" does not logically follow from being opposed to the major security vulnerability that no-interaction automatic binary modification poses.
- You're on Windows and not using the Windows Store version or a "portable" version of the application - You're on macOS and not using the app store version - You're on Linux and you're using the AppImage version
Given the security-sensitive nature of the application and the target audience (mostly non-technical people), I think it's not a bad thing that this software has auto update functionality.
If you want to be free of this behaviour, you can either install the application through your system package manager/app store so you can control the update behaviour there, or run a development build of your vetted version of the source code.
If you simply reboot your computer, the new code executes.
Even still, auto update is a feature, not a vulnerability. It's the only way to get non-technical people to patch their software because people are afraid of change. Even if there's a huge vulnerability in Bitwarden, tons of people won't click the "yes update please" button because they're afraid updates change the way the tool works or break something.
Autoupdate is fine, so long as it's opt-in. It is a massive vulnerability if not, amounting to the same control as a standard remote access toolkit: full RCE.
> It's the only way to get non-technical people to patch their software because people are afraid of change.
Not only is this a factually incorrect statement, it also contains a presumption that Bitwarden's developers have some right to decide for the end user what software runs on their computer, when the end user is the final authority, for better or worse, on what code is allowed to run on the hardware they own.
I run a fork of the client now anyway, and bitwarden_rs on the server. I didn't want to deal with it but the dev responses to security reports are terrible.
Your phrasing and tone are quite harsh as others in that bug commented and seemingly agreed by the community judging by the fact you got more thumbs down reactions than thumbs up. Combined with the fact you're not even a paying customer, you really need to evaluate whether your approach was appropriate.
One very important feature for me is having a command line interface because I have a bunch of scripts that need to be able to query the password manager. Fortunately bitwarden provides a first party CLI that seems pretty fully featured, so I was optimistic.
Anyway, I try to install bitwarden-cli through AUR and I see that one of the dependencies is nodejs.
Oh no.
Right so it's a javascript thingy. I'm a bit shocked, but then I decide that I'm being silly and it's what all the kids use these days and it's just a programming language and who cares. So I decide to push forward and install the binary version of the program (installed size is 65MB, as a comparison point lastpass also provides a CLI tool written in C that's 0.2MB installed).
Since I don't know how the tool works, I decide to launch it without argument to get the usage. It takes 0.6 seconds to display the usage. That's with a hot cache.
Oh no.
So that's the story of how I kept using pass. I know that some people will say that it's not that big of a deal, and I know that for bitwarden's devs it might make sense to implement their client that way because it lets you reuse some code and get good portability, but I just can't even. I'm running on an overclocked desktop computer capable of executing billions of instructions per second, I can play 4K videogames at 60 fps but apparently I get 1.6 UPS (usages per second) with this tool. It unironically makes me sad that this is the state of software engineering nowadays.
Reading this thread it seems like it's a mess when it comes to privacy too, so I suppose I dodged a bullet.
I didn't even know LastPass had a CLI, but it seems like it's a rewrite of the algorithm and surrounded toolset in C.
I can understand why the Bitwarden devs didn't want to go through the effort, though. The tiny minority of Linux-users that want a command-line password manager is not exactly worth a lot of development time, so I figured they just put their JS library in a NodeJS application and called it a day.
Since I do this multiple times per day I wrote a simple bash script that invokes Anyconnect and supplies the VPN credentials it pulls out of my password manager. I alias this script in my shell environment so it's as simple as typing "vpn" to get logged onto the corp network, saving the hassle of mousing around to get onto the VPN.
As for my workflow I don't have any auto-fill on my browser, I just use "pass -c my-password-entry" to put it in the clipboard and paste it from there. It's arguably less secure than having it autofilled I suppose, but it hasn't been an issue so far (and pass clears the clipboard after 45 seconds to mitigate the risk).
Then I have a bunch of scripts for starting my VPN connections, my email client etc...
I should add that my pass's GPG key is stored on a yubikey and I need to physically press the button to decrypt, so that adds a pretty good layer of protection.
So yeah, I realize that my use case is incredibly niche, but I do think that being able to use your password manager in scripts could be useful in some cases even for people who are less enamored with the terminal than I am.
For example something like
curl -u user:"$(pass SomeSecret)" https://api.website.com
Nice usage.
You could also use HISTIGNORE variable, history -d, or unset HISTFILE. Here are some examples [1]
[1] https://www.rootusers.com/17-bash-history-command-examples-i...
However, I found https://github.com/doy/rbw , and alternative OSS cli written in Rust, and it's exactly what I wanted. (Disclaimer: I liked it so much I wrote a rofi integration for it.)
I like almost every part of the experience except an annoying issue where the autofill doesn't work on firefox android (everything latest version). it shows up 10% of the time, for a few milliseconds. I've seen similar issues dating back from a year ago (https://github.com/bitwarden/mobile/issues/784). Makes me wonder how such commonly used things can be so broken for so long (see also https://news.ycombinator.com/item?id=26296339).
However, unrelated to this specific case, I believe that mobile apps could be the one place that adblocking cannot be guaranteed to work. When things get byte-compiled, you can no longer programmatically inspect the interface and remove malicious ads like with the browser's runtime. Imagine a future where a critical feature you have to use like banking is only available through a mobile app, and this is enforced through something like a certificate check. Then they run ads over it.
DNS based blocking is not infallible either. Even today it does not work with the YouTube app, because their ads are served on the same domain as the content, so blocking one means blocking both. The only solution people have come up with is reverse engineering the official app's source code and releasing a modified version, a process that consumes far more time and effort than using something like uBlock. And this was only prioritized and accomplished because YouTube has become that important of a platform to enough people.
If there's a future where our lives depend on compiled apps, will enough people go through the same effort to sanitize all of them?
https://reports.exodus-privacy.eu.org/en/reports/search/com....
BTW CrashLytics/Firebase Analytics are a de facto standard in every Android app if you want to roll out the new versions responsibly so I'm less worried about it than some random unknown company (though this cements the Google monopoly, so yeah it sucks).
FWIW they do conduct regular security audits and post it at https://support.1password.com/security-assessments/ . The most recent one was done by Cure53 in 2020-Oct [1].
I've been a happy 1Password Family user for a few years now. Very easy to share common account login credentials, important documents etc with the family.
[1] https://bucket.agilebits.com/security/Cure53-B5_1PW-06-repor...
LastPass has been a clown show for years. Unbelievably sloppy work.
Security wise they're probably about the same, if you use the cloud vault. Ok, 1Password is slightly more polished than bitwarden but it's not 3.6x (36usd vs 10 usd) more polished than bitwarden.
I think for a security product the onus is on the author to show that this can't happen (not just that it doesn't), which means either not having trackers (easy) or somehow showing that trackers are isolated from the sensitive data (hard).
This isn't uncommon. Apple have published a bunch about how they do iOS security, and it's quite clear that there's strong sandboxing between untrusted code and sensitive data, in some cases even enforced at the hardware level.
I do. Some don't. Some do.
So give the user the choice instead.
I also wonder if this is even GDPR compliant...
Sometimes I also copy the db to my phone over gvfs (kdeconnect / gsconnect) from the command line so I don't have to start Syncthing.
KeepassDX on Android sets a AndroidApp attribute when an entry is used to autofill, because sometimes there isn't a website to match, so the com.X.Y format of the Android app's name will be used from the attribute next time.
As a bonus, KeepassX on desktop reloads the DB automatically once syncthing syncs the changes, so you don't have to reload the DB manually after adding/changing an entry from your other devices.
I am doing the same. With security, I feel that there is value in simplicity and even a little inconvenience.
No program which knows your master password and which has network access can ever be considered secure.
In that sense, they're just more secure than using a single simple password across multiple (potentially all) your logins. Or at least that's the goal...
I just never save my core Google password and bank passwords in a password manager, and a willing to risk the vanishing possibility that my password manager might be evil or dumb. Also I am fairly aware of my deal with the devil with regards to having Google manage most of my online information.
It's just LastPass that's uniquely bad. I don't understand how they are still in business. Their security track record is a series of embarrassments. Their UX is poor. Their browser extensions slow down the whole browser. And apparently their privacy is also suspicious.
But OTOH Firefox Lockwise/Sync is client-side encrypted, and the server just holds an opaque data blob for you.
Dunno. UX was okay, it was easy to use. They were very responsive to fix security bugs (you can't blame having a security bug, but you can if they ignore it. Otherwise you should start by ditching your favourite OS)
Former Lastpass user.
For products this critical, that handle a relatively large amount of per-user data, inertia is massive. Once you get used to it, the thought of moving tens or hundreds of items to another service is daunting, for the average nontechnical user. (Yes, I know it's just "export this, import that", but for nontechies even the first step can be scary - "what is this thing I get? Am i deleting stuff? Where do I save it? Is this the right format? ..." etc etc). They had a couple of wobbles, "so what? Everyone gets hacked, even Facebook".
I've moved to Bitwarden years ago but I know I'm niche.
Back when I used lastpass that's also how they handled it (you can read through their open source command line client to see how it's implemented under the hood, it's fairly straightforward).
I agree that its UI was pretty clunky though.
For what I have understood they store on their servers only an encrypted version of the passwords data. The encryption key is randomly generated from 12 words, that are not saved on their servers. Each new client that you want to connect to Dropbox passwords must be authorized by an existing client. I believe that it is at that time that the key is shared with the new client (if approved).
Is there someone here from Dropbox that could confirm this?
As per security, IMO this is currently the best compromise between security and usability.
1) the Netflix tier where my wife and in-laws are going to be sending it around insecurely and I don't really care what happens
2) the Random Bullshit tier where I really can't be bothered to remember another password
3) the Google and Financial tier where it's going to be a nightmare if it's compromised
The largest set is (2), and having a password manager for this one is extremely useful. I've tried prefix and mnemonic systems, but it can be a real hassle if it turns out you need to only use it a couple times a year and have to adapt for dumb character and length requirements. Having a manager for (1) is great too since I'm probably using it on multiple devices.
I don't put passwords from (3) anywhere and their knowledge will die with me.
I like the idea that it's a standard way to store passwords that can be easily manipulated with whatever tools you like, including git.
But I've mostly switched to using the dmenu script, since it's much more snappier and available everywhere.
And then wonder when they are being extorted ("you better subscribe and pay or else!"), datamined (article) or have their data stolen (LastPass was hacked before).
People, stop giving these businesses the loaded guns to hold at your head! There are plenty of offline password managers that will do you equal or better service than this.
That's cool, I didn't know that and I'm eager to hear of replacements. I regularly use 5+ devices, currently all via 1password and have about 3 family members including myself using 1password (so in total maybe 10 devices or something like that). None of us want to host a server by ourselves (as both time and security is of a concern there). What do you suggest we use in my household? Would have to work on Windows, Linux, macOS, Android, iPhone, web and unix terminals. It should be able to store passwords, photos, credit cards and also have browser extensions for Safari, Firefox and Chrome for making it easy to fill out. + if it has a password generator as well, but not required.
Many thanks!
For cases where you really can't use an offline password manager (e.g. because you are using some sort of gadget that doesn't allow you to connect to Google Drive or whatever), sync the relevant (not all!) passwords using your browser account.
Why is the above better than your 1password, LastPass or something else? Well, I don't need to take the company at their word that they are properly encrypting the file and properly protecting it - I know it is because it has been encrypted locally by Keepass (easy to check, the source code is all available too).
Google only ever gets to see a binary encrypted blob. And if I need to move to another service (e.g. I have been using Dropbox before), I simply move the file, that's all. No mess, no fuss. My data (especially passwords!) aren't held hostage anywhere.
That said, I use NoRoot Firewall so these are not problems. I make a global Block rule and I get rid of them 'nice folks' for everything (stock, bloatware, apps) on the phone.
Also, if you can edit/replace your HOSTS file I always suggest this: https://someonewhocares.org/hosts/
Less convenient for passwords in native apps, but still usable.
but it's commonly used with OpenKeyChain, which does have a tracker: https://reports.exodus-privacy.eu.org/en/reports/org.suffici...
In defense of trackers: knowing what features your users use and don't use is a huge deal to decide where to spend time on and where not. This doesn't cease to be true when software is open source. Giving users a simple way to give feedback of how they use the app is totally fair. Similar to how distros collect stats about installed packages, you wouldn't stop using Debian because it had an opt-in mechanism to send such stats upstream.
That said, multiple trackers is ridiculous, and by multiple third parties no less. I can understand that the abuse of tracking due to blind optimization for profit leads users to adopt a "trackers are generally bad" stance, since more nuanced views quickly get complicated.
I deleted my account to send a message to the Pointy headed bosses running LastPass that you can only squeeze a customer so much. Also -- aren't the people who use LastPass are by default privacy and security conscious and actually paying for added security and convenience? And the morons decided to violate our trust.
I get it - if you want to minimize your contact with trackers you do you. But this is being marketed as some kind of scary security breach so people switch from one proprietary product to another.
They also have native Linux app and their browser plugins are good. Of course they still have plenty of critics, but I just don't think my family would use Bitwarden yet.
Is Lastpass a widely trusted thing? other than the obvious refrain: "of course it is - its a password manager"?
Is its security known for being well regarded?
They've been the target of security breaches in the past and are currently receiving bad press because of a bait and switch they did with users on their free plan.
What LastPass did was they removed functionality of a free plan -- functionality which they had for several years (I think over 5 years now) and then decided to remove it, most likely because they thought the marketing value of the free plan was no longer worth the potential sales cannibalization. (I'm not an employee and have no inside knowledge). This is a straightforward business decision that firms do all the time. You can always take your zero dollar business elsewhere.
I wouldn't consider LastPass to be the most secure password manager, and I'm not sure I would recommend them as my favorite, but they are very easy to use, are the market leader, and it is important that they stay in business, as on balance these password managers do improve the overall security of the web.