LastPass Android app has got 7 trackers in it(reports.exodus-privacy.eu.org)
reports.exodus-privacy.eu.org
LastPass Android app has got 7 trackers in it
https://reports.exodus-privacy.eu.org/en/reports/165465/
255 コメント
LogMeIn was bought a few years ago by a private equity company. The standard PE playbook is to buy things that are popular and stable but maybe not growing like this and then milk them for all they can, particularly in things that are hard to move away from (see Travis CI).
I knew that LogMeIn had acquired LastPass, but I didn't know that private equity had gobbled up LogMeIn (which used to be publicly traded on the stock market).
Apparently the private equity deal was only finalized in August of last year, see:
[1] https://www.nasdaq.com/press-release/francisco-partners-and-...
Apparently the private equity deal was only finalized in August of last year, see:
[1] https://www.nasdaq.com/press-release/francisco-partners-and-...
I'm sorry you feel like someone waved a gun at you or held your accounts hostage but damn this comment is entitled. You are talking about a _free_ service that runs on physical and expensive servers. It even offers an easy way to export your entire account in a csv. They are not doing anything wrong here other than trying to stop burning cash.
The cost of storage is marginal, 1 subscribing user subsidizes 100-1000 free users. The encryption computation is offloaded to the client as well. That's why this service is a profitable recipe for freemium. I'm sorry you're sorry about the parent commenter's experience.
No need to feel sorry for me ;-) Personally, I am used to that, I've been in IT for too long. But I can indeed imagine that some people experienced some anguish over this.
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).
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).
LogMeIn did the same. They became popular because they have a great product that was free to use for personal matters.
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 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.
And then TeamViewer did the same, and if you accidentally connected to a Windows Server OS, they locked your account :-(
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).
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).
I just use it to connect to my friends and family, I think the only thing is they cut the connection at 45 mins but that is it.
Complaining about storage costs seems weird, when data generated by those trackers is literally orders of magnitude larger.
> You are talking about a _free_ service
The irony of claiming this is a free service when the service uses 7 trackers. The free service is a product!
The irony of claiming this is a free service when the service uses 7 trackers. The free service is a product!
Look again. ~~These trackers are not for advertising~~
Edit: I'm actually not sure about all of them.
Edit: I'm actually not sure about all of them.
Are you a lawyer? Just kidding. But I ask because you are technically completely correct and have just secured an acquittal for LastPass on a pure technicality ;-))
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.
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.
AppsFlyer, Google Analytics, Segment are in there.
There are ways to monetize a free service further and some are better than others.
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.
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.
If customers had known this would happen when they put their data on LastPass, I think I would agree with you. In this case, LastPass is using a classic bait and switch tactic on their customers, which seems within their rights but is definitely not earning trust or loyalty from anybody.
Look, I get where you're coming from, but LastPass's behavior is just not clever at all. Frankly, if I had to think of a better way to antagonize my users with 100% certainty, I couldn't have done a better job myself (short of disabling free accounts overnight).
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?
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?
> OTOH, if you treat your free users with respect
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.
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.
A number of alternatives were mentioned in this thread. User referrals; a better fleshed-out premium tier with actual added value without deteriorating the free tier; a longer transitioning period; a less ridiculous either/or (forcing users to decide between mobile & desktop, wut?); more pricing/tier differentiation; a genuine enterprise solution that finances the free tier and creates brand awareness and a good image; offering a self-hosted version at a higher (approx. 24x monthly pro payment per user) one-time price point for individuals, education, SMBs or a higher price for larger companies. This is just from the top of my head, and I'd argue that any one of them would've been better than this severely strange cause of action. There are endless ways how this could have been handled better without damaging the brand or user trust (if that ever played a significant role).
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. ;-)
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. ;-)
> this comment is entitled
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.
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.
In principle I agree.
I certainly don't think they used to be evil, they set out do create a product and brand that stood for safety and security and trust.
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...
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...
I was actually using their free tier for awhile (the Pro version didn't have any extra feature that I personally needed anyway). But when they pulled this bullshit counting on how useless the free tier will be and basically forcing the upgrade, I replaced them in like 5 minutes.
Yep, exactly. I have no problem with gentle reminders to check out pro features. Or maybe a recommendation engine ("Refer 10 of your friends to us and we'll give it to you for free"). Or making it clear to new users that the service tiers are now different and grandfathering-in the legacy free tier (like Gsuite used to do).
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.
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.
I also moved to Bitwarden as a result of the new policy. The UI is equily bad but I feel more secure using an open source tool that will not change their policy whenever their execs want more $$$
Also the LastPass desktop client was beyond slow.
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.)
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.)
AnyDesk is the spiritual successor for TV! Highly recommended.
Why is this an issue?
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.
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.
First, who said it's an issue that you have to care about? People feel different things are issues.
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.
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.
Of course facts aren't FUD. I'm responding to a lot of comments here which assume this is a bad thing, which I think is obviously why it's being upvoted as well.
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.
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.
> I'm responding to a lot of comments here which assume this is a bad thing
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.
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.
Compare it to 1Password with it's 0 trackers.
https://reports.exodus-privacy.eu.org/en/reports/com.agilebi...
https://reports.exodus-privacy.eu.org/en/reports/com.agilebi...
I was just about to pay for my LastPass subscription (after years on being on free tier), given the recent price changes. This made me change my mind - why a password manager, which I entrust with my personal passwords, notes and credit card info, needs to dial home to 7 different trackers is just beyond relief.
I like LastPass because it works across my phone and multiple machines / browsers (I use Firefox). Can anyone please shed some light on good alternatives? I will happily pay for it.
Bitwarden is open source (with $10/year for some extra nice-to-haves if you use their hosted cloud service) and better than LastPass for me personally in pretty much every respect.
I switched approx 2 years ago after the LogMeIn acquisition and haven't regretted it.
I switched approx 2 years ago after the LogMeIn acquisition and haven't regretted it.
Been hearing good things about bitwarden, just switched in about 2 minutes. As a password manager, Lastpass hasn't really improved with the times, infact it's been getting buggier and buggier with Chrome as times goes on.
It's bee a couple years but the web browser plugins for BitWarden were unreliable. Our power users made it work but our average office user complained non-stop and moved back to using notepad. Maybe BitWarden has improved since then but it was too immature to rollout to the average office user.
I started using BitWarden during their rough phase and can agree it was a struggle. On the computer it is now flawless except for the very occasional web site that codes far enough out of standards that any normal heuristic cannot detect that there is a prompt for credentials being shown. On mobile, it is still a bit hit or miss. I'm on Android 10 (awaiting the OnePlus release of Oxygen OS 11 for my model) and the Firefox Add-on is really good, but there are still places where detection of logins isn't quite right. And in apps on Android, it's also hit or miss. Venmo, for example, required me to do a long press, hit the ellipsis and choose autofill. That's fine for a power user and generally a bit beyond what an average office user would find acceptable. Though I don't have comparison to alternatives - it may just be that these apps aren't "behaving" well with the Android autofill service, and you can't blame BitWarden for that.
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.
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.
I've been using Bitwarden for a few years and have never had to tweak it. It's not as good as LP was at detecting new logins and the mobile app sometimes doesn't detect password fields but overall it has worked fine. In the cases when it doesn't detect it's not hard to copy / paste.
How does Bitwarden.rs[0] (RUST IMPLEMENTATION) relate to the open source Bitwarden and its hosted cloud service?
[0] https://github.com/dani-garcia/bitwarden_rs
[0] https://github.com/dani-garcia/bitwarden_rs
I know this topic is old by now, but the official bitwarden server is pretty heavy-weight for selfhosting (mssql db, needs >1gb just to start),so some people thought they could do better. This seems to go well because bitwarden is completely open source. But bitwarden_rs is not affiliated with bitwarden and is missing some features from the official version. The bitwarden team seems to also look out for those alternative solutions a bit, notifying them about breaking APIs and so on.
I also switched from LastPass. I find the Firefox Extension and Android experiences in Bitwarden much more intuitive. The autofill on Android works far better in my experience too.
Bitwarden also supports self-hosting their service.
Bitwarden also supports self-hosting their service.
I was an (on and off) paying LastPass user until 4 or so years ago, not because I had to, but because I felt like supporting it.
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).
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).
> Can anyone please shed some light on good alternatives?
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.
https://www.mozilla.org/firefox/lockwise/
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.
https://www.mozilla.org/firefox/lockwise/
Same, I've been very happy with Lockwise, with only a couple of UI complaints here and there.
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...
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...
I wish Lockwise was available on other browsers too. It really is a great app.
KeepassXC plus some file sync tool works great for me across multiple devices (Android, Linux, Windows)
I wouldn't recommend it for casual users as there are definitely things that are less polished about the way it works, but for power-users it is great. The SSH key integration is really good.
Is it though?
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.
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.
Sadly the simple act of choosing where to save a file, understanding where that is, and remembering that, is more than many people feel they should need to do. Signing in with an email address and guessing their own password (typically one of the three passwords they share across all of their online services) is the norm.
The way the browser integration works means it just sometimes doesn't pick up that the app is open.
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.
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.
iOS?
Last I checked, there were some third party iOS apps but the Bitwarden iOS app was far superior.
I have found KeePassium to be an excellent iOS KeePass client.
Strongbox is good on both iOS and macOS...
KeePass only officially works on Windows. All non-Windows versions are unofficial versions. See [1] for a list.
[1] https://keepass.info/download.html
[1] https://keepass.info/download.html
There's also KeePassX and KeePassXC which have been working fine on Linux for years.
- https://keepassxc.org/
Not to mention mobile clients even on Sailfish OS.
- https://keepassxc.org/
Not to mention mobile clients even on Sailfish OS.
KyPass has been excellent for me for the last several years.
1Password is by far the best on iOS, and it works on Mac, PC, Linux, and Android as well.
1Password is the best I've seen out of several alternatives. Works flawlessly on all devices, great syncing, great UI. Highly recommended, well worth its price. Easy enough to set up that I've helped a few relatives around age 80 to get it running.
Bitwarden is great. I got work to buy an enterprise license, which also gives me a full license for personal use.
Also, it's open source.
Also, it's open source.
have you actually tried to use their support, it was a single guy, who wasn't helpful, when I asked for a different rep, he copped an attitude.
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 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.
Firefox's built-in password storage?
Not sure how secure it is, and if you need your passwords in other apps, you can download their LockWise app.
How well does it work on iOS?
It integrates with the system password manager interface but it's sometimes a bit slow to start. I think the problem is that it updates the passwords every time it is opened instead of relying on cached copies. Other than that it works fine.
It doesn't integrate well with iOS but if you are willing to use Firefox for iOS over Mobile Safari, it works pretty well.
Firefox has been a great web browser for me, as the synced tabs over devices has been useful. And while Google still likely has some of my data, I've switched to DuckDuckGo and Firefox full time now.
I moved from LastPass to 1Password some time in early 2020 and never looked back. The browser add-in alone on 1Password is SO much faster that I feel it alone has saved me a bunch of time.
I did the same, however I wish 1password would keep my extension logged in instead of asking me to type up a convoluted password every time I open the browser.
You can update your settings for it to turn off locking (while using the browser, idle, or sleep). However, if you quit the browser completely you'll have to re-login.
How does one realistically type in the master password on a phone keyboard [1]? A secure password would be like 20 characters long with a mix of alphanumeric and special characters.
[1] Do these password managers even use their own keyboard, or rely on whatever insecure keyboard is installed on the mobile OS?
[1] Do these password managers even use their own keyboard, or rely on whatever insecure keyboard is installed on the mobile OS?
My MP is more than 40 chars long, but it's not really a chore to type it in considering we are texting much longer strings than that literally all the 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.
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.
> [...] considering we are texting much longer strings than that literally all the time.
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.
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.
Without typos. I use a keyboard that has no predictive features, swiping, or suggestions. But I understand your point. Personally I found training myself to type accurately worth it but most people may not.
What's wrong with typing in 20 characters on a phone keyboard? My password is longer than that and I don't have an issue
Alternatively you can use fingerprint unlock
Alternatively you can use fingerprint unlock
Because it takes a long time. On the rare occasion I log into something on my phone, it takes almost a minute to type in the random passwords that Keepassxc on my computer generates.
Fingerprint authentication will work though.
Fingerprint authentication will work though.
Once you're logged in, just copy/paste the password? You only need to type out your master password manually.
Am I misunderstanding the issue?
Am I misunderstanding the issue?
On Android you should not copy/paste as all apps can read the clipboard. Use either a keyboard that comes with the password manager, or system auto-fill support that gets the values from the manager. Both modes are supported at least by Keepass2Android.
I use diceware to make a master password that's reasonable to type on a device.
Bitwarden is able to produce diceware style passwords too.
https://theworld.com/~reinhold/diceware.html
Bitwarden is able to produce diceware style passwords too.
https://theworld.com/~reinhold/diceware.html
[deleted]
The other question would be, how do you handle this without a password manager?
And is this a known problem of Android, that there are keyboards that can log your keys?
And is this a known problem of Android, that there are keyboards that can log your keys?
Personally, I don't trust Android and all the crap installed in it at all. So, I do very limited secure activities on my phone. I have never logged into my email on my phone, for instance [1]. The only thing private is messenger apps, which is an unfortunate minimum requirement on social life. Always looking for a way out.
[1] Also because I deal with work on my own time.
[1] Also because I deal with work on my own time.
I use Simple Keyboard (based on the AOSP keyboard), which is a very basic FOSS keyboard with no logging, suggestions or any of that. Other good options with more features most people want are OpenBoard and AnySoft. Hacker's Keyboard is a decent one too.
Related question: Does anyone have any suggestions for an OSS keyboard with suggestions and (good) swipe functionality? I currently use Gboard and it's great, but, well, it's a Google product.
The FOSS keyboard with the best swipe functionality is AnySoft. But it is miles behind SwiftKey and Gboard in my experience. With some patience and training it is serviceable though.
This is why I stick with SwiftKey. Nothing beats it, and although it got bought by Microsoft, they did not Frankenstein it. If you look for the app start with the 'M' of Microsoft though.
Yeah, I think SwiftKey with a firewall blocking outgoing requests is the most feature-rich keyboard experience on Android which isn't outrageously privacy invasive
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.
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.
You can use a fingerprint to authenticate on Android.
The problem is, most if not all Android devices do not provide some secure-enclave like architecture where the crypto key to unlock is secured by hardware design, but rather simple software solutions where the master unlock key resides in memory. So if you happen to have any malware combined with a security exploit, they might access your vault without requiring a fingerprint.
I do not trust any android device with my vault for exactly that reason.
I do not trust any android device with my vault for exactly that reason.
>The problem is, most if not all Android devices do not provide some secure-enclave like architecture where the crypto key to unlock is secured by hardware design, but rather simple software solutions where the master unlock key resides in memory
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.
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.
"wait" means run in the background. Once more this is not possible on iOS.
This is incorrect. There are multiple ways of running tasks in the background eg. https://www.raywenderlich.com/5817-background-modes-tutorial.... Moreover, if you have sandbox escape (probably a prerequisite for getting arbitrary memory reads) you don't have to wait because you can use the other methods I've mentioned in the second half of my prior comment.
This is just completely incorrect. https://developer.android.com/training/articles/keystore
It says that secure enclave is optional. Do you know of any vendor that ship hardware based secure enclave? AFAIK there are no major vendors that actually do this, so this is just operating system level protection, not hardware based.
Keepass2Android can install it's own keyboard.
I moved to 1Password last month after LastPass sync got corrupted and the data would not populate my Firefox extension or my iOS app. 1Password has been an excellent replacement. I had a paid family account with LastPass previously.
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.
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.
I've been using Keepass for years now, combined with Keepass2Android on my phone. I recently (finally) got that setup working perfectly by setting up Syncthing between my phone and computers.
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.
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.
Be very careful with the keepass Syncthing combo. If you're not monitoring which one had changes, you could get it overwritten when you don't want it to.
Controlled for! Keepass2Android prompts and merges if the file changes out underneath it. Regular keepass each machine uses its own file in send only mode, and synchronises to the main file which is in send-receive mode on save.
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.
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.
1Password is a dream compared to my experience on LastPass.
1Password. Zero trackers.
Do you know that or are you assuming that?
By the same Exodus service: https://reports.exodus-privacy.eu.org/en/reports/com.agilebi...
In addition to sibling poster, and while they've gone in an unfortunate cloud sub direction overall, it's still possible to buy an entirely standalone non-subscription normal license for 1Password and sync vaults via Dropbox, iCloud for those in the Apple ecosystem, a folder, or manually via WiFi. You can then use an application firewall or anything similar to monitor all network connections. At least from what I've seen 1Password makes only the expected connections needed for their own services for things like auto update checks, Watchtower (a typical local compromise check system with k-anonymity, their page here [0]), and sync. All of them can be disabled with no effect beyond the expected of those functions not happening.
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.
----
0: https://support.1password.com/watchtower-privacy/
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.
----
0: https://support.1password.com/watchtower-privacy/
How about cutting the cord on silly SaaS services like LastPass or Bitwarden ?
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.
[1] https://www.zetetic.net/codebook/
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.
[1] https://www.zetetic.net/codebook/
I find a comment like:
> ...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.
> ...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.
Personally I'd much rather use Bitwarden due to their fully open source nature, and possibility to self host if they ever go down the wrong path.
In addition, there are open source alternatives that have all the features you mentioned (namely the Keepass/Keeweb family).
In addition, there are open source alternatives that have all the features you mentioned (namely the Keepass/Keeweb family).
I use Codebook which uses opensource encryption libraries developed by them. Liking it so far.
If you haven't heard of it, I highly recommend checking out SQRL (secure quick reliable logon). It solves the problems of Identity on the internet in a nice, convenient, and decentralized way. While it isn't going to be widely adopted for a while, we should be talking about it anytime we see trackers in password management apps or breaches of websites.
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://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
This looks very interesting. Are there any websites or services actually using this?
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 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.
I just realized my first reply did very little to answer your questions, so I'll take a look at them one by one here:
> 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.
> 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.
The four PDFs present on the SQRL page to a better job explaining than I will here, however I'll summarize a bit:
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)
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)
This is interesting stuff, but as others have said they do a really bad job of presenting the what it does and how it fits it.
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?
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?
All of these points have inaccuracies, and I'll run through them one by one:
> 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.
> 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.
I really appreciate your thoughtful and thorough response!
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/
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/
Def agree! Might try to look into doing this in the future.
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 :)
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 :)
Thanks for the pointer, but I'm initially very skeptical. Not to judge a book by it's cover but that website looks like it was made in 1990. They also don't do a very good job explaining what this is. I found this:
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?
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 first document, SQRL explained, does a decent job describing how the system works. Having to download a PDF to read text on a website isn't the greatest of UX experiences.
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.
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.
To me, it's much more concerning that they do such a bad job of telling me what SQRL does than the fact that the page looks dated. At least it's clean-looking.
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.
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.
I would recommend reading through at least the first PDF on the site to get an idea of what it is and how it works. The short version is: It's a replacement password manager-esque protocol that enables logging into a web server while leaving no compromise-able secret in the servers database.
EDIT: A user posted a very nice write up of it in another comment: https://news.ycombinator.com/item?id=26314472
EDIT: A user posted a very nice write up of it in another comment: https://news.ycombinator.com/item?id=26314472
There is a much better explanation here:
https://security.christmas/2019/2
https://security.christmas/2019/2
> Some web sites have started to offer support for passwordless authentication using FIDO2 hardware keys. This offers similar security properties to SQRL (in some ways arguably better), while also being very simple to use.
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.
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.
This is much better, thanks.
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.
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.
This is a good write up! Thanks for adding
The spec was recently completed and there are multiple efforts to bring it into a more well rounded existence. The work is being done by volunteers, so it may take some time to become a reality across the internet, however, the seeds are all there to make it work and with some dedication from volunteers I think it has a bright future as possibly being the preferred password manager in the future. If you browse the SQRL forums, you can get an idea of where all the different efforts are playing out, but there is no real central repo of all SQRL code. https://sqrl.grc.com/
No serious user should still be using LastPass in 2021.
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.
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.
Move to Bitwarden. It has a great free version but if you want to support them, you can pay 10 USD per year. Less than 1 dollar a month. Really reasonable.
Bitwarden has one critical feature that makes it unusable. For example, one feature that has been "in the works" for last 3+ years : "auto-save newly created passwords with a prompt" [0]. I understand that it is a different model than LastPass but 3y+ for a critical feature is one of the reasons BitWarden is not the first choices.
[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.
[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.
To clarify: the issue is that autosaving works only some of the time, not that it doesn't exist. From observation, it seemed to be overly keen at one point (prompting excessively) and now is very shy (not prompting even when it really should). At least that's my experience on Firefox. Seems to work better on FF/Mac than FF/Win.
In my case, the some of time is almost never - macOS /Safari and macOS / Firefox.
I'm using pass as my password manager but I heard a lot of good about bitwarden
so I decided to give it a try, that would be one fewer thing to administrate for
me.
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.
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 agree that the Bitwarden cli is awful. You have to log in, and store the token it gives you manually so that it knows you're logged in.
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.)
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.)
If I had known about this client I might be using bitwarden today! Thank you for that.
I've never had a use for a command line password manager so I've got to ask: how does this fit into your workflow? I'm honestly mostly using a password manager in my browser and on my phone; I don't need command line authentication all that often.
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.
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.
I don't do a lot of "serious stuff" on my phone, so whenever I need to input a password there I just display the password on my computer and enter in there, if I regularly needed to access my passwords however my current solution would be unusable.
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.
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 me I have 1 use case - logging onto a Cisco Anyconnect VPN.
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.
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.
I use it fairly regularly for cases where I want to input something sensitive on the command line, and not have that stored in my bash history.
For example something like
curl -u user:"$(pass SomeSecret)" https://api.website.com
For example something like
curl -u user:"$(pass SomeSecret)" https://api.website.com
> I use it fairly regularly for cases where I want to input something sensitive on the command line, and not have that stored in my bash history.
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...
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...
Bitwarden is a reasonable alternative, but it's important to be aware of the weak points compared to Lastpass (which IMO, makes it a good-enough-but-no-great-choice).
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).
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).
> Autofill is relatively poor (it fails even on HN!).
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.
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.
I have yet to find a site that autofill fails on. Hacker News works perfectly for me and always has.
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.
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.
> Autofill is relatively poor (it fails even on HN!).
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.
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.
> Autofill is relatively poor (it fails even on HN!)
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.
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.
[deleted]
added bonus, Bitwarden has " only " two trackers in it
https://community.bitwarden.com/t/remove-embedded-trackers-f...
https://community.bitwarden.com/t/remove-embedded-trackers-f...
I feel like these trackers (Firebase Analytics and Visual Studio Crash Reporting) need to be looked at in context of the data they actually send and who they report to. According to the thread
> 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.
> 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.
Crash reporting within a password manager is a serious liability considering memory dumps would often contain secrets or encryption keys.
Firebase is Google. I don't know why they deserve different levels of trust. If Firebase has your permission to harvest your sync info, there is no reason to think this doesn't get copied right on over into googles 'track every click and movement' apparatus.
Firebase is Google, yes, and the name of a suite of mobile-related products. They have ML Kit, Crash analytics, configuration management, auth etc.
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.
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.
This assumes you're trusting Google. Technically you are still sending a lot of data to them (IP address and persistent identifier, which would allow them to correlate other info they gather from other sources) and they have the capability to use it for nefarious purposes if they decide.
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.
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.
The Firebase Data Processing and Security Terms [1] (section 5.2.1) limit Google's usage of any data they obtain through Firebase and would seem to prevent that sort of tracking.
[1] https://firebase.google.com/terms/data-processing-terms#5.pr...
[1] https://firebase.google.com/terms/data-processing-terms#5.pr...
Also in the same thread, you can download the no tracker version from F-droid.
[deleted]
Love bitwarden and use it every day (paid user).
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).
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).
Lastpass is the same way.
I setup bitwarden_rs recently on my own server with traefik in front. I use the android app and browser plugin which point to my own instance. Currently it's only working on my home network, but I'm working from home.
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.
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.
I done the same after the first breach and when they almost doubled the yearly sub free.
Bitwarden is open source and works just fine. Had no issues with it
https://lesspass.com/ is another interesting option.
Bitwarden grants full remote access to your computer to the Bitwarden developers if you use the desktop app.
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.
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.
For those just scanning the comments, "full remote access" is just being used to mean "has an automatic update system" here
An interaction-free automatic update system is, by definition, RCE, which is equivalent to full remote access.
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.
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.
How do you feel about browsers or operating systems that are updated on a monthly/weekly basis? Do you not upgrade them ever? Do you set them to manual update but blindly accept all the updates? Or do you manually update only after performing a detailed code review of all the source code changes, along with doing a build yourself to make sure nothing malicious was slipped in?
I disable automatic updates on all software on my machines, and update them periodically on a schedule, using downloads that are verified as authentic.
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.
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.
How do they decrypt the vault without the master password?
By replacing the client code with code that exfiltrates the password the next time you enter it.
Alternately, brute forcing the client password is straightforward due to their use of a too-fast KDF and low iteration count.
https://github.com/bitwarden/jslib/issues/52
https://github.com/bitwarden/server/issues/589
Alternately, brute forcing the client password is straightforward due to their use of a too-fast KDF and low iteration count.
https://github.com/bitwarden/jslib/issues/52
https://github.com/bitwarden/server/issues/589
I agree that automatic updates should have a toggle, Signal desktop is another client where the devs won't provide one and have even taken egregious steps to prevent blocking it. Run in a reduced-privilege account though and either client will still require your assent via the admin rights to install.
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
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
That's a very disingenuous way of putting it. If you use the application, there's auto update functionality (with a confirmation dialog box) if:
- 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.
- 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.
It doesn't have a confirmation dialog box, it simply notifies you that it has already happened. You can't easily prevent it. The vulnerability has already occurred by the time the dialog box is displayed.
If you simply reboot your computer, the new code executes.
If you simply reboot your computer, the new code executes.
Does it? From what I could tell from the source code, it seems like it should ask first.
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.
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.
> Even still, auto update is a feature, not a vulnerability.
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.
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.
You should read your own bug report for the way to disable auto-updates: either use the portable version or set the ELECTRON_NO_UPDATER=1 environment variable.
It's easier to just chown the app to a user different than the one running it (so it can't self-modify) than it is to set env vars for GUI apps in macOS.
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.
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.
There was a single dev response to your bug and it was the above solution.
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.
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.
Truth isn't a popularity contest, unfortunately.
I'm not sure these trackers are the worst possible as they could be used for things like crash analytics.
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?
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?
In other news, my banking app used to have 17 trackers (!) but they reduced to 6 some time ago (I pinged them about that, not sure if this was related but it's good to put some pressure on the businesses to let them know users care).
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).
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).
I rarely see mention of 1Password. Anyone have thoughts about its security and privacy?
According to the same researcher, 1Password has no trackers. 1Password does use UserID & DeviceID as identifiers though.
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...
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...
Rather than link to their whitepaper etc, I’ll just offer my endorsement as a security engineer of 1Password as being the most secure and best password manager.
LastPass has been a clown show for years. Unbelievably sloppy work.
LastPass has been a clown show for years. Unbelievably sloppy work.
Probably because, for most of us, the reasoning goes like this:
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.
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 see it recommended a lot but I am happy with Bitwarden so never had a look. Maybe I will before my next billing cycle starts...
Reading the comments it almost seems that folks assume passwords are shared plain text with these trackers. I don't have any issue with Lastpass having anonymized logs of how often people visit which part of the app if it leads to improvements in usability.
From a security standpoint this is kinda the point – we don't know what it's sharing and it has the ability to, so we have to assume it. Obviously it's unlikely, but through accident, ignorance, or malice, it's possible.
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 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 don't have any issue with Lastpass having anonymized logs of how often people visit which part of the app if it leads to improvements in usability.
I do. Some don't. Some do.
So give the user the choice instead.
I also wonder if this is even GDPR compliant...
I do. Some don't. Some do.
So give the user the choice instead.
I also wonder if this is even GDPR compliant...
I go with Keepass + Onedrive for my personal stuff
Keepass and Syncthing. The laptop is where I update the database. Every other device is read only.
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.
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.
I do this, but other devices are configured as sources too, so I can add entries from my smart phone or wherever.
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.
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.
Risk of bidirectional synching, apart from conflicts when you edit from both sides, is that if something catastrophic happens, like you mistakenly delete half of your passwords, it gets synchronized to the other instances.
Syncthing can store histories, so you can retrieve your database from before the conflicts, if it happens. Personally, it hasn't happened to me. I keep my eye on syncthing's notification anyway, so it's not a problem to me.
And to be absolutely sure I have a cronjob that backs up the DB at regular times :-)
Yeah I’ve been using Keepass with a synced db for about as long as it’s been around and never had a complaint. Got most of my family doing the same and they like it too... and no longer use petname1234 for every single website.
username checks out
I am doing the same. With security, I feel that there is value in simplicity and even a little inconvenience.
I am doing the same. With security, I feel that there is value in simplicity and even a little inconvenience.
Still wondering how it became the general consensus that password managers are secure. I wouldn't store my passwords in any online system.
For average user they are. They allow humans use long passwords without reuse. They're resistant to phishing. Online sync is necessary for multiple devices.
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.
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.
> I don't understand how they are still in business.
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.
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.
> I don't understand how they are still in business.
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.
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.
I will say, though, as someone who just switched, 1Password is significantly nicer.
>But OTOH Firefox Lockwise/Sync is client-side encrypted, and the server just holds an opaque data blob for you.
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.
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.
Come on, security isn't black or white, or absolute. I understand that my password manager may be flawed, but it sure was a huge upgrade from doing much simpler passwords, with my cats birthday in them, and +01, +02, +03 to make them "unique" between accounts. That sure made me feel vulnerable and unsecure. (And I do not really have a cat.)
Driving in a highway isn't secure, but only Japanese manga characters avoid leaving their town because of it. You pick your battles.
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.
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.
Your threat model doesn't really make sense either. If your password manager is evil, you're probably screwed anyways because on non-sandboxed platforms (ie. windows, linux, maybe mac), there's basically zero security between applications so there are a variety of ways it can get your google/bank passwords. As for the "dumb" bit, that can almost be entirely mitigated by using a password manager that doesn't have network functionality.
Because you can architect them to be provably secure via E2E encryption. See how 1Password deals with this for reference.
You can architect it so, but the implementation is what counts.
No program which knows your master password and which has network access can ever be considered secure.
No program which knows your master password and which has network access can ever be considered secure.
There is no program that knows the master password. It's hashed.
Why do you use a web browser then? It doesn't know your master password, but you enter most/all of your passwords into it anyways. To make it worse, it runs third party code that also have access to your password (ie. addons with the "Access your data for all websites" permission, which is most of them).
Dropbox passwords, although it still leaves something be desired, looks very secure.
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.
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.
I think of passwords in 3 tiers:
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.
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.
Isn't the general consensus that nothing is secure, you just have different levels of difficulty to break in?
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...
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...
Perhaps taking a leaf from Voldemort's book might make you more comfortable with using them.
https://kaizoku.dev/double-blind-passwords-aka-horcruxing
https://kaizoku.dev/double-blind-passwords-aka-horcruxing
They aren't completely secure but even the browser password managers enable good practices like having 64 random printable character passwords that are unique for every site. They're also resistant to phishing.
I recently switched to pass, and found it much better than any available password management service. It makes use of tools that I use on a daily basis, which helps a lot with simplicity. And I don't have to trust a single provider with all my data.
https://www.passwordstore.org
https://www.passwordstore.org
I love the Git integration on this, it's saved me so many times when my computer failed.
How well does the chrome browser plugin work?
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.
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.
Can't comment on the chrome plugin, but the firefox extension(passff) feels pretty much like a drop-in replacement for it's default password backup feature.
But I've mostly switched to using the dmenu script, since it's much more snappier and available everywhere.
But I've mostly switched to using the dmenu script, since it's much more snappier and available everywhere.
I moved to bitwarden. Their app / product is top notch. Actually easier to use than LastPass.
These specific trackers are not normally used for advertising or selling your data to third parties afaik. These trackers are used for fixing bugs and understanding how your users use the app so it can be improved.
I just don't get why people think that uploading all their passwords that are protecting some potentially extremely sensitive data to some random internet company is a good idea.
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.
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.
> 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!
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!
I am using KeepassXC and keeping the encrypted password file in a Google Drive, shared across my devices. That would likely cover most of your use cases too (the file is locally cached so even if there is no network connection I am not screwed).
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.
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.
[deleted]
LastPass on my phone also tried to talk to Facebook on every launch. I consider those parasites to be trackers.
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/
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/
Firefox Sync is quite good. And it's part of Firefox.
Less convenient for passwords in native apps, but still usable.
Less convenient for passwords in native apps, but still usable.
password-store has 0: https://reports.exodus-privacy.eu.org/en/reports/dev.msfjarv...
but it's commonly used with OpenKeyChain, which does have a tracker: https://reports.exodus-privacy.eu.org/en/reports/org.suffici...
but it's commonly used with OpenKeyChain, which does have a tracker: https://reports.exodus-privacy.eu.org/en/reports/org.suffici...
The piwik in OpenKeychain is gone in the 5.6 release. And it was always opt-in, of course.
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.
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.
RememBear is the unsung hero, awesome interface, apps for different platforms, and a bear who loves you.
(Runner up is bitwarden, great price, great tech, great project, poor UI)
I actually liked LastPass and have been a long time paying customer. I just deleted my account. Trackers on a Password Manager -- what the fuck were they thinking ?
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 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.
How many people are going to write all their passwords into a plain text csv file that will sit on their HD forever just to move to another password manager that might have even worse security because of this FUD. These are all standard analytics packages.
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.
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.
Eurgh it was so much work to get my parents used to using lastpass. I even pay for premium for the whole family, can't face having to migrate them all.
Don't know if you prefer it but the 1Password family plan is decent, and basically the transition is mostly just a case of pasting the dump from LP into 1password.
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.
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.
I've already switched to BitWarden. One thing I really miss from their mobile app is the in-app browser that LastPass had. All my credential-requiring browsing can stay inside the app itself instead of my phone browser. Whereas now, I'd have to copy and paste them from BitWarden to my mobile browser.
Same, I wish there was a BitWarden to Safari sync or something
I use Firefox as my password manager. Does Lastpass or Bitwarden have benefits that I am missing out on?
For anyone moving away from LastPass, it's very easy to export all LastPass data into a CSV file and import it to other password managers. The hard part was deleting everything from LastPass as it only allows to select one item at a time.
1Password for Android have 0 trackers. And 1/3 of the permissions needed.
This sucks. I decided to buy LastPass premium after having used it for many years. This makes me sad, because I cannot ask for a refund, and I am stuck with it for a year.
I expect the iPhone edition has the same trackers in it. It's quite disgusting, frankly. I don't see a logical need for these trackers.
I chose LastPass, then it got sold to the current owners, so i switched to 1Password the next day, and I'm glad I did.
Germany based privacy research firm warns users, code signatures of 7 trackers found in the app
So that means the overall reputation is withering as well. Even more than before probably.
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?
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?
2 years old, perhaps relevant: https://twitter.com/taviso/status/1167400178912882688
Lastpass is the most widely used password manager.
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.
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.
I'm not sure I'd call reducing the functionality of the free tier as bait and switch. First, you aren't paying anything for that free tier, and bait and switched usually refers to a type of business fraud (which is illegal, btw) in which you are sold one good but then provided with a different good. If you didn't buy anything, and were not asked to buy anything, but were simply provided with less free stuff than last year, it's a bit of stretch, and even a bigger stretch to be so indignant that you are now getting less. Honestly, it sounds pretty damn entitled.
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.
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.
Yes, I think people should know about this because LP is the most popular one. And it's collecting loads of data.
Probably this is the reason why they never open sourced it
This is why I ask. A big target means lots of attention. A small target might have even worse security but no one is paying attention to the same extent.
Oh they even have an exodus app to scan your phone!
Does this still apply to the enterprise edition?
Security != Privacy
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"...