setting the password through the web app is a bad security model

[alkeryn]

Steps To Reproduce

you claim that you are "zero trust", but the fact is the master password cannot be set from the desktop / mobile client and only through your web app.

this means that we have to trust your website not to steal the master password.
even if no ill intent is present, this is a point in the chain that has to be trust.

let's say your server decided at any point to serve custom javascript (be it from your decision, or because someone compromised your server) the master password could be stolen.

with a proper trust model, the master password should only be setable through a localy running client, or at least it should be an option.

being redirected to a web page to set it for something that is supposedly "zero trust" is just crazy.
i may consider using your services if this get fixed, otherwise no thank you.

Expected Result

being able to set the password from the desktop / mobile clients

Actual Result

we are redirected to a web page that fundamentaly cannot be trusted.

Screenshots or Videos

No response

Additional Context

No response

Operating System

Linux

Operating System Version

arch, lattest

Web Browser

Brave

Browser Version

lattest

Build Version

lattest

Issue Tracking Info

• I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

[Krychaz]

Hi,

Please have a look at our security whitepaper to get insight into our security mechanisms and architecture - https://bitwarden.com/help/bitwarden-security-white-paper/

We use GitHub issues as a place to track bugs and other development related issues. As this is not a bug, this issue will be closed now. Please use our forums https://community.bitwarden.com/ if you would like to discuss this topic with our community.

[alkeryn]

@Krychaz i don't care about your white paper, the issue mentioned is objectively a bad design, you can't claim "zero knowledge" when the master password can only be set through your web app which could at any time serve compromised js.

this is an universal issue.

this would only be valid if the master password could be set through open source clients that can be audited.

there is no technical reason to not be able to set it through the localy installed client.
the fact that we have to do it through the web app basicaly make it no longer "zero trust" / "zero knowledge" the users cannot trust that you are not gonna steal the master password when it is being set by sending custom javascript to him specificaly.

you also say that the master password is never stored, but you cannot trust your word for it since it can only be set through a web page of which your server can send different javascript at any time.

[pamperer562580892423]

Another user here. (= not a Bitwarden employee)

this means that we have to trust your website not to steal the master password.
even if no ill intent is present, this is a point in the chain that has to be trust.
[...]
Expected Result
being able to set the password from the desktop / mobile clients

So, you don't trust Bitwarden's own web app (web vault) - but you would trust Bitwarden's own desktop app or mobile app? You do realize that the web app is developed by Bitwarden just as their desktop app and mobile app? - I guess everything you are suspicious of with the web app could potentially also happen with the desktop app and mobile app ?!

[alkeryn]

@pamperer562580892423 the desktop and mobile app can be audited since they are open source and can be built locally (and are if you use stuff like nixos or gentoo).

their web app on the other hand could serve a perfectly safe login system then target specific users by sending another js such that they can steal the master password.

yes you could think it as an unlikely scenario, but they shouldn't even be able to do that.
they can't say they are "zero trust" or "zero knowledge" when you have to trust them not to send you a malicious login page.

there are NO technical reasons that prevent setting the master password from the client side.
you are effectively not building an ideal security product for no technical reason at all.
just the fact that it isn't an option makes me suspicious.

it is well known that "zero trust" application where the decryption key is dependant of your password are worthless when used through a web app, this was a common criticism of MEGA by many security analysts.

I guess everything you are suspicious of with the web app could potentially also happen with the desktop app and mobile app ?!

no because as said, these can be audited and you can guarantee that a specific version and deterministic build is not stealing your master key.
you cannot have that guarantee for a web page that can change at any time or for specific high profile users without notice or auditability.

just the fact that you cannot set and change the master password from the desktop / mobile client makes me suspicious of their whole software stack because it is objectively a terrible decision regarding security especialy if you are gonna advertise yourself as "zero trust" or "zero knowledge".

also in the case of self hosting, this also mean that if your server is compromised they could steal your password.

this software could be written in such a way that it is secure even if the server is compromised or untrusted and it isn't.

[pamperer562580892423]

the desktop and mobile app can be audited since they are open source and can be built locally

It seems your premise is wrong, as you can see here that also the web app is part of audits: https://bitwarden.com/help/is-bitwarden-audited/

[alkeryn]

@pamperer562580892423 maybe refresh the page i edited my previous reply.

yes, the web app is part of audits, but you are missing my point, it could be perfect for 99.9% of users and they could chose to send a malicious login page for specific high value users.

the whole point is that you have to trust that they are not sending you a malicious login page, when you shouldn't even need to.

and as i said previously:

also in the case of self hosting, this also mean that if your server is compromised they could steal your password.
this software could be written in such a way that it is secure even if the server is compromised or untrusted and it isn't.

basicaly it boils down to the attack surface being much higher than it needs to be, for no technical reason whatsoever.
you should not have to trust the server, it should be safe even if it was compromised by bad actors.

[pamperer562580892423]

yes, the web app is part of audits, but you are missing my point, it could be perfect for 99.9% of users and they could chose to send a malicious login page for specific high value users.

No offence, but your whole argument is circular in a way. Bitwarden's cloud servers are also updated regularly - so to spin your argument further: why trust the respective next server version (which is the "basis" for every BW client/app that communicates with the server data)?? - Your argument probably ends in: you can't trust Bitwarden at all. It seems you should either self-host Bitwarden - and therefore control both the server version and web versions (but then you will probably run into compatibility problems with newer client versions and suffer from missing security updates) - or you should probably devise your own password manager that you can trust completely.

[alkeryn]

@pamperer562580892423 my whole point is that the server shouldn't need to be trusted at all.
this should be safe even if the server was entirely compromised and it isn't.

and as i mentioned, that's still an issue for self hosting, if your server gets hacked for example, they could steal all your password just by waiting for you to change the master password or login in the web app.

my whole point is that it can be written in a way that you don't have to trust the server even if it was fully compromised and it curently isn't, you should be able to set and change the master password from the mobile and desktop client.

it can be written in a way that you don't have to trust the server at all and it isn't, this make me suspicious of the software as a whole and company.

this is effecitvely increasing the attack surface for no reason whatsoever, the only device that should need to be trusted is the one that runs the client, not the server powering their cloud offering, neither your server if you choose to self host.

the whole point of a zero trust architecture is that you don't have to trust the server, it could be fully compromised and it'd still be safe.

this isn't the case.
hence, their advertisement is false and the design is sub optimal.

the fix for it is near trivial.

or you should probably devise your own password manager that you can trust completely.

i could do that, but i'm already busy enough as it is, "muh build your own" when pointing an obvious and easy to fix flaw isn't a good response especialy if a company advertise itself as a security product and their product isn't actualy as secure as it could be.

this is among the most unexperienced kind of mistake you can make when building zero trust software, the whole point is that it should be ZERO trust, ie, you don't have to trust their server to know that your data is safe.

what's the point of end to end encryption if they could steal your master key by sending you a malicious login page whenever you want to set or change it.

[alkeryn]

@pamperer562580892423 honestly the more we talk about it the more i want to make a competitive company out of spite and have the first entry in the blog post that bitwarden is unsecure for that exact reason, they claim to be "zero trust" but you actualy have to trust the server, which you shouldn't have to.

heck, they should even recomend against loging in from the web page, and the recomended way to set the master key should be through the client.

they could also offer deterministic builds to guarantee that they don't ship a binary with added malicious code, that i care less about because i build myself anyway.

all to say, the security of this product is sub optimal.

[pamperer562580892423]

@alkeryn ... if you care that much about it, then you're invited to help improve it: https://contributing.bitwarden.com

PS:

when pointing an obvious and easy to fix flaw isn't a good response especialy if a company advertise itself as a security product and their product isn't actualy as secure as it could be.

Please remember, that I'm not a Bitwarden employee. Nothing I wrote is an official response from Bitwarden.

[alkeryn]

@pamperer562580892423 i understand that you are not an employee but this discussion allowed to get my point accross, hoping an employee will read it.

they know their software, it would take very little time to add that feature, it's an easy fix.
it'd take me at least twice as much time because i'm not familiar with their codebase, and again, i'm busy enough as it is.

also even assuming i'd want to make the change myself, i'd first need to be sure they actualy consider it an issue as to not waste my time.

for all we know this "vulnerability" was made on purpose for gov spying, technicaly the government could ask them "if this specific user try to change his master password, send him a malicious login page and recover it" this would pass through audits as for most users, they'd get the normal page.

anyway, as a starting point i'd like it to be recognized as an issue, then maybe i'll think about making a PR.

[willrabbermann]

Don't trust bitwarden, they glow in the dark. Switch to an offline only database like keepassxc that doesnt interact with the web unless you put the database on a mountable network filesystem.

[alkeryn]

@willrabbermann yea, that's what i plan on doing, my whole point is that it glows from a billion miles.
i'll probably eventualy write my own, and maybe make some meme company out of it.

[quexten]

Hi! I've converted this into a discussion.

To address your points; It is true that if the web server is serving you a malicious web vault, it can exfiltrate your decrypted data after you unlock. Compromised clients are generally out of scope for security issues.

If this is within your threat model, and the web vault being tampered with is a real concern to you, for instance because your TLS channels are being MITM'd by your country via a root certificate that's on your system, by your work place, or simply because you don't trust the Bitwarden cloud servers, then you should not use the web vault.

Subsequently, not being able to use the web vault means certain features - such as password change - are currently unavailable to you. I've reached out and it seems there are plans to make password change available on other clients, but there is no concrete timeline I can provide.

[alkeryn]

Hey !
thank you for addressing the issue, sorry if i happened to sound a little harsh.
but i am happy it is considered as one.
from my standing you shouldn't need to trust the server, even if it was fully compromised it should still be safe to use.

thank you for reaching out !

in the meanwhile do you have some api docs regarding the master key changing ?
maybe as a bandaid i could write an external tool that could set it in a way that it is guaranteed the data was not exfiltrated.

thank you !

[quexten]

The simplest approach here is self-hosting the web vault. You can just build it directly from the git repo, though there may be some issues with CORS when talking to the cloud server api via a locally hosted client.

If you want to re-implement it, I can provide some pointers, but there is no publicly documented API:

clients/libs/angular/src/auth/password-management/change-password/default-change-password.service.ts

Line 50 in 60aaa39

const decryptedUserKey = await this.masterPasswordService.decryptUserKeyWithMasterKey(

https://github.com/bitwarden/clients/blob/main/libs/common/src/auth/services/master-password/master-password-api.service.implementation.ts#L33

You'd also need to implement login:

clients/libs/auth/src/common/services/login-strategies/login-strategy.service.ts

Line 311 in 60aaa39

async makePreloginKey(masterPassword: string, email: string): Promise<MasterKey> {

clients/libs/auth/src/common/login-strategies/password-login.strategy.ts

Line 78 in 60aaa39

override async logIn(credentials: PasswordLoginCredentials): Promise<AuthResult> {

However, I'll note that the implementation should be heavily tested on a test account before you use it on your account. It's easily possible to end up in an undecryptable state if any part of the crypto is wrong.

[dwbit]

Hi everyone, closing this one out as it does not contain a code contribution proposal for review. For futher discussion, please use other community spaces like the forums, or Reddit.