Extension for encrypting an entire website

[epicfaace]

Staticrypt is great! I extended it a bit so that it could be used to encrypt an entire website. Here are my steps:

1. Change the template so that it stores the password in localStorage once entered.
2. Run staticrypt on all html files.
3. Now we have a website where the user can log in once and then navigate to other pages without entering in their password for each page. (demo at https://epicfaace.github.io/ghpages-private-test/, password is "password")

@robinmoisson would you be willing to accept PRs to modify staticrypt so that it can work with these kinds of workflows more easily? Essentially, staticrypt could then work out-of-the-box to let people easily deploy a password-protected github pages website (or, really, any static website).

I'm thinking of updating the staticrypt CLI options with the following parameters:

Usage: staticrypt <filename or directory> <passphrase> [options]

Options:
  --help               Show help                                       [boolean]
  --version            Show version number                             [boolean]
  -e, --embed          Whether or not to embed crypto-js in the page (or use an
                       external CDN)                   [boolean] [default: true]
  -o, --output         File name / path for generated encrypted file
                                                        [string] [default: null]
  -t, --title          Title for output HTML page
                                            [string] [default: "Protected Page"]
  -i, --instructions   Special instructions to display to the user.
                                                        [string] [default: null]
  -f, --file-template  Path to custom HTML template with password prompt.
                          [string] [default: "[...]/cli/password_template.html"]
  -i, --in-place   Whether to modify input file(s) in place.
  -p, --persist-type   Whether to persist the password in the user's browser.
                            Can be set to "localStorage", "sessionStorage", or "cookie".
                            [string] [default: null]

Then, generating a static site and deploying it to GitHub Pages might be as easy as doing the following:

npm run build # generates files in `dist`
staticrypt dist -i -p localStorage
gh-pages -d dist

Some potential improvements:

1. It would be good to have an option such as --logout-url that allows a logout page to be generated; the user can then link to this logout page on the static site which should clear the password from the user's localStorage / cookies.
2. It seems okay, but not ideal, to store the plain password in the user's localStorage / cookies. Could we make the stored password automatically expire (if there's some cryptographic way to make a token valid only for a particular amount of time, that would be great -- otherwise, we could just maybe delete a cookie after a certain period of time)?
3. Allowing provisioning of multiple users and passwords.

Related to #110, #114.

[404invalid-user]

this would be nice to have because i tried folowing your steps and failed

[epicfaace]

Here's a gist with the code I created for this, if it helps: https://gist.github.com/epicfaace/c1a4452401af14d35b60fe211f2c1559

[404invalid-user]

Thank you I'll have a look at this an see if I can get it to work

[wzdiyb]

@epicfaace Thanks for your wonderful sharing, the idea helps a lot!

[robinmoisson]

Hey @epicfaace, thanks a lot for the detailed suggestion and my sincere apologies for taking so long to answer.

I think the feature is a good one. Regarding the use case, it feels to me the main one would rather be browser dependent than "choosing between localStorage and sessionStorage at encryption time": if I access the page from my personal computer I might want to stay "logged in", if not it might be better to ask the password for each page.

So that's what I implemented in #124 (along with a way to logout and expiration handling).

sessionStorage might be an interesting future way to enable decrypting multiple different pages on a single domain without persisting the passphrase for a longer time.

---

Regarding the storage in clear text I feel on the same page as you are (I think): it's not ideal, it might be okay-ish here.

Thinking out loud, here are some threats I think it might enable:

• rogue extension reading the localStorage (if it can read the localStorage it can probably access the page anyway and get the passphrase when typed in. This would allow the passphrase to be leaked even if the extension becomes malicious after you typed the passphrase)
• third party JS included in the decrypted file might read the localStorage once decrypted and leak out the passphrase (in this case it can't do that without this feature)

I don't really see a way to get the localStorage content that would not also allow reading of the page decrypted in browser (though there might be), so my assumption would be that the content of the page is compromised and what might be protected is the passphrase the user typed.

A mitigation I had in mind was salting + hashing the passphrase and store that in localStorage, so the hashed passphrase effectively becomes the key to the encrypted page. This doesn't mitigate the leaking of the hashed passphrase, which allows decryption of the page, but does mitigate password reuse.

#124 first draft has clear text passphrase storage.