That’s positive at least. I hadn’t looked at that part. Still having the whole dump of data and attacking it locally vs having to query a web server repeatedly for each attempt is a major advantage. This is why I significantly prefer Vaultwarden over a synchronized database, especially if it’s publicly synchronized in a publicly accessible git server or something making it relatively trivial to copy.
The cops maybe, but the agencies are in the pockets of the companies that sell it. And they control the message given to politicians who are also on the pockets of these companies. The companies have no qualms bribing all over the spectrum of politics and haven’t been stopped from doing it up to now. The systems are crap but super expensive for this very reason. The primary cost of the product is the bribes, not the technology. It’s how the industry of road cameras (plate tracking, red light, speed, etc.) has always been.
Yeah, there’s still a risk if you’re exposing the encrypted passwords. For example there is still some risk that governments have backdoors in some kinds of encryption, which of course means other malicious actors do as well. And there’s still brute forcing which is mitigated with a webserver layer in front of the raw data.
But there are lots of existing applications for that like keypass and its forks. Vaultwarden is more about the web services front end to the data than the data storage itself. And a web service benefits from a relational database over a flat file.
Yeah, fortunately Vaultwarden has enough users that probably someone will eventually create an extension for it. And in the mean time you just have to make sure to use an old version of the existing extension until that happens. It’s not like the changes in Bitwarden will affect Vaultwarden directly. The old client versions will still work until Vaultwarden changes something.
It uses a database and it’s totally possible to use SQLite as the database and sync that elsewhere. You could then find or make a small client that just accesses that db directly rather than a web service, I suppose. Though there are already several apps out there that store passwords locally and their data files can be synced, if that’s what you want.
But if you’re doing that then you may not be using this in the most common way or may not understand the risk involved. This is likely to have every one of your logins, not just a single login that may or may not be used on other sites, but the specific username and password and which site it’s associated with. On addition to access to those accounts, this links all of your accounts to a single identity which companies spend billions to do with advertising IDs, cookies, embedded scripts, and lots of other, usually shady, practices. This is a gold mine, though usually only for one or a few users, so generally not a major target unless you’re being targeted personally for some reason. So, even if they don’t get the passwords, they’ve now linked every account you have on every site to your identity.
If you are allowing the database to be relatively easily obtained by syncing it to a central location accessible over the internet, a bad actor who gets it can even take their time brute forcing any encryption that may be present in the database, but if you don’t keep encryption keys only on your local device because you want to be able to use it elsewhere, then you probably stored the keys along with the db and they dont even have to bother with that, or if it uses password based encryption, they just have to guess or brute-force a single password.
If it’s behind a properly secured web service, then even if they find an exploit in the server software, they likely have to do many queries over time to get much data and the server can mitigate that risk and/or alert the owner about new logins and such. A database in the hands of the bad actor can’t complain about too many attempts to access it or notify anyone that it’s been copied.
So, IMHO, it’s a bad idea to use synced local password managers unless you have a very robustly secure way of storing the database and the encryption keys.
Yeah, not the best. But at least there is an alternative.
Vaultwarden will survive. Since the client is open source, once they close the API and break compatibility of the clients with Vaultwarden, the old version of the app can simply be forked and rebranded. I also do hope that the KeyGuard app will continue to support vaultwarden as well since if bitwarden closes the API and makes a breaking change, as is likely to happen, it will break KeyGuard as well, but it will still work with VaultWarden for some time.
The real issue is that many people who are using Bitwarden aren’t savvy enough to host Vaultwarden in a secure way. Many people are careless with things like secret keys and such and dont know how to properly secure a web facing app or a VPN into their local network. But anyone who self hosts should result learn those things anyway. This one just happens to be a particularly high risk since it contains all of your passwords for everything else.
Guessing this is for getting a new phone number? They had stopped giving them outside of Fi for a while. Are they allowing new accounts again? I wonder if with Alphabet’s continuing expansion of cooperation with law enforcement and governments, this is something that those agencies requested in order to link your call data and recordings to your identity when they tap your calls. Google Voice has never been private.
Yep, that’s why I left most social media and try to keep things private. Not because i have anything to hide. I just don’t want everything I do, read, and say to be used against me or trigger hate-based attacks. These days everyone has at least one thing that some hate group would target them for since that’s how fascism works. Make everyone an enemy in small subgroups and trigger hate against that small subgroup whenever you need to distract from taking away rights or taking people’s money.