[spondyl]

I've used pretty much every password manager under the sun at one point or another. Lastpass, 1Password, Bitwarden, Dashlane, Remembear, KeePass(X) and I've finally settled on regular ol' pass.

I never really understood how it "syncs" but it's just git! Push and pull to update on every device. I use a private repo since site names are still metadata. You could put the whole directory tree in a tomb as well but that extension is only supported on mac only or something.

Pass is the one thing that seems fairly universal I think and it's all just text files which makes things really nice. No worrying about will it work on mobile or if the browser extension is useless without an application.

For example, 1Password X is a standalone extension so you could use it on Linux while Dashlane requires the desktop application running on the host. The connection works but isn't always reliable when running non-natively ie WINE

As for security, they're all fairly well audited I think? Remembear and 1Password both have external audits they pass, and provide remediation plans for any findings. Probably the same with Lastpass. Personally, I don't really think about it that much so I don't have a good answer. You can interpret that as me trusting providers but I have no real idea. I mainly just focus on the usability hah

[Fnoord]

Bitwarden has also had an external audit.

With regards to Bitwarden, it has a wordphrase on the account which only you know. You can verify this when you connect to the cloud. You can run the server within your own cloud.

With the cloud, you can assume that the government has access to the encrypted database. If you have a strong password, it will take them longer to brute-force your database. We are talking about two governments here: the US government (most password managers are from US companies and are hosted in US clouds) and your own (who can attempt to ask for the data), this is no issue, but I believe you should by default not trust them. This is important because it should be part of your risk assessment.

It would probably be easier to attempt a MITM (with help of the password manager sysadmin). I've once seen a fake Lastpass login page (back when I used Lastpass).

Almost all password managers can import/export their database to CSV. This allows you to avoid a vendor lock-in.

[octosphere]

> You can run the server within your own cloud

For me there is a tradeoff. On one hand, Bitwarden's online offering where you trust them with your data is convenient, but also a single point of failure. If their server goes offline, you can't access your passwords (And servers do go down). On the other hand you can repair your own instance if it goes down and have full control over it. The only caveat with self-hosting being the overhead. Regular non-techie people just don't have the time or intellectual curiosity to experiment with self-hosting. For me personally I just sync a Keepass database with Dropbox and call it a day.

[Fnoord]

Agreed w/your post in general.

> On one hand, Bitwarden's online offering where you trust them with your data is convenient, but also a single point of failure.

Put your network connectivity off, and try to relogin to Bitwarden. It will work. I just tried it. The only downside is that the database might not be synced (which, I admit, can be a problem).

> The only caveat with self-hosting being the overhead. Regular non-techie people just don't have the time or intellectual curiosity to experiment with self-hosting.

I don't know the password to connect to my (hypothetical) self-hosted Bitwarden instance. Because of the above though, that would not be an issue.

Hence I am going to switch to self-hosting. There's a Rust implementation with Docker image.

[benhurmarcel]

>Put your network connectivity off, and try to relogin to Bitwarden. It will work.

That's correct, but the parent comment is also correct about the single point of failure. The Bitwarden server could erase your database for some reason (bug, hack…), and it would sync on all your devices, erasing all your data.

[faitswulff]

What operational security risks do you have to be aware of when self hosting passwords?

[Fnoord]

This is a great question which everyone should ask themselves.

It has to be user-friendly enough (which Bitwarden IMO is). You need to do a CIA threat assessment yourself.

Confidentiality I solve by using WireGuard; hence I don't mind if I use HTTP or HTTPS with self signed certificate. You might be able to use Lets Encrypt instead. Integrity I solve with offsite backups of the most important data. Availability is solved by having decent uptime on my cable provider, about 25 mbit upload. I also used RAID1 on my server. My server is a Synology NAS with Docker.

If that gets compromised by hackers, they have access to private data of mine anyway. If you include the government in your threat assessment they are very likely able to get access to your server (VPS or my example). That is why I prefer to stick to my local government/jurisdiction. I'm already bound by them anyway. If they want to screw me over (including working together with US government) they can and (since we are part of Nine Eyes) likely will.

YMW(ill)V

[anarazel]

> With the cloud, you can assume that the government has access to the encrypted database. If you have a strong password, it will take them longer to brute-force your database. We are talking about two governments here: the US government (most password managers are from US companies and are hosted in US clouds) and your own (who can attempt to ask for the data), this is no issue, but I believe you should by default not trust them. This is important because it should be part of your risk assessment.

If it were just the risk of brute-forcing, I have a hard time believing this to be a real problem. Use a secure enough passphrase etc (and if that's not good enough, they could also just brute force into most of your accounts anyway). IMO the relevant thread model is more that they can convince / coerce / do it themselves the provider to change the javascript that does the client side decryption.

I use bitwarden for a good fraction of my login data, because I don't currently consider this part of my thread model...

I'm not fully convinced by bitwarden, especially the 2nd factor integration IMO isn't good enough. But I've not had enough to time to look much further.

I wish there were something that used (as a second round of encryption) a key residing on a yubikey to decrypt the password of individual entries, without going through gpg. Going through gpg just seems to complicated and fragile to me, and has annoying restrictions like not really allowing multiple yubikeys.

[Fnoord]

> IMO the relevant thread model is more that they can convince / coerce / do it themselves the provider to change the javascript that does the client side decryption.

Yes, this is the MITM I referred to in another post. I'm not sure the fingerprint phrase [1] is adequate to mitigate that danger

> I wish there were something that used (as a second round of encryption) a key residing on a yubikey to decrypt the password of individual entries, without going through gpg. Going through gpg just seems to complicated and fragile to me, and has annoying restrictions like not really allowing multiple yubikeys.

I currently use 2 YubiKeys with OTP and 2 YubiKeys plus 2 Solos with FIDO U2F on top of an Authenticator App as backup. There's backup codes as well. E-mail or SMS I prefer not to use (they don't provide SMS AFAIK but do provide Duo). I plan on fine-tuning this once I receive my new smartphone with NFC and my Somu; then I will likely remove some of these keys, reset them, and sell them.

[1] https://help.bitwarden.com/article/fingerprint-phrase/

[tim333]

I'm guessing "regular ol' pass" is "pass the standard unix password manager" https://www.passwordstore.org/ ?

Just thought I'd stick that here to save others the googling.

[spondyl]

Ah sorry, yes! I was tapping that out rapidly on my phone because I had gotten excited seeing a password manager thread. Maybe too much because I left the shower running before I realized I better wrap up my comment and stop being wasteful haha

[Boulth]

Not to mention pass, due to its connection to GnuPG, can protect secrets using Yubikey that require 6 digit PIN (will lock after 3 tries) and touching the blinking dot.

[eropple]

Interesting. I've never used pass, but this thread is making it sound interesting. Does it support fallbacks (multiple keys, other forms of credentials) simultaneously?

[Boulth]

Multiple keys: yes, through a config file (can be also useful for team access). I'm not sure about "other forms of credentials" though. Pass is just a simple GnuPG wrapper if gpg can do something pass can do it too.

[SomeOldThrow]

How do access your passwords from your phone?

[Libbum]

There's an Andriod client for that: https://github.com/zeapo/Android-Password-Store#readme

Plenty of other extensions, managers here: https://www.passwordstore.org/#other

[Boulth]

See sibling comment. Additionally it's possible to use the same Yubikey token on laptop and phone (through NFC or USB). Convenient and secure!

Second benefit is Yubikey can hold authentication subkey that can be used to SSH to a server on a phone.

[dancek]

I'd love to start using pass but I find managing gpg keys troubling (perhaps due to my lack of knowledge). Does your setup require copying the same key to each device? What would happen if someone got your gpg key? What would happen if you lost the key?

[woile]

I've made a cheatsheet[1] for gopass, which is the same but also includes multi stores (you could have a personal store, and a shared store with your work team, synchronizing to different git repos).

Edit: to export the public key you can search Google, I'd recommend saving it in a yubikey or in a usb with encryption.

1: https://woile.github.io/gopass-cheat-sheet/

[_-___________-_]

pass can encrypt to multiple keys. I use one key for my laptop and one for my phone. If someone gets your gpg key then they can decrypt all your passwords if they also get the repository. It would be prudent to change all your passwords in this case (pass-rotate could help a little with this). If you lose the key, you lose access to all your passwords.

[_-___________-_]

worth also noting that that when I used to use Android, I didn't need multiple keys - my GPG key was on my yubikey neo, and i could plug it into my laptop to decrypt passwords there or tap it to my phone to decrypt passwords there. not possible on iOS due to Apple not opening up NFC to developers, so now I have pass set up to encrypt to two keys.

[spondyl]

I think GPG keys get a lot of flack for not being the most user friendly thing and probably fair enough. The nature of them having to remain secret, makes managing them a bit confusing. I don't use mine for anything more than signing commits and (rarely) encrypting secrets

Personally, I use OpenKeychain[1] on Android, Kleopatra[2] on Linux, GPG Suite[3] on macOS and Pass[4] for iOS/iPadOS

Phew, that's a lotta apps but you can just pick and choose whatever you prefer. I have no idea about Windows myself. Once I imported my keys (public + private) into each application, I never really had to touch them again.

As I mentioned, I use my GPG key for signing my commits. I think I saved my password to my laptops keychain so it automatically signs my commits without my interaction.

Similarly, Pass automatically encrypts and decrypts everything without my interaction. Whether that's a good idea security wise aside, it works fairly seamlessly. Pass on my iPad is quite literally just a pull to refresh. I would have thought it'd be much more painful with all the GPG nonsense in play!

So, back to your questions:

> Does your setup require copying the same key to each device?

Yes but only once. It may also require entering your password anywhere from everytime to never depending on your settings. For my android device, I have to do it once every restart but after that, a process keeps my "store" open for example.

> What would happen if someone got your gpg key?

Presumably they could take all of my passwords and sign my Git commits as if they were me.

Personally, I have no strong investment in my GPG key, nor am I someone well known so this would have little to no effect beyond being a big annoyance. I would still own my email account so I'd still be able to reset the majority of my passwords.

Actually, I don't know my email password (since it's randomly generated) so I'd have to cross my fingers and hope the attacker hasn't revoked any of my sessions. Once again, no different than any other password manager. At least losing the key would be my fault, and not that of a third party I suppose.

> What would happen if you lost the key?

Presumably I'd lose all of my passwords but once again, that's no different than the single master password setup of those cloud based password managers.

I didn't realize until I looked it up just now but you can apparently generate a revocation certificate, separate from your key. From what it says on the tin, I imagine you can keep that safe and if you did lose your key, use it to tell any of the popular key servers that it's gone.

That wouldn't do anything to get your password back though, it would just signal to anyone looking up your key, that they shouldn't trust it.

Anyway, that was a bit of a tangent but the best way to learn is to just play around with GPG keys. The only reason I know the little I do is purely through making mistake :) I went through heaps of keys myself (I forget why) before I finally settled on my current one. You can even see some revoked ones here http://keys.gnupg.net/pks/lookup?search=marcus%40thingsima.d...

[1] https://www.openkeychain.org/ [2] https://www.openpgp.org/software/kleopatra/ and https://kde.org/applications/utilities/org.kde.kleopatra [3] https://gpgtools.org/ [4] https://github.com/mssun/passforios

[jarfil]

For Windows there is Gpg4win, which includes a port of Kleopatra.

[spondyl]

Thanks! I'm actually moving to a Windows environment for development shortly so this is handy to know. I'll likely just use pass via WSL2 but I might give gpg4win a shot too

[dancek]

Thanks for taking the time to answer! It's great to hear the system has good usability on multiple platforms once set up.

I guess my problem has been trying to make things perfect at once, and learning about subkeys and revocation certificates and how they apply to pass (they don't, I think) is a lot of work.

Maybe I'll just try it out, keeping my email and money-related passwords out of the equation for now.

[_-___________-_]

> Pass on my iPad is quite literally just a pull to refresh. I would have thought it'd be much more painful with all the GPG nonsense in play!

FWIW, the pull to refresh effectively just runs `git pull`. GPG isn't involved.

[spondyl]

Ah yup yup, that is true. For some reason, I always have this idea that it's pulling and decrypting everything. Gotta remind myself that computers are actually fast and decryption can happen on the fly :)

[tbrock]

Sadly this isn’t a modern solution. People have smartphones and occasionally have to login to Windows (without WSL).

While I’d love for everything I use to provide an easily accessible *nix shell it just isn’t practical for phone use or modern computing environment where you can access cloud data using web services from any internet connected computers/devices.

[Gorgor]

I have a smartphone and use pass via the app Android Password Store [1]. You have to set up your GPG key of course and also an SSH key for the sync with the remote repository, but once that’s done, it works perfectly fine.

[1] https://github.com/zeapo/Android-Password-Store

[yorwba]

There are other clients: https://www.passwordstore.org/#other

FWIW, using Termux on Android enables practical phone use of many command line programs.

[e_proxus]

That's why I decided to trust a commercial password manager (in this case, 1Password). Rather than trudging some unknown third party developer on each mobile platform, I'd rather trust a more official provider on all platforms (which also gives me the increased usability and larger feature set).

Since I absolutely need a cross platform password manager, especially on mobile, I felt this to be the most logical solution.

[333c]

On iOS I use this open-source client:

https://itunes.apple.com/us/app/pass-password-store/id120582...

[lgunsch]

I used LastPass specifically because 1Password does not work on Linux. At least up till a year ago, which was the last time I checked, the 1Password extension doesn't run on Linux.

[lasdfas]

It really surprises me that people are using pass or any other password manager developed as open source.

Yes, the code is open source, but unless you download the code yourself and compile it, which not many people do on desktop and no one does for mobile clients, you have to trust the deploy process of a random group of people. None of the people even have to be malicious. They just have to have an insecure deploy process (which allows an attacker to insert code), which is extremely common in open source. Very few if any open source projects have audited their deploy process and have monitoring for vulnerabilities or exploits happening. It's just too time intensive/expensive for a side project someone isn't getting paid for.

I prefer to trust an organization that has gone through tons of audits. Not just on whether the client is secure (can encrypt securely), but that their software development lifecycle is secure. They also have a huge financial incentive to keep things secure, which is not the case in open source.

[xhcudjchv]

pass is a single ~700 line shell script wrapping gpg and optionally git.

while long for a shell script, that's pretty easy reading for a password manager, and easy enough to understand.

[lasdfas]

Yeah absolutely. But have you audited the mobile apps or the chrome extensions, etc. (Extensions can update in the background without interaction)? Every time a new release happens? Those products are created by completely different developers.

Not saying that a company could not have a malicious release. It could. I just think the odds are much lower because their release process has better security controls and is generally audited better.