Live data from Hacker News

Proton Pass: Open-Source and Encrypted Password Manager App

proton.me

61–70 of 114 posts

Re: Proton Pass: Open-Source and Encrypted Password Manager App

#61

It grinds my gears when password managers bundle 2FA/MFA without pointing out how this weakens the security of it, or discussing mitigations. "Proton Pass makes 2FA easier with an integrated authenticator that stores your 2FA codes and automatically displays and autofills them." Is it really multiple factor auth if you're using the same device for the password and automatically filling in the token? It's not a unique…

> Is it really multiple factor auth if you're using the same device for the password and automatically filling in the token 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 p…

So you're saying it's insecure anyway. So why bother? Hmm.

Re: Proton Pass: Open-Source and Encrypted Password Manager App

#62
post #3

It's amazing how many new products Proton manages to make while still barely supporting their VPN on Linux. On the one hand, nice work proton team. On the other, you lost a VPN customer today.

For what it's worth, their written-from-scratch new Linux app is in pre-release now: https://protonvpn.com/support/linux-prerelease/

Any idea if the new one removed all the dependency on systemd? I know it's the most common among distributions, but plenty of popular ones are using OpenRC, for example, and can't use their client at all because of it.

Re: Proton Pass: Open-Source and Encrypted Password Manager App

#63
post #51

Earlier quoted context omitted.

> Is it really multiple factor auth if you're using the same device for the password and automatically filling in the token? 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

You might say those are 2 factors, but when it's happily auto-filling passwords and MFA codes automatically, uhh, that's a lot of trust in computer built to run arbitrary code, let alone Javascript etc in a browser environment! Maybe it's 1.5 factor? It's not truly separate. To encourage people to do this with no warning is irresponsible. Variants of timing attacks that can result in arbitrary code execution come out…

Expecting users to remember individualized passwords and maintain separate authentication factors for every service is placing a lot of trust in the user! I think this is a case where it's reasonable to think that automation might actually lower the overall risk.

Furthermore I don't think maintaining individual factors for every service would protect you very much against a browser compromise.

Re: Proton Pass: Open-Source and Encrypted Password Manager App

#64
post #58
post #56

Earlier quoted context omitted.

I agree with you, but I think a majority of users are fine with being on one ecosystem, as long as it is convenient. iCloud Keychain works on Windows and Chrome using an extension provided by Apple. It is possible to login using passkeys on another device outside of the ecosystem by using QR codes.

Oh sure, but that's not necessarily Proton's market - that's what I'm pointing towards. There's a group of folks who are both most likely to use a password manager, and also don't necessarily want that password manager attached to their Google/MSFT/iCloud accounts.

You're right, that's a very good fit for Proton's users.

Re: Proton Pass: Open-Source and Encrypted Password Manager App

#65

Earlier quoted context omitted.

> Is it really multiple factor auth if you're using the same device for the password and automatically filling in the token 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 p…

So you're saying it's insecure anyway. So why bother? Hmm.

I think I'm saying:

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?

Re: Proton Pass: Open-Source and Encrypted Password Manager App

#66

It grinds my gears when password managers bundle 2FA/MFA without pointing out how this weakens the security of it, or discussing mitigations. "Proton Pass makes 2FA easier with an integrated authenticator that stores your 2FA codes and automatically displays and autofills them." Is it really multiple factor auth if you're using the same device for the password and automatically filling in the token? It's not a unique…

> But the link with the key in the URL hash is public.

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

Re: Proton Pass: Open-Source and Encrypted Password Manager App

#67
post #27
post #23

Earlier quoted context omitted.

If you can cite some sources, I will be very interested to read all about it. I trust Proton with most of my crucial e-mails(bank, insurance, govt services) and use a cheap alternative for personal things. If it is really a NSA honeypot, I'd rather let M$ or GOOG have my e-mails anyways.

No real sources but hn comments, but hey if the river sounds.. 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

I guess you are referring to Crypto AG

https://en.wikipedia.org/wiki/Crypto_AG

Re: Proton Pass: Open-Source and Encrypted Password Manager App

#68

I know it may be nitpicking or just pedantic, but they say on their page "Your data also never goes to the cloud, as we own and manage our own server infrastructure." But...if you upload your data to their servers (so it can go to all your devices), isn't that the "cloud"?

I think in general one might consider "the cloud" to be virtual resources on hardware shared with third parties. So of course AWS/GCP/Azure, but DigitalOcean would probably also qualify since to my knowledge droplets are virtual servers on shared hardware. Although renting virtual resources on shared hardware can be convenient (much easier to provision virtual resources than real servers), there are a couple of drawb…

Isn't the term "public cloud" invented for this distinction?

Re: Proton Pass: Open-Source and Encrypted Password Manager App

#69
post #3

It's amazing how many new products Proton manages to make while still barely supporting their VPN on Linux. On the one hand, nice work proton team. On the other, you lost a VPN customer today.

We appreciate your feedback. We wanted to let you know we're currently working on a new app. In general, the Linux app does lack features in comparison to our Windows application, this has to do mainly with 1) the fact that the Linux team is quite small compared to the window team and 2) the linux team is quite recent. Differently than the other platforms, Linux is an extremely fragmented OS. To support it means supporting a galaxy of combinations among distributions, network subsystems, service subsystems, key stores, desktop environment. In the last year we have been working hard to re-build the foundations of a new Linux application from the ground up. The new app is designed to be solid, extensible, and future-proof, and will allow our engineers to ship faster new features, like WireGuard, and all those that are presently missing from the current app. The alpha has been released, which you can check out here: https://protonvpn.com/support/linux-prerelease/. We're working towards a public beta. Rest assured, our aim is to have the linux app on par with the other clients. The new version (v4) is very flexible and it will be much easier for the community to contribute.

Re: Proton Pass: Open-Source and Encrypted Password Manager App

#70
post #8

It seems only the clients are open source? https://github.com/orgs/protonpass/repositories

Yup, for proton open source means client code only

I tend to think this is a fair trade-off for services like this because: 1) for end-to-end encrypted services, I think what you most want to verify is: is my data actually being encrypted with my keys before being sent over the network, which open-source clients allow you to do 2) you can't personally verify what code is running on a company's servers anyway

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.

Post reply on HN