Proton Pass: Open-Source and Encrypted Password Manager App
proton.me
proton.me
I look at the cloud as something I can spin up a new service or VM very quickly. Think AWS, or Azure or whatever other service lets you quickly and easily deploy something.
We've now gotten to the point where people are saying any computer on the internet is "the cloud" and I don't think that's right or wrong necessarily, but for the sake of Hacker News, I do wish we were a little more specific.
That said, I think this argument from Proton is bordering on funny word play to make it seem different.
I don't feel like my passwords should be stored "somewhere, not here". They should be stored "here" - where I choose to store them, and nowhere else.
I purchased a hardware password manager a while back, which seemed really neat:
But, sure enough, bulk import uploads all of your passwords to their servers, even though there's just no rational reason why a server "somewhere, not here" needs to play man-in-the-middle to all your logins. To avoid it, you have to go one by one (even then there's no assurance, but the official docs do not say it's sent up to their servers).
If you read "cloud" as "somebody else's computer" it entirely depends on perspective.
If you're running a service on your own hardware in your own datacenter, you're clearly not cloud.
However, if you're a user of that same service, and your data lives on some computers that are running in someone else's data center, then for all intents and purposes your data is "in the cloud". It's indistinguishable if the service you're using is using AWS/Azure/etc, running their own hardware, and/or storing data on something like S3.
There's of course a mix of in between stuff that makes this 10x more complicated: if it's a rented server in somebody else's datacenter, are you "cloud" or not? What if it's your hardware, but somebody else's datacenter? What if you store backups on S3?
Although renting virtual resources on shared hardware can be convenient (much easier to provision virtual resources than real servers), there are a couple of drawbacks. Most importantly, particularly from a password management perspective, running on shared hardware could expose your virtual resources to hardware exploits like the row hammer effect.
Mistakes happen in the most secure systems. The more layers of defense you have, the less likely a mistake causes an incident.
Applied to this particular context, the colloquial interpretation doesn't make any sense whereas the technical interpretation does.
https://www.merriam-webster.com/dictionary/cloud%20computing
and to a lesser extent: 3) there could be legitimate security reasons to keep server code confidential 4) there could be legitimate competition reasons to keep server code confidential
Overall I think it is a fine tradeoff. And of course, there is already a great "full-stack open source" password manager out there, in Bitwarden.
There's an argument to be made we shouldn't call the whole thing "open source" and perhaps call it "open client" or something.
If this is ever the case, it means the server code has been written in a horribly vulnerable way and you should never use it.
On the one hand, nice work proton team. On the other, you lost a VPN customer today.
If I enable the kill switch, it can convince itself there is no network connection (for itself) because of its own kill switch. I turn the kill switch off and back on and it's fine. That's ridiculous.
They only support udp and tcp in their Linux app. The Android app literally has more features and stability.
On the other hand, now that I've switched to mullvad everything is at least apparently fine. I've been submitting error logs to proton for years, I was one of their first customers and really really wanted them to be good. Instead they just ask me to switch between tcp and udp over and over to provide new logs despite not installing a new version. It's pathetic.
And no, I don't buy the Linux market share thing when it's a VPN! Lol, it's not a video game. Their competitors seem to work great and value the Linux market. Years is enough patience, they redesigned their logo, released drive, and released this without fixing the basic issues with their existing products.
I'm done trying, it's wasting so much time trying to deal with their support now that they clearly just don't care about it. So I'm done.
[1]: https://github.com/ProtonVPN/linux-app/issues/110
I've even written a couple of tools that manage my connection through the CLI automatically and it all Just Works. The only issue I ever had was when I had to force shutdown my machine for an unrelated reason and I didn't have an internet connection until I opened and closed Proton VPN. I'm sure someone smarter than me could have just reset the interface they were using or something
Wouldn't $linuxuser just not simply install something like keypass w/o having to pay for anything? How many services/apps is the average linux user paying for?
I have used linux for ages before I moved to maco. So my bet is: not much. Why then, as a company, would I try to get people to give me money when they are used to getting stuff for free? And would rather tinker with some half-arsed solution (on average) instead of paying $5 per month?
Maybe sentiment has shifted since I was around. Maybe it was the Arch crowd. But my impression was: "I want it free as in free beer and open".
You might suggest your support team repeat what you said rather than an endless loop of submitting logs with no timeline for a fix or obvious intent to release one at all. In lieu of any other information or even meaningful acknowledgement of the problem, I gave up and switched to mullvad. I waited three years for this to work right and your comment is the first I've heard that there is even a Linux team working on it.
I'm using the most recent Ubuntu LTS version recently reinstalled with no other customization to the network configuration. This shouldn't be a hard target to make work. And to be clear, this is two different Ubuntu desktops with different CPU vendors manufactured seven years apart. Maybe it's just me but when I get the same issues over clean reinstalls of the OS over multiple years and multiple computers using one of the most popular distributions...
I dunno, but releasing (at least three!) new offerings while I'm sitting here for years sending bug reports sends a message about priorities.
They didn't even feel it was worth mentioning that there is an alpha to test! So bad!
The point is to combine something you know with something you own. The thing which you own can contain your passwords too.
Yes, the two factors are having the device with the password database on it, and knowing the unlock code for the database or being the biometrically identified owner
Furthermore I don't think maintaining individual factors for every service would protect you very much against a browser compromise.
No it's not, but plenty of services force MFA, even if the user doesn't want it. And in those scenarios it seems perfectly reasonable to store the 2FA token in a password manager. For some things (frankly most things) 2FA isn't critical as long as you have a high-quality password.
I would also point out that given that most people:
1. Have 2FA codes on their phone (either as SMS or TOTP)
2. Have their password manager installed on their phone (if they use one)
Then in many ways the phone (something easily lost!) becomes a single point of failure anyway.
1. The case in which 2FA is really key is when you have short password (or worse, a reused password). That leaves you open to bruteforce attacks, and attacks where your email/password combination that was leaked from one service is reused to gain access to another service. But this is generally much less of an issue with a password manager where you are likely using a long random password that is unique per service.
2. 2FA is still an extra layer on top of this, but perhaps isn't super necessary for a lot of less critical services. The chances of your password being compromised are pretty small.
3. Particularly with SMS 2FA, there may be attacks which are present for that that are not present for password-manager based TOTP. For example, attackers may be able to read SMS messages off a phone's lock screen without unlocking the phone. So it's not obvious that this is strictly worse than other options.
4. I think the ideal (aside from U2F tokens) is probably 2 separate password managers, syncing to different clouds (if syncing): a first factor one and second factor one. If one is being really picky: then on separate devices. But this seems like it's probably overkill in most circumstances. Perhaps it makes sense to do something like this for a few key accounts (email, etc), but not everything?
Only if is shared publicly. The fragment (part of the URL after the hash) is not sent back to the server by browsers. It can also be coupled with a password which can be sent over a second channel when one is more concerned about the communication channel being compromised, than convenience.
Disclaimer: I work on Proton Drive
Btw, the thing you mention for Proton Drive is only for files which are shared publicly. For sure the audit results are not perfect when viewed in isolation, but when compared to other password managers, it's another story.
If my Bitwarden vault gets leaked AND their encryption gets broken, I’m fucked anyway. So I might as well just store my 2FA keys in it too.
I’m more interested in protection against keyloggers, and leaks from the database of the sites I use. And for my critical accounts (Gmail…) I use a physical key for 2FA.
IMO it does not make sense to use any service from your VPN provider at the same time - it's like not using a VPN at all since they do know your real IP. No idea why this is not known to more people.
Not sure what you mean?
With how common hardware security keys (or even just tpm2) are these days this limitation seems inexcusable to me. Which is why I'll stick with gopass/pass using my yubikey (w/ touch policy fixed). You might hack my machine and trick me in to decrypting a few passwords, but at least you won't make off with them all.
EDIT: Credit cards are available. Somehow I missed that! Might have gotten released in the time since I tried it which hasn't been long at all...
Really, I think the alias feature should be added into protonmail and removed from proton pass.
Bitwarden UI has the edge though, imo.
I am sticking with Bitwarden.
So if you are happy with your setup, stick with it and no need to move to Proton pass. Maybe keep an eye and check back after few months if their offerings have changed or upgraded that is worth the effort and shifting trust.
I personally would sign up as first year is free/cheap and I like proton products, although somewhat buggy they are trustworthy and worth supporting. And I am using KeePass as my password manager which is cumbersome to selfhost and manage. I am not giving up on using KeePass yet as I too will wait to see where Proton pass ends up being.
If it is really a NSA honeypot, I'd rather let M$ or GOOG have my e-mails anyways.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
The NSA/CIA are just too good at hijacking swiss -neutral- companies for their own bidding
https://en.m.wikipedia.org/wiki/ProtonMail#Compliance_with_S...
edit: I'd like to inject a reminder that protonmail doesn't encrypt all of your mailbox contents. From their privacy policy:
"we have access to the following email metadata: sender and recipient email addresses, the IP address incoming messages originated from, attachment name, message subject, and message sent and received times"
Is there any of that that’s not basically required by the fact that they’re running an _email_ service?
If I remember correctly: one of the reasons they don't encrypt that metadata is so they can do the search box server-side.
Pass, uninteresting product.