search

OpenBoard-org / OpenBoard

OpenBoard is a cross-platform interactive whiteboard application intended for use in a classroom setting.
https://openboard.ch/
GNU General Public License v3.0
2.24k stars 412 forks source link

Improve password storage for YT credentials #1021

Open Vekhir opened 1 week ago

Vekhir commented 1 week ago
**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](https://github.com/OpenBoard-org/OpenBoard/blob/1665e2e570e5e76c75d9e8a4b7e9a3f0c5071736/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](https://github.com/OpenBoard-org/OpenBoard/blob/1665e2e570e5e76c75d9e8a4b7e9a3f0c5071736/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** 2. 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. 3. Use [QPasswordDigestor](https://doc.qt.io/qt-6/qpassworddigestor.html) 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. 4. 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?