Ask HN: How comfortable do you feel using cloud-based password managers?
Even though cloud based password managers have been around for a long time now, I never felt comfortable using them - the idea of handing over my important login details to some third party company seemed really weird to me. Most people might not care but the HN crowd are generally security conscious or say paranoid about security(for good reasons). But from password managers related threads, its apparent that many of you use them. So I wanted to get a general idea of how HN users feel about them.
198 comments
[ 4.6 ms ] story [ 170 ms ] threadI used to use rsync (bittorrent-sync) to keep my own hosts up to date against each other. This was painful to manage so I accepted the bitwarden cloud model.
The risks are there, for sure. If you doubt the crypto behind your keystore, where it is should worry you little because how insecure it is should not be about where it is: its about how its shrouded, and how what is shrouded can be revealed.
My belief in the shroud protecting my secrets is my belief in their ability to code to the spec. it wasn't founded in my use of a private filestore to back the keystore, although I did, and I prefer private files, to private cloud files, to cloud files hosted by some intermediary, to public cloud.
Bitwarden is a private cloud file, hosted by some intermediary. The risk here is twofold: the intermediary is broken and its persisting filestore is readable, and bitwarden is broken and its interior private view becomes visible.
My best belief is that no part of my interactions depend on bitwarden knowing the interior state of my keys, they only handle shrouded data, and either I run apps which decode locally, or I run javascript which decodes locally, but I do not expect or believe any transit of the un-shrouded state of my data routinely has to flow through their hands. And the persistence of that belief is because they say the limits to how they can help recover my keystore, if I lose critical information. if they are truthful here, they cannot help me if I lose the escrow passphrase, because nothing they hold is the decrypt of my shroud. I have to give permission to de-shroud there side, the protecting key. its otherwise only used locally to me. (if somebody breaks the .js code, then the filestore being in the cloud is irrelevant)
1Password made the same kinds of commitment to me. As do LastPass and a number of other people. They all have to be comparable in this regard because its the fundamental business model.
At one stage, there was some leakage in the model for some keystores. The file names un-necessarily encoded revealing parts of the URLs they related to. I think thats changed now. It was scary. I had assumed everything was shrouded, it turned out for some period of time, only passwords and identity inside the URL had been fully protected. They changed that. I think it was 1password, it might have been lastpass. It wasn't bitwarden because I moved to them earlier this year and that was 2-3 years ago or more.
If I have misunderstood and sometimes my data is visible to them in clear, on their machines, I'd love to know.
1Password, for instance, has a pretty good security doc about it: https://1password.com/files/1Password%20for%20Teams%20White%...
I moved from Lastpass to pass(https://www.passwordstore.org/). It's by far the best decision I've made in a long time (I've moved a lot of services over to my servers and self host pretty much everything)
I use Mac, but it works on any machine to my knowledge and the great thing is:
1. Use your keys, so ONLY YOU can only decrypt it (gpg keys)
2. Has Chrome/Firefox extensions that automatically fill out passwords
3. Can upload the encrypted passwords to git to use on other machines (presumably)
4. Dead simple to use (go on terminal and generate random passwords, bunch of other goodies)
5. As said previously, it's all on your machine, no one else having access.
Currently using keepass. I would migrate to pass since I enjoy managing data via command line, but what I don't like is depending on a gpg key being installed in order to use it.
https://itunes.apple.com/us/app/pass-password-store/id120582...
At work I’ll see people — the security team, usually — taking some already-encrypted thing and re-hardening it to the nth degree. I think that’s stupid. If you don’t trust your encryption, don’t bother using it. If you do trust it, stop there. It’s maths. It’s proven.
I feel the same about 1Password. I trust that they encrypt my stuff with trusted encryption. That’s it.
If you are encrypting a password store and using the cloud only for sync, you're trusting an encryption standard.
If you are using a cloud based password manager from a service provider, they may be using encryption, but your trust has to be in the company and their employees.
It's a rather large distinction.
No they are not. That’s one of the things that makes designing correct crypto systems difficult. Going the wrong way through most cryptographic trap doors is conjectured to be difficult but I’m unaware of a single one that’s proven.
Given a ciphertext, the only information available is its length.
You have a way to securely exchange or store the one time pad (at that point just use slices of the pad as passwords)
The pad is sufficiently random
This was how RC4 was used to encrypt things; RC4 is fundamentally a random number generator. To use it you throw away the first so many bytes (because they could be used to recover the state of the machine.) and then the rest was used as a pad. Unfortunetly patterns in the data can make it easy to recover the raw RC4 pad (uncompressed blank bitmaps for example) and this can be used (again) to recover the state of the machine generating the numbers. On top of that it turns out RC4 is a lot more predictable than people originally thought.
Essentially all a one time pad does is move the problem somewhere else, often that other place isn't great.
For example, some backup providers will encrypt your data for transport to their machines and then reencrypt them for storage. Would you trust TLS implementations in the path and provider's application to protect your data? Or would you rather encrypt yourself and only then let the provider handle it?
I prefer to store KeePass encrypted dB on Dropbox than going for 1Password cloud.
Plus Keepass is opensource...
I also find it extremely important for my password manager to be available on EVERY platform I might use. Not just the popular ones a company can make a business case to support. Historically this has been a bigger issue than at present, but its still a big one to me.
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
Plenty of other extensions, managers here: https://www.passwordstore.org/#other
Second benefit is Yubikey can hold authentication subkey that can be used to SSH to a server on a phone.
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:&...
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.
FWIW, the pull to refresh effectively just runs `git pull`. GPG isn't involved.
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/
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.
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.
> 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.
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
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.
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.
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/
Just thought I'd stick that here to save others the googling.
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.
FWIW, using Termux on Android enables practical phone use of many command line programs.
[1] https://github.com/zeapo/Android-Password-Store
https://itunes.apple.com/us/app/pass-password-store/id120582...
Since I absolutely need a cross platform password manager, especially on mobile, I felt this to be the most logical solution.
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.
while long for a shell script, that's pretty easy reading for a password manager, and easy enough to understand.
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.
Passwords are too important to evaluate a manager on convenience primarily. I think it is a little strange that banks do not work to get in this area. You trust your bank or else you would not keep your money there. I know too little about the main password manager companies to know if they are trustworthy.
I guess this is too small domain for banks but I think it would be interesting to see what happened if they moved into it.
That being said, I do have a safe deposit box with backups of important documents and a KeePass DB. The KeePass DB isn't synced as often as my local copies, but does get synced whenever I change passwords on any crucial site. I do have a copy on onedrive, but if I lose access to my password manager I won't be able to login to onedrive to access it. It's a little bit of work, but there are certain things that are definitely worth backing up in a secure location. Plus, there's a printed copy of my KeePass credentials and access information for relatives in case I'm gone.
For other people, such as family members: I totally recommend it. It is way better than whatever password reuse they are doing now, and the chances of a breach are low enough.
My point being: I think they are overall better than not using anything, but if you have the knowledge and diligence to keep an offline encrypted file (and its backup!) up to date, then I would suggest doing that instead.
[0]: https://www.passbolt.com/
That said, I use my own remote storage (not cloud) with keepass's sftp plugin.
The reason I went with the cloud sync is that I have to share secrets over multiple companies with all kinds of people and 1Password is simply the best compromise of convenience and security I found.
I have a KeePass file and use Syncthing to share it across all my devices. The keyfile is not synced and I manually send to any new device. Syncthing works well and most KeePass clients can nicely merge two KeePass databases in case of conflicts. Firefox integration with Kee.pm is really convenient.
For me this works really well. It was easy to setup and in my opinion it is very much worth it if you want to avoid third-party hosting.
Due to this, I keep all of my passwords offline, as far as possible. For mobility and comfort reasons, I developed Authorizer (https://github.com/tejado/Authorizer):
"A Password Manager for Android with Auto-Type over USB and Bluetooth, OTP and much more.
The idea behind Authorizer is, to use old smartphones as a hardware password manager only. To avoid manual typing of long and complex passwords everytime you need them, Authorizer provides Auto-Type features over USB and Bluetooth. It pretends to be a keyboard (e.g. over an USB On-The-Go adapter) and with a button press inside the app, it will automatically type the password for you on your pc, laptop, tablet or other smartphone."
It’s the same with backups. I can’t be trusted with my own data. I’d rather let someone else keep.
Additionally, using an open-source password manager that you can audit alleviates any further paranoid concerns you may have. If you also worry about the cloud provider suffering a severe outage then you can always keep offline backups. Assuming that you have the expertise and time you can implement a solution yourself but it always depends on your threat model and your level of paranoia.