Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve password storage for YT credentials #1021

Open
Vekhir opened this issue Jun 19, 2024 · 0 comments
Open

Improve password storage for YT credentials #1021

Vekhir opened this issue Jun 19, 2024 · 0 comments

Comments

@Vekhir
Copy link
Contributor

Vekhir commented Jun 19, 2024

Is your feature request related to a problem? Please describe.
After #1019, the only other (direct) dependency on OpenSSL I can find is in src/frameworks/UBCryptoUtils.cpp. If the usage could be removed and/or replaced, there would be no direct dependency on OpenSSL anymore.

Next to this initial motivation, their usage is insecure. The defined functions are only used in src/podcast/youtube/UBYouTubePublisher.cpp, where they are used to encrypt passwords which are stored for automatic fill-in. Not only is the way they are stored out-of-date (static algorithm and too few hashing iterations), it's also insecure since all input data for the key is static and public, making decryption trivial.

Describe the solution you'd like

  1. Remove the password storage entirely. Modern password managers exist, which are more secure and better audited. Not quite as convenient as automatic fill-in, though copy-to-clipboard is usually available.

Describe alternatives you've considered

  1. Integration with password managers. Instead of storing passwords on our own, retrieve them from a secure vault that's managed by a password manager. This keeps convenience, while coming with a maintenance burden. A candidate for that integration could be Pass (https://passwordstore.org) which provides a CLI.
  2. Use QPasswordDigestor and add context data to the stored password. This somewhat modernises the algorithm while not really solving the underlying issues. Probably expects compatibility with currently stored passwords.
  3. Keep things as is. There is no defined attack model and no security guarantees, so just say that it's not an issue. Security expectations are user error. Least maintenance burden.

Additional context
I don't know how prevalent that feature (storing YT passwords for reuse) is at Geneva schools and in the wider community, though I'd hazard a guess that it's not much. The code has been imported from Open-Sankore and never been touched since. What's your preferred direction?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant