OWASP [1] recommends for password hashing the following algorithms in
descending order: argon2id, scrypt, bcrypt. They state that bcrypt may
be used in legacy systems or when required due to legal regulations.
We're however not building any legacy application. Even HedgeDoc 1.x
utilizes a more modern algorithm by using scrypt.
While bcrypt is not insecure per se, our implementation had a major
security flaw, leading to invalid passwords being accepted in certain
cases. The bcrypt nodejs package - and the OWASP cheatsheet as well -
point out, that the maximum input length of passwords is limited to 72
bytes with bcrypt. When some user has a password longer than 72 bytes in
use, only the first 72 bytes are required to log in successfully.
Depending on the encoding (which could be UTF-8 or UTF-16 depending on
different circumstances) this could in worst-case be at 36 characters,
which is not very unusual for a password. See also [2].
This commit changes the used algorithm to argon2id. Argon2id has been in
use for several years now and seems to be a well-designed password
hashing function that even won the 2015 Password Hashing Competition.
Argon2 does not have any real-world max input length for passwords (it
is at 4 GiB).
The node-rs/argon2 implementation seems to be well maintained, widely
used (more than 150k downloads per week) and is published with
provenance, proving that the npm package was built on GitHub actions
using the source code in the repository. The implementation is written
in Rust, so it should be safe against memory leakages etc.
[1]: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Che
at_Sheet.html#password-hashing-algorithms
[2]: https://security.stackexchange.com/a/39851
Signed-off-by: Erik Michelson <github@erik.michelson.eu>
When the frontend is notified about metadata updates, it refreshes the
data and therefore refreshes information like the timestamp of the last
revision save in the sidebar.
This commit adds such a notification from the backend to all clients on
each revision save, so that the "last saved at" value in the frontend is
correct.
Signed-off-by: Erik Michelson <github@erik.michelson.eu>
The motd.md is user-supplied and should therefore not be prebuild during
the HedgeDoc build process. As that required the presence of the base
URL which is also not available in the build context, it fell back to
our fallback value example.org, thus breaking offline builds.
By removing the example.org domains and disabling the prebuild for the
motd, this seems fixed.
Co-authored-by: Philip Molares <philip.molares@udo.edu>
Signed-off-by: Philip Molares <philip.molares@udo.edu>
Signed-off-by: Erik Michelson <github@erik.michelson.eu>
This workflow was used in an early stage of development of HedgeDoc 2.
It allowed the core developers to quickly check fixes, improvements or
new features to the HedgeDoc UI without the requirement to check-out
the branch locally. As not every pull request required a deployment,
this workflow was only triggered when the "ci: force deployment"
label was added. Since some time already, the frontend and backend
are so tightly coupled that the netfliy deployment doesn't make any
sense anymore and therefore hasn't been used anymore. This commit
therefore removes this leftover workflow.
@RedYetiDev contacted us privately and reported that this deployment
workflow could have been abused to invoke arbitrary commands, including
extraction of environment variables which include our tokens for the
turborepo build cache or the netlify deployment token. For this it
would have been required that somebody created a "safe" pull request,
which would have been labelled with the deployment label and then
changed afterwards since the workflow checks out the pull request
source repository, not the target. We assured that the label was only
added to pull requests from trusted members of the HedgeDoc core team.
There was never any malicious use of the workflow. Furthermore, no
released versions of HedgeDoc (1.x) could have been affected by this,
even in the worst-case scenario.
We're thankful for putting this risk at our attention!
If you too encounter something unusual regarding security in HedgeDoc
itself or our toolchain around it, don't hesitate to contact us.
Details on this are wriiten in our SECURITY.md in the root of the
repository.
Signed-off-by: Erik Michelson <github@erik.michelson.eu>
