[HN Gopher] Bring Your Own Password Manager: Portable BitWarden ...
___________________________________________________________________
Bring Your Own Password Manager: Portable BitWarden on a Pi Zero
Author : kickaha
Score : 145 points
Date : 2022-11-01 12:07 UTC (10 hours ago)
(HTM) web link (novamostra.com)
(TXT) w3m dump (novamostra.com)
| alexk307 wrote:
| This is cool, but you can just leave it at home plugged into your
| router. DDNS + Nginx + Let's Encrypt might be easier to set up,
| and definitely easier to use.
| slowhand09 wrote:
| That's such a tease. I check RPI-locator daily. Buying a Pi
| anything in the US is hard now.
| 16mb wrote:
| I ended up getting some ROCK64 boards instead. They're a great
| price
|
| One downside is the PoE hats are massive
|
| https://pine64.com/product/rock64-4gb-single-board-computer/
| 3np wrote:
| Just get 5V 3A PoE China splitters from Aliexpress.
| green-salt wrote:
| I got the waveshare ones for the pi 4 and they're really
| compact. Not sure if they would work with the rock64 though
| misnome wrote:
| I had some luck in the UK where rpi-locator only showed the
| main SKU, but the sellers had "kit" stock available with a case
| and charger for like PS10 more, on a separate page.
| synergy20 wrote:
| What about using the $4 rp2040 to make an open source yubikey
| instead?
| joshka wrote:
| You'd want some sort of TPM for that to be viable.
| atemerev wrote:
| On one hand, this is incredibly cool, and brings some great
| security.
|
| On the other hand, docker containers on a RPi Zero? What a sad
| state of affairs we have in 2022.
| bheadmaster wrote:
| Why?
|
| Sincere question - AFAIK, Raspberry PI OS is a Linux
| distribution like any other, with dependency/distribution
| issues like any other. Why would using Docker on it be a sad
| state of affairs, in contrast to using it on any other
| distribution?
| atemerev wrote:
| Because a password manager is a tiny piece of software.
| Instead, it is now a multi-component black box installation
| with a general purpose operating system running on a full-
| scale Linux machine with a containerization platform designed
| for datacenters.
|
| I am not a fan of this kind of redundancy and opaqueness.
| jorvi wrote:
| Reminds me of someone writing a little status light app (in
| the macOS menu bar / windows tray) and choosing Electron
| for that. Something ridiculous like 200MB+ install size and
| 150MB memory use.
| bheadmaster wrote:
| When you put it that way, I agree - a password manager
| should really be implementable as a single statically
| linked binary.
|
| There seem to be some other Docker features used, like
| healthcheck [0], and MariaDB seems to be installed, too, so
| it might be worth considering how much additional OS-
| dependent complexity would the equivalent functionality
| without using Docker require. At the very least, you need
| some kind of service manager to run your program on boot,
| and restart it on error. At that point, Docker may as well
| be used as a glorified service manager - just slap your
| static binary in a `FROM scratch` container, and you're
| done.
|
| > I am not a fan of this kind of redundancy and opaqueness.
|
| Me neither. But I wouldn't blame Docker itself - it's just
| a tool. If it wasn't for Docker, some other way of
| circumventing good engineering would be found :-)
|
| [0] https://github.com/dani-
| garcia/vaultwarden/blob/main/docker/...
| hk1337 wrote:
| BitWarden isn't all that tiny. I am pretty sure the main
| reasons for the docker container is that is built with
| dotnetcore and uses sql server for its database. BitWarden
| is complicated to install for self-hosting as opposed to
| using it on PiZero.
|
| That said, I am skeptical of running it on a PiZero. I
| could see running it on a Pi3 or Pi4 where I can leave it
| connected to my network and cron backups to a NAS.
|
| The BitWarden documentation itself shows 12 containers
| running. https://bitwarden.com/help/install-on-premise-
| linux/
| vxNsr wrote:
| Not the OP but maybe bec this is a single use device... why
| not just install direct on the OS and back the whole thing
| up?
| deberon wrote:
| Docker has been a godsend for home labs. People don't need
| to know where on the filesystem their configs have been
| scattered (distro dependent). They just need to know how to
| docker pull and configure their container.
| Dayshine wrote:
| Is there a generally supported way to back up an entire
| Linux installation from the device itself while it's
| running?
|
| Is there a way to do it without backing up all the os
| packages?
|
| With docker I can stop the service, then snapshot its data
| volume, then restart it. And restoring is very easy.
|
| I have no idea how to get that workflow at an os level
| without a vm manager.
| jeroenhd wrote:
| One reason is that software isn't always distributed in
| normal distro repositories anymore. People can't (or don't
| want to) deal with dependency management so they ship an
| entire (slightly outdated version of an) OS with their
| application to make deployment foolproof.
|
| The vaultwarden install instructions assume Docker, for
| example: https://github.com/dani-garcia/vaultwarden. If you
| want to install native binaries, you're going to have to
| git fetch/checkout/pull the latest release tag and run
| `cargo build --features sqlite --release` yourself. Doable
| in a cronjob, but it'll probably take a compile to build a
| system like vaultwarden on a low-power ARM core.
| atemerev wrote:
| Yes, Docker is a black box. You don't know anything, you
| just launch something without understanding what
| components it consists of, what are they doing
| individually, what is their attack surface.
|
| Not to mention that it encourages sloppiness and software
| bloat. The password manager could be put on a simple MCU
| device, instead, we have a large non-transparent multi-
| component installation swept under the rug with Docker. I
| do not think this is a good thing.
| jeroenhd wrote:
| The same can be said of any software that you don't
| review and compile yourself. Whether I run a Docker
| container or pull in 500 npm/pip/cargo/gems/composer
| dependencies, the attack service remains. With Docker
| these individual layers can be separated and inspected at
| the very least.
|
| Based on the name, I expected someone to take vaultwarden
| and make it an actually pdrtable executable that runs on
| its own without an OS; instead, this is just a quick
| tutorial for "how to set up vaultwarden".
| [deleted]
| osrec wrote:
| In case you ever wish to change the operating
| conditions/environment/hardware in the future. Having a
| consistent operating environment is a big win, in my
| opinion.
| jalk wrote:
| Yes absolutely, but if the hardware requirements for
| running docker currently doesn't fit on a keychain (a
| physical one that is), perhaps its not the best choice
| today for secure password storage.
| [deleted]
| jeroenhd wrote:
| I much prefer normal systemd services to sandbox my
| applications but if the software you want to run isn't packaged
| in some normal, updateable way (like a standard repository)
| then Docker is definitely the way to go.
| gigel82 wrote:
| Seems unnecessarily complicated. I self-host Vaultwarden at home
| (and expose it to the internet via WireGuard), nice and seamless.
| bm3719 wrote:
| This is an interesting tech stack, but seems heavy-handed for
| managing such a small amount of raw data (the l/p list itself).
|
| My solution for the past 14 years has been a simple GPG-encrypted
| org-mode (text) file. I can get to a password multiple ways from
| any device. The main way I check one is to open the file in Emacs
| which prompts for the master password via pinentry. You could
| also use a keyfile. Usually I just ssh and connect to a tmux
| session with emacs -nw already running, but I can also decrypt
| and grep it from the CLI, or clone the private repo its on to do
| the same locally. I only do anything involving PII or money in a
| dedicated PureOS VM though, so I generally don't jump through any
| hoops and it's relatively transparent.
| nordsieck wrote:
| > My solution for the past 14 years has been a simple GPG-
| encrypted org-mode (text) file.
|
| Have you ever taken a look at pass?
| zikduruqe wrote:
| Pass synced to a bare git repo at home... via WireGuard of
| course. Same dev.
|
| Also look at Passage which uses Age encryption.
| Bluecobra wrote:
| Seems pretty complicated to me. There's lots of steps involved
| which increases the chance of something going wrong. For example,
| the self signed cert will eventually expire, how easy would it be
| to renew it? How do I keep this up to date?
|
| It would just be a heck of a lot easier to just use KeePass and
| save the database on a SD card.
| ctoth wrote:
| Does Bitwarden's setup process still involve entering your master
| key in the browser? This always felt very sketchy to me, for some
| reason.
| hatware wrote:
| As long as the master key stays local and is hashed/salted
| before being sent to BW, you have nothing to worry about. You
| can verify this yourself.
| password4321 wrote:
| If you have an old Android phone you might be interested in
| https://github.com/tejado/Authorizer
|
| > _Authorizer is a Password Manager for Android. It emulates an
| HID keyboard over USB and enters your credentials on your target
| device. Additionally it supports OTP_
| guenthert wrote:
| Now I won't lament the overkill in hardware (512MiB RAM for a
| _password manager_?), but the lack of protected memory (Smart
| Card or otherwise) makes this approach imho quite questionable.
| Lose the device, lose _all_ your passwords?
| syntaxing wrote:
| An alternative to this is to expose this to your local network
| and use tailscale to connect to it so you do not have to carry it
| around while being secure.
| mbreese wrote:
| That similar to what I was thinking too... instead of carrying
| around a device, why not have a server that is physically
| secured somewhere and connect with Wireguard? It could be at
| home or on a cloud, if you trust that.
|
| Tailscale and wireguard are available for all major devices,
| including mobile. So, if you do this, your password manager can
| live anywhere and doesn't need to be exposed to the main
| internet at all. You don't even need SSH/network access to the
| remote machine, just HTTPS over Wireguard (and local or console
| access). Everything else can be locked down tight.
| iso1631 wrote:
| My understanding of tailscale is you give full access to the
| tailscale company to allow any public key to access any of your
| machines.
|
| I think I'll stick with running my own wireguard thanks.
| vermon wrote:
| Or you can run Headscale:
| https://github.com/juanfont/headscale
| grepLeigh wrote:
| Great write-up, thanks for sharing this!
|
| One thing I would add: a self-signed certificate is not adequate
| for password transmission. In some ways, it's even worse than
| transmitting over clear-text http because it provides an illusion
| of security.
|
| Any actor on your network can man-in-the-middle, provide their
| own certificate, and you'd be none the wiser.
|
| I'd suggest provisioning LetsEncrypt leaf-node certificate on a
| node that can respond to HTTP-01 or DNS-01 challenges (don't open
| your home network to :80 :443 - use a VM in the Cloud to respond
| to challenges), then transfer the certificate to the Raspberry
| Pi. https://letsencrypt.org/docs/challenge-types/
| patmorgan23 wrote:
| Only if you blindly accept the cert. You can still check the
| thumbprint for what cert is being used.
| GekkePrutser wrote:
| IMO Letsencrypt is way too difficult to bother with for such
| scenarios: devices that are not open to the internet.
|
| The hassle of forwarding the ports for their verification and
| having to do it so regularly (3 months) is a real pita.
|
| I used to just pay for yearly certs for this reason but prices
| have gone up so now I'm back to using self signed. I'd love to
| set up my own PKI but the tool chain is so complex and many
| OSes like Android allow apps to opt out of user -added root
| certificates which makes it very hard to deal with.
| snapplebobapple wrote:
| you could use the dns authentication, just set the ip to the
| local one this box for the domain you own/will be always use
| then all you have to be able to do is hit external dns and
| letsencrypt to update the cert.
| [deleted]
| GekkePrutser wrote:
| Ah but I use a personal TLD which does not really exist in
| the real internet. Can I still use letsencrypt with that?
| snapplebobapple wrote:
| afaik you can't because then there are no dns records to
| verify against. You could use a subdomain of a real tld
| if you had one though, or just bite the bullet and spend
| 10 bucks a year.
| giobox wrote:
| Lets encrypt is staggeringly easy for devices that are not
| "open" to the internet - it supports or has plugins to manage
| ACME DNS challenge records fully automatically even for
| private IPs in your home network, and this is just one way to
| do it. Using letsencrypt to get valid SSL certs easily,
| automatically and for free for private IPs behind a NAT is
| something I love using it for!
|
| You never need to expose a webserver to the public internet
| to use letsencrypt to get a valid SSL certificate, even if IP
| is in the private RFC range (192.168.x.x, 10.x.x.x, etc etc).
|
| Every single webapp I run internally has a two line automated
| Caddy/letsencrypt auto configuration, that just _works_.
|
| To suggest it is way too difficult suggests you haven't tried
| recently, or are familiar with very old http-based DNS
| authentication challenges. You do not need to use http-based
| challenges to use letsencrypt for a long time, although still
| supported.
|
| > https://caddyserver.com/docs/automatic-https
|
| > https://caddy.community/t/how-to-use-dns-provider-modules-
| in...
|
| No port forwarding required, ever.
|
| This feature also exists in plain ole letsencypt, their
| "dns-01" challenge support:
|
| https://letsencrypt.org/docs/challenge-
| types/#dns-01-challen...
|
| The list of DNS providers who support this is massive now
| too:
|
| https://community.letsencrypt.org/t/dns-providers-who-
| easily...
|
| It is now _so_ absurdly easy to do, all my personal projects
| just have valid SSL by default now, even on my internal LAN.
| All letsencrypt needs is proof of domain ownership- thanks to
| DNS TXT records, no one needs to host a website /port forward
| to accomplish that.
| GekkePrutser wrote:
| But still those ACME records need to be updated every time
| on my outside DNS server right? Or is it just a static
| record? That I can do, a dynamic one is very hard with my
| DNS provider (meaning I still need to do everything
| manually every 3 months which is not an option).
|
| I also don't really like leaking internal network info in
| my external DNS provider which is why I run my own internal
| DNSes. And I use a domain for my internal network which
| does not really exist in the real world, I don't know if
| letsencrypt can handle this.
|
| I have indeed not tried it recently, the last time I tried
| it it was about 1 year since they launched. Trying to
| script all the firewall rules to open the ports for a
| second was a real PITA.
|
| I'll have a look at this, thanks for the heads-up.
| bee_rider wrote:
| The general idea is neat. I wonder why they didn't emulate a
| keyboard instead...
| rpgbr wrote:
| Holy cow, that seems complex!
|
| What are the advantages of this setup over carrying a pendrive
| with am encrypted KeePassXC vault in it?
| qwerpy wrote:
| I've seen so many interesting password manager solutions over the
| years, but I have yet to move away from a Keepass file hosted on
| cloud storage. I can read and write to it using apps from every
| device I use: windows and linux PCs, iOS and Android devices. The
| file is versioned so accidentally clobbering it isn't a concern.
| There is zero maintenance, and if my home server goes down my
| passwords are unaffected. If I'm going somewhere without internet
| and need a backup mechanism of getting to my passwords, I can
| copy the database onto a memory stick.
| zmxz wrote:
| What happens when there's more than you who uses the Keepass
| file and how do you store new passwords to the file when you
| create new accounts on the web (for various services)?
|
| What's the usage flow? Is there browser extension that allows
| you to interact with it without opening Keepass program?
|
| Maintenance you described is easy, but what about the actual
| usage and sharing passwords?
| bityard wrote:
| I have a personal Nextcloud instance set up on a VPN. We have
| a "shared" keepass file that is shared between the two of us,
| and individual one for each of us, which is not shared via
| Nextcloud but still syncs to Nextcloud to have available on
| our computers/phones.
|
| This has worked great for us for a number of years.
| pmontra wrote:
| Not OP. I add only from my laptop, I share with Syncthing to
| my other devices. Nobody else use my passwords. If a customer
| has a per team password they either never change it or in the
| very rare cases they do, they tell me the new password when I
| ask why the old one doesn't work anymore. They don't let me
| in their shared password manager anyway (only one customer
| has one.)
| qwerpy wrote:
| Good questions and I think they show some of the blind spots
| I have.
|
| I don't share my passwords database. Right now my wife and I
| do have a very limited number of shared accounts but I set up
| the same system for her and we simply duplicate the few
| shared logins we have in our two databases. This could be an
| issue if we need to share more.
|
| Creating new accounts is easy. Both my windows and iOS
| Keepass clients open the file directly from cloud storage.
| They can save changes and reload the database on startup.
| Once in a while I've had conflicting writes but it's rare,
| and I stopped getting them when I got better about saving and
| closing after changes.
|
| Usage flow on PC (I'm sure I could install a browser
| extension, but haven't bothered yet):
|
| 1. oh I need a password. windows+s, type keepass, open
| keepass, type master password.
|
| 2. ctrl+e look for the website I'm on
|
| 3. ctrl+b copy username, paste
|
| 4. ctrl+c copy password, paste
|
| Usage flow on iOS:
|
| 1. oh I need a password. iOS magically knows, gives me
| options of iCloud keychain or Keepass client. Select Keepass
| client
|
| 2. Sometimes it's not smart enough to detect which password
| entry to use. In this case, type in the website/app name and
| select it
|
| 3. Usually it's smart enough to fill out the username &
| password fields automatically
| bee_rider wrote:
| Oh, that's neat. What iOS app do you use? I've been using
| minikeepass but it has been no longer supported for a while
| now (I've got a copy of the .kdbx for my phone elsewhere,
| so when it eventually self-destructs I'll still have that
| at least).
| lotsofpulp wrote:
| I use Strongbox, with Keepass databases stored in iCloud.
| One for me, one for wife, and one for both of us for
| mutual accounts. Periodically they are backed up to a USB
| drive to store with important documents. And Time Machine
| backs them up regularly to NAS.
|
| We also use macOS/iOS keychain for convenience, but the
| TOTP and other notes about the account are stored in
| Keepass database.
| qwerpy wrote:
| Keepassium. Free, has some limitations that don't affect
| me.
| antisthenes wrote:
| What's the use case for sharing passwords? I've never had the
| need to share one in 20+ years of being a power user. If I
| end up dead, my master password will be shared in my will
| with appropriate parties.
|
| > Is there browser extension that allows you to interact with
| it without opening Keepass program?
|
| I sure hope not.
| dspillett wrote:
| _> What 's the use case for sharing passwords?_
|
| For personal use: none for me. Instructions for
| deriving/obtaining my master password and physical key will
| be made available in any will or power of attorney
| documentation I get around to drawing up.
|
| In DayJob there are several, though they are usually only
| temporary needs, such as:
|
| 1. We often get sent password-protected documents by
| clients, that more than one of us needs to read. It pains
| me how often I see an attached document on an email
| containing the password needed to open it... A shared
| password manager where someone can record the credential
| and mark who should be able to access it (or better have
| all credentials encrypted by the public keys of those who
| should be able to access them rather than just trusting a
| flag) would be less daftly insecure.
|
| 2. Distributing initial credentials for new assets or to
| new people, where those assets are not integrated with
| single-sign-on so nothing needs to be distributed anyway.
|
| There are other ways to manage such situations of course,
| but a password management arrangement with a well-defined
| way of sharing credentials may encourage behaviour more
| secure than some of the ad-hoc solutions people regularly
| use.
| pmontra wrote:
| > Distributing initial credentials for new assets or to
| new people
|
| Sometimes I write the password in a file in the home
| directory of a server we both access in ssh. It doesn't
| happen often, maybe not every year.
|
| A customer has no servers, not a chance with them.
| zmxz wrote:
| > What's the use case for sharing passwords?
|
| There's plenty.
|
| > I sure hope not.
|
| Why? I'm not suggesting to have an extension that has
| access to your file system. Bitwarden has browser extension
| that communicates to Bitwarden vault via HTTP and it's easy
| to autofill passwords or generate new credentials.
|
| For throwaway accounts or demo accounts or any kind of new
| web service/app accounts, it's easy to memorize username
| and autogenerate a strong, safe password which are saved to
| vault.
|
| You have the access to that same vault from a different
| device (smartphone etc), it makes interacting with
| passwords and its storage extremely easy and without
| mistakes.
| dec0dedab0de wrote:
| Others have mentioned shared family accounts, I could also
| imagine storing shared wifi keys, or the admin password for
| the router. In the case of a business/project, there is
| also storing API keys, and maybe also admin passwords for
| devices. There could also be non-digital secrets stored in
| the vault, like bank accounts and social security numbers.
| The easy solution is just to have a separate keepass file
| that is meant to be shared, and/or have everyone maintain a
| separate vault with some of the data duplicated, and
| manually tell everyone when its time to update their info.
|
| At work we use hashicorp vault, ansible vault, and cyberark
| for different things, but I still store my stuff in
| keepass. For personal use, I use keepass on dropbox, and
| it's worked incredibly well for almost 15 years now.
| Arainach wrote:
| Unless you live alone and have no family, there are all
| sorts of scenarios for sharing passwords.
|
| Fedex/UPS only lets one account get detailed tracking
| numbers for an address, so I need to share my Fedex
| account. To check and pay my freeway tolls I'm only allowed
| a single account - so it gets shared. Plenty of people
| share all sorts of subscriptions, be they to Netflix, the
| New Yorker, or more. I need to share access to my
| insurance, to the utility bills, to sporting event tickets,
| to grocery store and pet food orders. On and on and on.
| toqy wrote:
| A use case isn't hard to imagine. You have a significant
| other whom you want to share credentials to some website
| with.
|
| I have quite a few shared passwords in my "family" vault in
| Bitwarden. Utility websites (electric, gas, water,
| internet, etc), streaming services, banking, credit cards,
| mortgage, car payments, car insurance, Chewey (manage pet
| food auto ship), probably others.
| rootusrootus wrote:
| > What's the use case for sharing passwords?
|
| My wife and I have a number of accounts we share a single
| credential for. There are a surprising number of services
| we access as parents that don't have the concept of shared
| ownership of content on the server side.
|
| I'd bet there are other use cases as well. Off the top of
| my head, Hello Fresh also doesn't allow more than one login
| to manage the same subscription.
| Semaphor wrote:
| Not OP. Sharing is not a thing, but I never had the need to
| share passwords.
|
| Storing new accounts syncs just like everything else.
| riedel wrote:
| We have been encrypting the key file with our SSH keys and
| share it along the database in a private GitHub repo.
| Additionally we have a single memorable password as preshared
| key. Works well for our small admin group.
| Semaphor wrote:
| It's the same for me. And I don't even need to copy the DB, as
| the Android app long-term caches the file even when it's
| normally read via nextcloud.
| allanrbo wrote:
| Cool idea with the ethernet gadget. If I understood it right, the
| RPI acts as a virtual ethernet adapter over USB.
| resoluteteeth wrote:
| Using something like an RPI Zero and carrying this around would
| make more sense if the device had a display and could be
| airgrapped.
| jrexilius wrote:
| That was our approach. Build it into the keyboard, do all the
| various secrets management (passwords, TOTP, et al) and message
| encryption behind a data diode (sorta air gapped). And RPi
| isn't the ideal compute module for it as you don't want a
| wireless chip on the inside of the "airgap".
| https://www.anomie.tech/
| criddell wrote:
| I'm not sure a RPI makes sense at all for stuff like this. They
| are so heavyweight compared to a little microcontroller board.
| xd1936 wrote:
| Keeping all of my passwords on a failure-prone SD card acting as
| a boot drive makes me nervous. I think I'd prefer a SyncThing-
| based solution for self-hosting a Bitwarden Vault or KeePass
| file... if I wasn't already a happy customer of Bitwarden's
| hosting solution.
| asmor wrote:
| You can chainload EDK2 builds for the Pi 3 and up (putting them
| on the SD card) and then boot into generic UEFI capable ARM
| linux on USB mass storage.
| Vexs wrote:
| Something that's been on my mind for some time is the seeming
| inevitability of getting RCE'd by some innocuous application- web
| browser, chat app, videogame, whatever. These vluns keep popping
| up and eventually one might hit me. And if it does, it might come
| with something targeting keepass and _if_ it does I'm Fucked with
| an upper case F.
|
| Building a portable terminal that can emulate a keyboard with a
| reasonable screen for ease of use seems like a fairly reasonable
| solution.
| evernite wrote:
| sorcix wrote:
| This article is using Vaultwarden, not the Bitwarden server. It's
| wrongly referring to Vaultwarden as "BYOPM hosts a Bitwarden
| instance" and "the Docker Image of Bitwarden." It is not, it is
| hosting a Vaultwarden instance. This is an issue as people using
| Vaultwarden report bugs to the Bitwarden project, where they
| can't be helped.
| patmorgan23 wrote:
| Yep, it's a bitwarden compatible vault but is not bitwarden
| cstuder wrote:
| I have a general question regarding the BitWarden server: How
| would you rate the security between using the official BitWarden
| server and self-hosting Vaultwarden?
|
| I am sympathetic (and capable) of self-hosting, but if my
| instance and my passwords are compromised, the fallout could be
| catastrophic for me. Am I better of in the long term by just
| using the BitWarden server and assuming that they have better
| security than I do, even though they are the even jucier target?
| the_svd_doctor wrote:
| I think the idea is that if you use the official client, there
| is "no risk" because everything is encrypted client side
| anyway.
|
| In theory.
| orangepurple wrote:
| So many commenters here are running air gapped solutions on a
| dedicated device. What's your backup story? How quickly can you
| add a new entry?
|
| It just seems like a HUGE hassle and risk of data loss compared
| to the classic KeepassXC + Syncthing burrito.
| dusted wrote:
| There's still enough lack of good password-manager infrastructure
| that I'll venture to say that FinalKey is still relevant, even in
| the face of Ubikey and Fido.
| Barrin92 wrote:
| honestly to me this falls into the category of LARP security. the
| entire point of encryption is to move sensitive data across
| adversarial channels. Meaning, if you trust Bitwarden enough to
| use it at all there's no benefit to not just using their servers
| (you keep a local copy of your data anyway).
|
| If you want to keep your data secure by keeping them on you, just
| use a notebook. Cheaper than this and works without a power
| chord.
| Karunamon wrote:
| It not so much that I do not trust the company today, it is
| that I do not trust them to not silently become adversarial in
| the future when the government comes knocking or if they get
| bought out, or whatever.
|
| This is a bit of attack surface that all hosted cloud solutions
| share, and it is one that it has never been easier to
| eliminate.
| Barrin92 wrote:
| all of these password managers (including bitwarden) encrypt
| your data end-to-end and nothing ever leaves your client in a
| plain state so regardless of who has the backend your data is
| never touchable. You always only ever need to trust the
| client, which you do here as well.
___________________________________________________________________
(page generated 2022-11-01 23:02 UTC)