Should you be concerned about LastPass uploading your passwords to its server?

Years ago it was Hamachi (the LAN-over-internet software). Then it was LastPass and via it XMarks (itself acquired by LastPass shortly before). XMarks suffered much more grievously than LastPass — I suffered data losses on multiple occasions before finally throwing in the towel.

From my practical observation: People will go to great length to avoid dealing with a crappy UX. That can include falling back to "YOLO, I'll just use the same password everywhere" if the password management process is sufficiently atrocious. So I'd say good UX is part of the security concept, bad UX will compromise it.

Maybe, but a good UX goes a long way to convincing people to use the solution. The best security solution is the one you actually use.

This approach is exactly why the vast populace has essentially no security. I'd be glad if my parents were to switch to last-pass, as it is so much better then weak password re-use schemes.

I'd say that compromising security for comfort is a given, its guaranteed to happen. The best strategy here is to make sure that users will have the most security after the compromise.

People are reusing passwords and writing passwords down on post-its specifically because they haven't found sufficiently UI friendly options of password management. Regardless if that is out of ignorance of available options, UI not being friendly enough for them, or some other technical hinderance.

A compromise isn't weighing between an ideal scenario and your current situation. A compromise is finding an optimum between value extremes in acceptable real world scenarios. An ideal security extreme is a disconnected system, but that's never something you can compromise towards since the comfort/usability reaches 0.

You're trying to move security up by getting users away from pass reusage and post-its. In this case added comfort happens to also be increased security.

Any app that gets updates is vulnerable to that type of attack.

I think a lot of people feel uncomfortable giving a proprietary product access to their passwords, and feel more comfortable doing the copy-and-paste themselves. But compromising security for better comfort is not a very good strategy.

The website from the service in question also suffers from severe JS-errors on their page (FF 66).

My annoyance is lately it's become less skilled at detecting password changes properly, even when I'm invoking 'Generate Password'.

What do you mean? How are you measuring that? How do you think that would make a password of the same length and character set less secure in a practical way?

I'm not that familiar with mobile dev, but could a rogue app just sit in the background, making a copy of whatever's in the clipboard?

[0]: https://cdn.bitwarden.net/misc/Bitwarden%20Security%20Assess... [1]: https://hackerone.com/bitwarden

I think, for practically everyone, it is far more likely that shared infrastructure (like LP or hosted bitwarden) would be centrally compromised. For example, this post mentioned compromising a safety check for all lastpass users by finding a single vulnerability on a single lastpass domain.

Unless you go to extreme lengths with your personal opsec, a targeted attack by a skilled attacker is pretty much sure to be able to compromise you.

(In fairness, I don't actually know if self hosted bitwarden is enough for all classes of attacks or if I should also compile the clients myself in order to remove any references to the main bitwarden domain)

For example, I chimed in on github semi recently about there being a lack of automated tests and within a week somebody claimed to have decided to prioritize it. With other companies, 1) we wouldn't have known, and 2) we wouldn't ever know if it was fixed

TLDR, long term looks great for bitwarden, short term makes me a tiny bit nervous though

Edit: looks like they added 3 test files that I could find, which isn't terribly comprehensive but I assume there are more I missed on the other repos...

It's the superior choice to sharing an existing/personal account.

And people will do it, the best you can do is making the sharing secure.

At home, I take care of most of the bills. There are a few services where bills are under her name and account, but I need access.

The other case I've run into is at work, when the company has an account with an outside vendor rather than individual users.

- You have a social media account that a group of people should be able to access. (Facebook does this "right," in that pages don't have their own login credentials, and you go through your personal Facebook account to access the page. But I kind of wouldn't want to use my personal Facebook account for work, anyway. Twitter, Instagram, Reddit, etc. treat each account as its own log-in-able entity.)

- You have an AWS account where you want to avoid a single point of failure for the root credentials. Yes, each person should use their own IAM creds for day-to-day use, but if person X is unavailable person Y should be able to get to things. (And for casual projects, "learn about IAM" is a significant burden over "learn how to upload pages to S3" for limited benefit.)

- You have a web hosting account from someone who's not AWS who gives you a single username and password. Or a DNS registrar account (most registrars I've seen don't let you split up access). Or whatever.

- You have a shared email account for replying to things as a team, or even for just archiving emails. Again, some systems do this "right" - if you're using Exchange, you can allow one user to access another user's inbox. But most people aren't on Exchange, they're on something like Gmail.

- You have an account for some service where you shouldn't be sharing passwords according to the service, but doing so is strictly in the service provider's benefit, not yours. Netflix is the canonical example.

I hope they took it away for a good reason, like a security vulnerability.

I will admit that I don't store my Google password in any password manager. That is the root of trust for everything, so I remember the password and use 2FA. The other accounts aren't as important.

This is a complete red herring - it's an argument for using password managers in general, not LastPass in particular. The issues here are whether it is being done in a way that unnecessarily compromises those better passwords.

One organization I worked with accidentally created a password manager and it looked better than LastPass. Since it grew to become a huge security risk it got migrated to LastPass, which was barely useable and, at that time, got hacked, so that's a plus, and then migrated to 1Password the instant they added group vaults.

I think it's fine to enjoy a product, but it's also good to recognise when something could be better. Anything can be better.

You'd know, is there a tool that would let me migrate all my passwords from LastPass to 1Password? I think I have like 3k passwords and the thought of manually building that DB up again is daunting.

Reply from Wladimir Palant:

Unfortunately, I didn’t make notes last time I looked into this – the issues simply weren’t serious enough for reporting. And I only looked at a small portion of the codebase, so when I look at it now it will probably be some different code paths. So the getDomain() function I see under https://github.com/bitwarden/jslib/blob/dd46d5ecdd51f91dace5... is indeed using URL objects. It also knows that tld.js won’t handle IP addresses correctly, but it will only consider IPv4 addresses in dotted decimal notation and not IPv4 addresses in other notations or IPv6 addresses. All of that appears to be a minor risk but not an actual issue – assuming that URLs are already normalized when they get here (ok, let’s ignore the code prefixing URLs with http:// here).

The code at the bottom of this function is quite problematic however. Rather than ignoring non-HTTP URLs, this function will pass them to tld.js. But tld.js isn’t aware that non-HTTP URLs can have different semantics, so it will happily return “example.com” when it is fed something like “data://example.com,asdf/”. Oops, I think that one might even be exploitable…

I think I’m going to stop here. This needs a structured effort, not spending ten minutes every now and then. As I said, the codebase isn’t bad. But there are obvious issues that shouldn’t have been there. As always, spotting the issues is the easy part – proving that they are exploitable is far harder. I’m not going to spend time on that right now, so let’s just file these under “minor quality issues” rather than “security problems.”

Sharing password files via Dropbox, Google Drive, etc. is convenient, but how is that really different than what Lastpass does?

With Syncthing being peer to peer, there's a lot less opportunity for someone else to even know your password file exists.

Taking drugs is also a calculated risk, still, most people agree that you shouldn't...

Thus a (smart) attacker needn't guess the user's encryption key directly. They just need guess the user's password, "hash" it via PBDKF-2 with the proper params and see if it decrypts the data.

Using a sub $1,000 GPU and a table of common passwords obtained from popular website database leaks it's not that hard to crack the average joe's vault.