Skip to content

do not store profile passwords in clear text #1905

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

Open
josephtingiris opened this issue Apr 6, 2025 · 3 comments
Open

do not store profile passwords in clear text #1905

josephtingiris opened this issue Apr 6, 2025 · 3 comments

Comments

@josephtingiris
Copy link

Describe the feature you'd like to request

Today I noticed that the chrome (and chromium) extensions (on linux) are storing the (webdav) passwords in clear text in both the *.log and *.ldb files, i.e.

/home/jtingiris/.config/google-chrome/Floccus Profile/Local Extension Settings/fnaicdffflnofjppbagibeoednhnbjhg/000144.log
/home/jtingiris/.config/google-chrome/Floccus Profile/Local Extension Settings/fnaicdffflnofjppbagibeoednhnbjhg/000146.ldb
/home/jtingiris/.config/chromium/Default/Local Extension Settings/fnaicdffflnofjppbagibeoednhnbjhg/000302.log
/home/jtingiris/.config/chromium/Default/Local Extension Settings/fnaicdffflnofjppbagibeoednhnbjhg/000304.ldb

stores its json ..

{
  "17438009688830.4750445422309294": {
    "type": "webdav",
    "url": "https://my.dav.server/blah",
    "username": "jtingiris",
    "password": "THIS_PASSWORD_IS_TOO_EASY_TO_READ",
    "bookmark_file": "bookmarks.xbel",
    "bookmark_file_type": "xbel",
    "includeCredentials": false,
    "allowRedirects": false,
    "passphrase": "",
    "allowNetwork": false,
    "enabled": true,
    "label": "bookmarks",
    "localRoot": "0",
    "syncInterval": 15,
    "strategy": "default",
    "nestedSync": true,
    "syncing": false,
    "scheduled": false,
    "error": null,
    "errorCount": 0,
    "lastSync": 1743942607529,
    "failsafe": true,
    "clickCountEnabled": false
  }
}

and those files can be easily read by anyone with access to that home directory.

My main concern is on multi-user systems, particularly those in which more than one person has admin/root access.

Describe the solution you'd like

Chrome, Firefox, and Safari all offer built-in password storage features, e.g. the Chrome Credential Management API. Or, prompt for the password every time the browser is started. At the very least, come up with your own reversible hash or something. Don't put the full json in the logs. I realize this can be a difficult feature to implement properly but it doesn't have to be SO easy.

example:

    // Request credentials from the user
    chrome.identity.get(function(credential) {
      if (credential) {
        // Credentials retrieved successfully
        var username = credential.username;
        var password = credential.password;
        // Use the credentials
      } else {
        // Handle the case where credentials are not available
      }
    });

Describe alternatives you've considered

Go back to the default edge, chrome, or firefox sync methods which do not store clear text credentials on the filesystem.

Copy link

github-actions bot commented Apr 6, 2025

Hello 👋

Thank you for taking the time to open this issue with floccus. I know it's frustrating when software
causes problems. You have made the right choice to come here and open an issue to make sure your problem gets looked at
and if possible solved. Let me give you a short introduction on what to expect from this issue tracker to avoid misunderstandings.
I'm Marcel. I created floccus a few years ago, and have been maintaining it since. I currently work for Nextcloud
which leaves me with less time for side projects like this one than I used to have.
I still try to answer all issues and if possible fix all bugs here, but it sometimes takes a while until I get to it.
Until then, please be patient. It helps when you stick around to answer follow up questions I may have,
as very few bugs can be fixed directly from the first bug report, without any interaction. If information is missing in your bug report
and the issue cannot be solved without it, I will have to close the issue after a while.
Note also that GitHub in general is a place where people meet to make software better together. Nobody here is under any obligation
to help you, solve your problems or deliver on any expectations or demands you may have, but if enough people come together we can
collaborate to make this software better. For everyone.
Thus, if you can, you could also have a look at other issues to see whether you can help other people with your knowledge
and experience. If you have coding experience it would also be awesome if you could step up to dive into the code and
try to fix the odd bug yourself. Everyone will be thankful for extra helping hands!
If you cannot lend a helping hand, to continue the development and maintenance of this project in a sustainable way,
I ask that you donate to the project when opening an issue (or at least once your issue is solved), if you're not a donor already.
You can find donation options at https://floccus.org/donate/. Thank you!

One last word: If you feel, at any point, like you need to vent, this is not the place for it; you can go to the Nextcloud forum,
to twitter or somewhere else. But this is a technical issue tracker, so please make sure to
focus on the tech and keep your opinions to yourself.

Thank you for reading through this primer. I look forward to working with you on this issue!
Cheers 💙

@marcelklehr
Copy link
Member

marcelklehr commented Apr 6, 2025

Hello @josephtingiris
Thank you for your feedback, I appreciate it! Unfortunately the password storage facilities you are talking about are not available for web extensions to my knowledge. Floccus used to have an unlock passphrase, but that became obsolete with the advent of Manifest v3 as there is no long running browser context anymore that can hold the passphrase in memory. Additionally, I am of the opinion that if an attacker can read your files they can also read what you type into a passphrase input box. I'm open to being proven wrong, but currently I see no better way than to just use the browser extension storage.

@josephtingiris
Copy link
Author

Security is a feeling. I'd feel a little better knowing it was obfuscated with base64 than in the clear. Yes I realize that's not encrypted, but it is one extra step someone has to take. The same principles of security apply with regard to signs advertising a home is protected by an alarm company. Bad actors will often move on to an easier target

I know this isn't an easy problem to 'solve' but it can be made better.

What about an unlock passphrase using Manifest v3 storage.session ?

Maybe something like this and encrypting browser.storage.local would be even better?

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

2 participants