robinmoisson/staticrypt

Feature: Allow for multiple passwords for decryption

martinseener opened this issue · 4 comments

martinseener commented

We have a use case where we want to give the URL to several third parties but all of them should have its own password for login.
Could staticrypt being extended to store the master password encrypted and being able to decrypt by multiple 2nd layer passwords, like LUKS does it.
Would be nice if this can be possible.

robinmoisson commented

Hi, could you help me understand your use case a bit more? It seems to me people will have access to same content and you're the one generating the password, so why doesn't providing one single password to all work? Is it in case one is compromised, then you can change only that one password without impacting access for the others?

martinseener commented

Hi,

yes exactly. Our use case are API Docs being statically generated and at the moment we use simple htpasswd to generate logins for each entitiy and if one is compromised or should have no more access, we cpuld delete the key.

robinmoisson commented

Thanks for detailing the need @martinseener. This sounds useful and like something StatiCrypt might want to support.

This is low priority compared to the other features moving towards v3 so I don't expect it to happen soon however. I put it in the roadmap backlog for now.

Anyone interested in this can feel free to submit a PR, though I'd recommend waiting for v3 to be here as the code will be cleaned up quite a bit then.

robinmoisson commented

I thought about this some more and have an implementation lead. We can:

  • generate a random encryption key
  • use that key to encrypt the files
  • encrypt that key with multiple passwords, storing the results alongside the encrypted file data

To decrypt, we try to decrypt all encrypted keys with the provided password. If one of them matches, then we use the decrypted key to decrypt the file data.

Since everything is happening client side the random encryption key is exposed each time someone decrypts the file. So to allow revoking access that key needs to change each time we encrypt our files (else someone could store that key at one point and keep using it even if their password no longer works).

In the meantime, the recommended way is to encrypt the file multiple times with multiple password and multiple output directories. The protected files can then be shared with their unique urls: https://example.com/john/test.html, https://example.com/mary/test.html, ...

I added a section in the FAQ showing what that could look like.

It looks like a pretty good workaround to me but let me know if that didn't fit your use case. Thanks!