search

unverbuggt / mkdocs-encryptcontent-plugin

A MkDocs plugin that encrypt/decrypt markdown content with AES
https://unverbuggt.github.io/mkdocs-encryptcontent-plugin/
MIT License
130 stars 16 forks source link

Multiple passwords #36

Closed zubri closed 2 years ago

zubri commented 2 years ago

Great plugin, thanks.

Is there a way or workaround to use a set of passwords instead of a single one?

I mean like the global password configuration option, but having many, not just one. Thus we can distribute credentials per users, instead of granting a shared password to them all.

Otherwise there is no way to disallow someone that already knows the shared secret, but to change the password and re share it with everyone.

Regards

CoinK0in commented 2 years ago

Hi.

No, there is no way to make multiple passwords. In fact, the notion of user itself does not exist.

I already have thought about integrating this possibility and technically it is possible, but that it involves a lot of constraints. Maybe a dynamic site with a DB will make more sense than static mkdocs with this plugin. It's much more secure (as long as the backend/web page is properly protected)

I will not integrate the concept of user and multi password in this plugins. Sorry.

To argue a little more from a technical point of view.

Currently I encrypt the desired parts (Content + Encrypt Something + Search index) with the password defined globally or more specifically on the page. Then I hide the generated encrypted content in the page with a 'hidden' CSS style. But therefore the content is still in the page.

Several users, therefore implies several passwords and therefore to encrypt the same content several times to hide it in the page. In addition it will be necessary to be able to know which user enters his password, otherwise it is necessary to try the password on all the encrypted chains.

We could tinker and make a kind of static DB that the user password will come to decypt to recover a password which encrypts the page for him. In this case, no more multiplication of encrypted content, but no more security either, because each user could find the password used.

Then in all cases with these two methods, you would always have to rebuild your site to remove the user. (The only advantage is the distribution of the password)

zubri commented 2 years ago

Got it.

This is a very clean solution for the single password use case, since everything is self-contained in the static site, without any additional constraint.

For our requirement I will probably use HTTP auth via .htaccess or convert the mkdocs static site build into something else (ex using next js)

Thanks anyway.