"Remember me" not working - reusing same salt across multiple pages about staticrypt HOT 6 CLOSED

Ah, unfortunately you're correct... The problem is that to use the "Remember me" checkbox, staticrypt doesn't actually use the password in plain text to encrypt the page but a salted & hashed version. This is in order to be able to store this salted + hashed string in the browser's localStorage instead of the plain text password.

But when multiple pages are processed by staticrypt each will get a random different salt, so the value stored in localStorage will be hash(saltA + password) for a.html and hash(saltB + password) for b.html. Therefore saving the password on one page will not unlock the other (and going to the other page with a wrong stored password clears the storage, so coming back to the first will not unlock automatically either).

I'm not really sure how to mitigate this right now, I need to think about it for a bit. Thank you for your very clear report.

from staticrypt.

Got it, thanks for the explanation.

Too bad, I wanted to use your library for a private section in my UX portfolio. I hope this can be a fix not too difficult to perform, so that I don't have to switch to another solution.

By the way, kudos for creating this library! The password prompt looks very nice.

from staticrypt.

So here's what I'm thinking so far as a plan to make it work - even if they should stay safe-ish in the browser, I like the idea of not storing passwords in clear text and having a salted + hashed version powering the "remember me" feature. So we need to reuse the same salt across multiple pages.

A couple of options I see for doing that:

1. passing the salt as a parameter to the tool manually - this is what #126 now allows you to do, you can generate your own salt (here for ex - though I don't know if it's cryptographically truly random) and pass the --salt 6873d559652a54635aa4ebf349c357ff argument. I'll update the doc before republishing the package, it needs to be 32 hexadecimal character long.
2. if staticrypt could take multiple filenames as argument, it could autogenerate a salt and apply it everywhere. I think this is the most user friendly way of doing this.

One caveat of 2. is that the salt will change if the user runs the command again. So the flow

• encrypt with staticrypt (generates saltA), upload somewhere
• user visits with the browser, decrypts with remember me option (stores password w/ saltA in browser)
• make some changes on the source files, encrypt again with staticrypt (generates saltB) and re-upload
• user comes back, browser automatically tries password w/ saltA but saltB is expected => user is logged out

is broken. Method 1. would work if the user remembers the salt they first used, which is also somewhat inconvenient for them.

So I think staticrypt needs to save a config file to save the salt in between runs. I don't really see a way of avoiding this while still providing a unique salt per encrypted project in a convenient way. If you see a better option please let me know.

I think this should be good for most people, many tools follow this pattern. We can still keep the --salt option as a backup for people who don't want that extra file, and they can handle the logistic of remembering the salt from one run to the next as they want.

from staticrypt.

Hey @smogledore I've updated the CLI, you can now set a same salt across files with -s MY_SALT (and you can generate a salt to use with staticrypt --salt). Check out the new documentation and let me know if you run into trouble.

This should do as a workaround for now, I'll get to the method 2. described above that removes the need for the --salt flag when I get time.

from staticrypt.

Hi @robinmoisson
I did a quick try and it seems to work perfectly, I will come back to you if I encounter any problems during my further tests.
Thanks a lot for fixing it so quickly.

from staticrypt.

Closed in release https://github.com/robinmoisson/staticrypt/releases/tag/v2.1.0

from staticrypt.