Timshel / vaultwarden

Fork from dani-garcia/vaultwarden to add OpendID support.
GNU Affero General Public License v3.0
76 stars 12 forks source link

Experimental Feature (NO_MASTER_PWD) Not Working as Expected #31

Closed fabsau closed 7 months ago

fabsau commented 7 months ago

Hi @Timshel,

Firstly, I want to extend my gratitude for developing this PR that provides the much-anticipated SSO support.

I have been testing the experimental feature that omits the Master Password hash, but unfortunately, I ran into an issue. On a clean instance, I set SSO_FRONTEND='experimental' and SSO_EXPERIMENTAL_NO_MASTER_PWD=true (and, of course, properly configured SSO as needed). However, the feature doesn't seem to be functioning as intended.

Whenever I log in with a new user, I'm prompted to create a master password. As per my understanding, it shouldn't happen in this context, right? Moreover, if I follow through and create a master password, it is required for every subsequent sign-in.

Could you help me understand if I'm missing something or if there's a misconfiguration from my end? I've attached screenshots below that show my current setup.

image image

Looking forward to your guidance and support.

Best regards

Timshel commented 7 months ago

Hey

Maybe not the best chosen name for the config settings, but it does not remove the need for a Master Password ^^.

It's detailed here, not sure if you missed it or if it needs improvement :).

The idea is to stop sending/storing your Master password hash in the Server. The SSO is responsible to confirm your Identity before the server send your vault to the client, but the server don't need to know more. It remove the need to hash the password and all the need for the KDF iteration and the race to always increase it in case the DB leak.

fabsau commented 7 months ago

Thank you for your fast reply! How embarrassing ^^. I understand it now. I also have asked ChatGPT to rewrite the readme part, but I think it must have been my wishful thinking of not needed a master password anymore.

The experimental feature works by leveraging Single Sign-On (SSO) technology to authenticate users, instead of relying on storing Master Password hashes.

In typical scenarios, your Master Password is hashed (transformed into a unique, fixed-size series of characters) and the hash is stored on the server. Each time you log in, the password you enter is hashed again and compared to the stored hash to verify your identity.

However, with this experimental feature, the system no longer stores any Master Password hash on the server side. Instead, the SSO service is responsible for verifying your identity each time you log in.

While the server doesn't store the hashed Master Password, the Master Password itself is still crucial. It is used on the client side (your device) to encrypt and decrypt the contents of your vault. This means that even though the server doesn't hold onto your Master Password in any form, you still need to remember your Master Password to access your vault.

By doing this, the system adds an additional layer of security. It reduces the amount of sensitive information on the server, while still ensuring that only someone with the Master Password can access the vault's contents.

Timshel commented 7 months ago

A bit verbose ^^, but I'll add a mention that the Master password is still needed to unlock the vault .