Feature Suggestion | Jurisdiction should be a criteria for online password managers #1915

Open
opened 2020-05-13 16:17:33 +00:00 by cyanlemons · 10 comments
cyanlemons commented 2020-05-13 16:17:33 +00:00 (Migrated from github.com)

Description

Online password managers are a critical centralized point of failure that should be subject to the same level of scrutiny as "Providers."

Bitwarden is based in the United States (incorporated in Delaware) and is therefore situated in one of the Five Eyes. Bitwarden could, if they so desired, serve a user backdoored JavaScript which would collect the user's cleartext password.

Furthermore, the United States currently has the legal capacity to serve Bitwarden a gag order (otherwise known as a national security letter) along side a warrant for an individual's password and data.

At the very least, I believe there should be some kind of warning regarding the jurisdiction – in the same way there is a "contrib" warning for non-free software.

Threat model

A law enforcement entity discovers a ProtonMail account of interest. This entity unsuccessfully attempts to persuade the Swiss Judiciary into approving a warrant for all inbox metadata (subjects, to, from).

In an attempt to circumvent the rejection from the Swiss Judiciary, this entity serves gag orders and warrants to all US-based password managers in hopes that one of them will have an account under the same email address.

It so happens that the individual of interest has a Bitwarden account. Bitwarden is coerced and threatened into serving backdoored JavaScript to the individual of interest to obtain their password and decrypt their data.

At this point, the law enforcement entity can simply login to the desired ProtonMail account with the credentials that were (potentially) obtained from the Bitwarden account data.

## Description Online password managers are a critical centralized point of failure that should be subject to the same level of scrutiny as "Providers." Bitwarden is based in the United States (incorporated in Delaware) and is therefore situated in one of the [Five Eyes](https://www.privacytools.io/providers/#ukusa). Bitwarden could, if they so desired, serve a user backdoored JavaScript which would collect the user's cleartext password. Furthermore, the United States currently has the legal capacity to serve Bitwarden a gag order (otherwise known as a national security letter) along side a warrant for an individual's password and data. At the very least, I believe there should be some kind of warning regarding the jurisdiction – in the same way there is a "contrib" warning for non-free software. ## Threat model A law enforcement entity discovers a ProtonMail account of interest. This entity unsuccessfully attempts to persuade the Swiss Judiciary into approving a warrant for all inbox metadata (subjects, to, from). In an attempt to circumvent the rejection from the Swiss Judiciary, this entity serves gag orders and warrants to all US-based password managers in hopes that one of them will have an account under the same email address. It so happens that the individual of interest has a Bitwarden account. Bitwarden is coerced and threatened into serving backdoored JavaScript to the individual of interest to obtain their password and decrypt their data. At this point, the law enforcement entity can simply login to the desired ProtonMail account with the credentials that were (potentially) obtained from the Bitwarden account data.
danarel commented 2020-05-13 16:43:35 +00:00 (Migrated from github.com)

Bitwarden, as in your example, offers a self-hosting option. So does the rest of our main recommendations.

So if your own personal threat model is as such that the location of your password manager server is an issue, you can host it where you please.

Bitwarden, as in your example, offers a self-hosting option. So does the rest of our main recommendations. So if your own personal threat model is as such that the location of your password manager server is an issue, you can host it where you please.
blacklight447 commented 2020-05-13 19:22:54 +00:00 (Migrated from github.com)

also, we are considering dropping the "no usa" rule once we redo our jurisdiction page.

also, we are considering dropping the "no usa" rule once we redo our jurisdiction page.
cyanlemons commented 2020-05-13 21:07:27 +00:00 (Migrated from github.com)

@danarel That does not escape the fact that the overwhelming majority of people will simply use Bitwarden directly. Most people do not have the resources or technical know-how to set up a VPS and run their own instance of Bitwarden. If the majority of people will inevitably use a service in a certain way, I believe there should at least be a warning of the implications of said use.

In fact, a similar type of warning is already in use. Jami currently has the following warning: "This software is partially centralized but can be self-hosted." Bitwarden is also centralized and has jurisdiction concerns that can be mitigated by self-hosting, but only if one actually goes through the trouble of doing so. I see no reason to have the warning for Jami if it will not be present for Bitwarden.

@blacklight447-ptio I can understand dropping the "no USA" when it concerns entities that could not break the encryption even if they were so compelled. For example, even if Moxie Marlinspike did absolutely everything in his power to break Signal's encryption, he would fail. Signal has reproducible builds. All the encryption is done on the client side on open source software that can be recompiled to obtain the same result. It's extraordinarily public, transparent, and verifiable. Web-based services that depend upon JavaScript are the exact opposite.

If the "no US" requirement is dropped for ALL SERVICES, including those that CAN be compelled to break their encryption (such as Bitwarden), I believe this would be a severe mistake that would result in the depreciation of privacy for many.

@danarel That does not escape the fact that the overwhelming majority of people will simply use Bitwarden directly. Most people do not have the resources or technical know-how to set up a VPS and run their own instance of Bitwarden. If the majority of people will inevitably use a service in a certain way, I believe there should at least be a warning of the implications of said use. In fact, a similar type of warning is already in use. Jami currently has the following warning: "This software is partially centralized but can be self-hosted." Bitwarden is also centralized and has jurisdiction concerns that can be mitigated by self-hosting, but only if one actually goes through the trouble of doing so. I see no reason to have the warning for Jami if it will not be present for Bitwarden. @blacklight447-ptio I can understand dropping the "no USA" when it concerns entities that could not break the encryption even if they were so compelled. For example, even if Moxie Marlinspike did absolutely everything in his power to break Signal's encryption, he would fail. Signal has reproducible builds. All the encryption is done on the client side on open source software that can be recompiled to obtain the same result. It's extraordinarily public, transparent, and verifiable. Web-based services that depend upon JavaScript are the exact opposite. If the "no US" requirement is dropped for ALL SERVICES, including those that CAN be compelled to break their encryption (such as Bitwarden), I believe this would be a severe mistake that would result in the depreciation of privacy for many.
ThracianKnight1907 commented 2020-05-14 06:28:16 +00:00 (Migrated from github.com)

You can signup via the client and avoid the web-vault entirely. Maybe Privacytools should put a "tip" that this is possible and recommended? Although resetting the master password still requires the webvault, but that can be mitigated by using a very, very strong password and 2FA?

You can signup via the client and avoid the web-vault entirely. Maybe Privacytools should put a "tip" that this is possible and recommended? Although resetting the master password still requires the webvault, but that can be mitigated by using a very, very strong password and 2FA?
dngray commented 2020-05-14 09:02:23 +00:00 (Migrated from github.com)

If the "no US" requirement is dropped for ALL SERVICES, including those that CAN be compelled to break their encryption (such as Bitwarden), I believe this would be a severe mistake that would result in the depreciation of privacy for many.

The strategy we're thinking of doing is defining a list of countries that are good for privacy.

That list then will only really be a requirement for things where large amounts of unencrypted data reside, ie email.

Password services use E2EE, (really would you use one that doesn't?) so it's not relevant.

> If the "no US" requirement is dropped for ALL SERVICES, including those that CAN be compelled to break their encryption (such as Bitwarden), I believe this would be a severe mistake that would result in the depreciation of privacy for many. The strategy we're thinking of doing is defining a list of countries that are good for privacy. That list then will only really be a requirement for things where large amounts of unencrypted data reside, ie email. Password services use E2EE, (really would you use one that doesn't?) so it's not relevant.
blacklight447 commented 2020-05-14 10:09:21 +00:00 (Migrated from github.com)

Its all still up for discussion. the thing is that we don't really want to ban any countries. for example, if your and amercian whisleblower, then using a russian service might be a very smart idea, and vice versa. so instead of focusing on Country A good, country B bad, we want to focus on making people aware of whats important about jurisdictions, and what they need to keep in mind for their personal threatmodel.

Its all still up for discussion. the thing is that we don't really want to ban any countries. for example, if your and amercian whisleblower, then using a russian service might be a very smart idea, and vice versa. so instead of focusing on Country A good, country B bad, we want to focus on making people aware of whats important about jurisdictions, and what they need to keep in mind for their personal threatmodel.
cyanlemons commented 2020-05-14 14:37:54 +00:00 (Migrated from github.com)

Password services use E2EE, (really would you use one that doesn't?) so it's not relevant.

@dngray As far as I am concerned, browser-based E2EE that relies on unverifiable JavaScript coming from a jurisdiction with a long history of surveillance, compelling providers to break their encryption, and even threatening their arrest (e.g. Lavabit) – is not E2EE at all.

Even ProtonMail's E2EE is questionable, but at least they are in a somewhat reasonable jurisdiction that has no precedent for forcing service providers to break their encryption.

Although resetting the master password still requires the webvault, but that can be mitigated by using a very, very strong password and 2FA?

@ThracianKnight1907 In order to setup 2FA, I do believe you need to use their web service. There are quite a few other things too that can only be done through the webvault, such as adding account credit, upgrading to premium or changing some account settings.

Although I do agree that if a user is conscious of avoiding the web-based service, and exclusively sticks to the apps (at the expense of a few features & options), Bitwarden would be a good choice.

>Password services use E2EE, (really would you use one that doesn't?) so it's not relevant. @dngray As far as I am concerned, browser-based E2EE that relies on unverifiable JavaScript coming from a jurisdiction with a long history of surveillance, compelling providers to break their encryption, and even threatening their arrest (e.g. Lavabit) – is not E2EE at all. Even ProtonMail's E2EE is questionable, but at least they are in a somewhat reasonable jurisdiction that has no precedent for forcing service providers to break their encryption. >Although resetting the master password still requires the webvault, but that can be mitigated by using a very, very strong password and 2FA? @ThracianKnight1907 In order to setup 2FA, I do believe you need to use their web service. There are quite a few other things too that can only be done through the webvault, such as adding account credit, upgrading to premium or changing some account settings. Although I do agree that if a user is conscious of avoiding the web-based service, and exclusively sticks to the apps (at the expense of a few features & options), Bitwarden would be a good choice.
dngray commented 2020-05-14 15:20:41 +00:00 (Migrated from github.com)

@dngray As far as I am concerned, browser-based E2EE that relies on unverifiable JavaScript coming from a jurisdiction with a long history of surveillance, compelling providers to break their encryption, and even threatening their arrest (e.g. Lavabit) – is not E2EE at all.

Agreed. My personal opinion on this is that passwords don't belong in the cloud (encrypted or not).

I synchronize encrypted storage on my local network. Some people seem unable to do that...

Even ProtonMail's E2EE is questionable, but at least they are in a somewhat reasonable jurisdiction that has no precedent for forcing service providers to break their encryption.

I think they were looking into having some sort of third party notary sign their code. Not sure where that is at these days.

> @dngray As far as I am concerned, browser-based E2EE that relies on unverifiable JavaScript coming from a jurisdiction with a long history of surveillance, compelling providers to break their encryption, and even threatening their arrest (e.g. Lavabit) – is not E2EE at all. Agreed. My personal opinion on this is that passwords don't belong in the cloud (encrypted or not). I synchronize encrypted storage on my local network. Some people seem unable to do that... > Even ProtonMail's E2EE is questionable, but at least they are in a somewhat reasonable jurisdiction that has no precedent for forcing service providers to break their encryption. I think they were looking into having some sort of third party notary sign their code. Not sure where that is at these days.
blacklight447 commented 2020-05-27 13:12:51 +00:00 (Migrated from github.com)

So we would have to come to a decision, I personally do not think a jurisdiction requirement would have to be added, espeically considering that with the online manager we recommend, bitwarden, can be used mostly through the open source clients, and can be self hosted. However if we feel uneasy with it, we could add a little notification next to the listing like we did with duckduckgo.

@dngray

So we would have to come to a decision, I personally do not think a jurisdiction requirement would have to be added, espeically considering that with the online manager we recommend, bitwarden, can be used mostly through the open source clients, and can be self hosted. However if we feel uneasy with it, we could add a little notification next to the listing like we did with duckduckgo. @dngray
lynn-stephenson commented 2020-11-19 03:16:32 +00:00 (Migrated from github.com)

At least notifying users the jurisdiction of the official BitWarden instance would be nice.

But any additional instances users will have to do their own research.

At least notifying users the jurisdiction of the official BitWarden instance would be nice. But any additional instances users will have to do their own research.
This repo is archived. You cannot comment on issues.
No Milestone
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: privacyguides/privacytools.io#1915
No description provided.