Posted by mooreds 7 hours ago
The first step was easy. The account creation and import of legacy data all went pretty well. But after that it wasn't so pretty.
The first hurdle was trying to understand their model for sharing data (so my wife and I can share important credentials). The model that LastPass uses is pretty intuitive to me: it's just a matter of sharing a folder, so relatively transparent. But Bitwarden has a whole separate concept of "organization", and the items being managed don't go in "folders" here, but in "collections". So there are two separate, and subtly different, models in play, and this is confusing. The good news is that the client aggregates the data so when you're using it day-to-day to fill login forms, you don't have to worry about the differences.
Once I'd gotten the data in place, I had to get the clients set up on the various platforms (browser extensions; desktop native, which is actually required for the browser extension's security to work right; phone). The OoB settings were entirely paranoid, and had me re-entering the complex master password over and over, really annoying me. Figuring out how to get to a reasonable balance required figuring out some settings whose labels are misleading. For example, "Unlock with PIN" sounded to me like it was going to add an extra layer of security, but it turns out that it really means "allow unlock using PIN in lieu of master password".
Also, note that while most of the settings default to paranoia-level (like the "require master password every time I inhale", that I mentioned above), you will probably want to change the default crypto cypher. It defaults to PBKDF2, but a better modern approach is the other choice, Argon2id.
...which also reminds me that there's a distinct lack of parity between client platforms. Although you need the desktop native app to manage browser extension security, there's a bunch it can't do. For example, after importing my legacy data, I needed to select all the contents of my LP shared folders and move them to the BW organization collection, but the native app (which seems to be an Electron app, btw) doesn't have a multi-select feature; you need to do that in the online web app.
There are a few decent Android and iOS apps that work well. I use Nextcloud and WebDAV for access.
Not a setup I can recommend to just anybody though.
The need to have an opinion on how you’d like to sync a file does, as you suggest, eliminate some portion of the population who need a fully baked answer in one step.
I used to use Google Drive, but now I use Syncthing, further reducing my exposure. Paired with Synctrain and KeePassium on iOS.
One tip: enable the atomic save option in settings to reduce the risk of weird cloud sync issues.
For syncing, I do it manually with rsync. Given the database is 1 file it's easy to move around. You can rsync / scp it over, use a USB cable, use cloud storage, etc..
I use a password manager in a "read many, write infrequently" way so I don't mind occasionally syncing it as needed.
I’m sure it works for many people to Dropbox their vault around anytime they want to access something and manually handle copies and sync. I’m not nearly so naive as to think that has any degree of success outside tech bubbled people.
Well, I hope Klue got them more customers than they are losing due to this.
1- Tradeoff individual account risk, for systemic risk. You may argue password managers are safe, but few would argue that the risk model reduces the risk of individual password leaks more than the risk of all your passwords leaking. It's a tradeoff.
2- Cat and mouse security: There's a class of security decisions that work because they are new and different. First the weakness was that passwords were short, then you make passwords long but unmemorable, so people rely on some other mechanisms to authenticate, like a file on their computer, a drive, a fingerprint, facial recog, which may in turn be protected by a second factor password.
At first the new security model will not be stressed, but as more users migrate from one security model to the next one, that's when you are able to compare the security of both technologies, it starts being a juicy enough target that it becomes attacked.
So we are at the point where password managers are used enough that they start becoming worthwhile targets of attack (to overcome the difficulty of vulnerating them).
Also worth noting that these attacks are more winner-takes-all. In the sense that rather than seeing one account hacked every couple of hours, you will see them all hacked at once, because you introduced a vendor in the password supply chain AND because the vendor centralizes all of the passwords. So target that one vendor and from a single attack you get all the spoils. So when comparing the security of the olden method and the new, just 1 incident is enough to undo all of the reputational gains it has made over the years.
I don't think password managers which store encrypted vaults are less safe than trying to have and juggle strong unique-per-domain passwords, even if you think that the password manager is becoming a target.
I do think there are some cases where an online password manager makes sense, e.g. for businesses, but for individuals it's better to just stick with an offline password manager, at least for the high value accounts.
But if even that is too much then f.ex. `keepass` + a scheduled script to periodically backup to your own servers is also perfectly viable.
Wait. That's a thing? Like, there are drooling, mouth-breathing stooges out there that would trust not just one of their passwords to such a thing, but all their passwords to it?
And it's not unheard of that infections metastize, whether into developer accounts, product code... Probabilistically, this was a shot on goal.
I apologize for the mixed metaphors.
For backup, the hardware security key let's you download a file from it with all of your passwords encrypted, and the decryption password it's shown on it's screen (something like 12 random words)
https://news.ycombinator.com/item?id=48647272
Third time's the charm
The specific dependency that gets companies infected, and the optics that result, are so important. There have been sillier examples, but you can see how in this case, the priority of sales and profits has resulted in the sacrifice of the main quality measure of their main and only product.
What do you mean exactly here What do you think LastPass could have done to prevent this specific issue?
customer names, phone numbers, email addresses, physical addresses, support case data, sales-related data.
But LastPass does (Salesforce CNAME):
https://support.lastpass.com/s/?language=en_US
So this couldn't have happened to bitwarden, you own the reputation loss if any of your suppliers get owned. Though it really doesn't matter anymore for LastPass they leaked their customers vaults before, I have no idea how they can still be in business.
It's worth noting that this is not 'their marketing provider' what they do is load 30 different providers for some reason, to maximize the reach of their data sharing and advertising network. Well, their network reached too far and touched an infected node.
To be fair, and I don’t want to, supposedly the only thing that was compromised was contact info. No vaults were exfiltrated or unlocked (as far as the article info goes).
So this is really just another very boring info breach, not a targeted password-stealing hack.
The other breaches they suffered were worse.