Conversation
325fab6 to
9d16c18
Compare
epicfaace
left a comment
There was a problem hiding this comment.
lgtm, thanks for adding this!!
|
Also -- your suggestion -- "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." -- I think it's worth it to run something like pbdkf2 on the password, just to mitigate this risk of password reuse! Might be better to add now in this PR rather than later and expose people to more risk |
fe9383c to
67cb9cd
Compare
b2cf04e to
df37e55
Compare
|
@epicfaace yes I agree it would be better to not release a version that store cleartext password even temporarily, so I did the change in this PR and it's now the salted + hashed passphrase that we store in localStorage. Thanks for your review & feedback! |
Co-authored-by: Ashwin Ramaswami <aramaswamis@gmail.com>
Inspired by the discussion of #120 and #122 - this adds the option to put a "Remember me" checkbox on the decrypt screen.
When checked, when a user decrypts the page the passphrase will be saved in localStorage in plain text in the
staticrypt_passphrasefield and will automatically decrypt the page when they come back.If a non-zero expiration has been set when encrypting the page, another field
staticrypt_expirationis created and saved in localStorage when the passphrase is successfully entered. If the user comes back to the page after this expiration date, both values are cleared from localStorage and the user has to enter their passphrase again.It's also possible to clear the saved passphrase at anytime by appending
staticrypt_logoutto the URL query parameters.The PR also adds more parameters to make all strings from the default password template editable (to help make i18n more accessible).
Closes #120, closes #114, closes #122