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

user-passcode stored in plaintext and visible after session #218

Open
edeykholt opened this issue Nov 7, 2024 · 8 comments
Open

user-passcode stored in plaintext and visible after session #218

edeykholt opened this issue Nov 7, 2024 · 8 comments

Comments

@edeykholt
Copy link
Contributor

edeykholt commented Nov 7, 2024

Repro:

  1. Install and configure the extension
  2. enter passcode as usual
  3. close the browser
  4. install a "Storage Explorer" extension from the chrome web store
  5. launch the extension from the action icon button
  6. right-click on the action popup, and select Inspect
  7. In Developer Tools, select the Storage Explorer and view the chrome.storage.local area

Results:
See the user-passcode. Sometimes, when the extension is aborted abnormally, no passcode entry is required upon launch.... maybe days later.

Expected Results:
Should instead use chrome.storage.session, which would clear after closing Chrome. Could also take other precautions to clear the cached user-passcode.

image

@2byrds
Copy link
Collaborator

2byrds commented Nov 7, 2024

Thx @edeykholt . @HunnySajid let's prioritize this tomorrow.

@HunnySajid
Copy link
Collaborator

@edeykholt thank you for pointing this out.
As discussed with @2byrds
Initially, it was intentional move to keep user passcode in storage. The idea was to keep extension UNLOCK for specific time even if browser is closed and restarted.
Now, we will move passcode to session storage to make it more secure.
This way, extension would be unlocked for specific time during the browser session and user would have to unlock again if browser is closed. I'll generate a PR soon. Thanks

@HunnySajid
Copy link
Collaborator

@edeykholt the above mentioned changes have been added here
Now the passcode and relevant info is stored in session storage instead of the localstorage.
You may try the changes and then we can close this issue.
Thanks

@edeykholt
Copy link
Contributor Author

Much improved, thank you, but the "unlocked for a specific time" implementation isn't what I'd expect. Scenario:

  1. Start an interaction that leaves the action popup open (e.g. after signing the headers to access the status page, then click on the extension's action icon)
  2. Walk away for a long time.
  3. Come back, and the popup is still open, with user-passcode still in the chrome.storage.session area.
    image

@HunnySajid
Copy link
Collaborator

Much improved, thank you, but the "unlocked for a specific time" implementation isn't what I'd expect. Scenario:

  1. Start an interaction that leaves the action popup open (e.g. after signing the headers to access the status page, then click on the extension's action icon)
  2. Walk away for a long time.
  3. Come back, and the popup is still open, with user-passcode still in the chrome.storage.session area.
    image

I understand that now. Thank you for the clarification.
Actually, this is an intended behaviour. We do not want extension to be locked (session to end) if popup is still open. This is because there is a chance that user might still be interacting with extension and it can get locked in middle of an operation.

Screenshot 2024-11-12 at 9 23 36 PM

But I agree with your concern, I think we should keep passcode in encrypted form in session storage instead of storing it as plain text. That can help us to make it secure. But I don't think extension should be locked forcefully if popup is open
What do you think?
cc: @2byrds

@edeykholt
Copy link
Contributor Author

edeykholt commented Nov 12, 2024

My opinion is that it should definitely lock and clear the passcode on inactivity exceeding ~5 minutes.

Cleartext in session storage isn't as big of a concern for me relative to this, since the encryption key would probably be discoverable via the source code. Plus, there are other exposures of the passcode, such as in the extension's service-worker console output. See image. The team could create on another backlog item for hardening these types of areas. I'm working on some concepts in KERI Auth extension related to having the user providing a password (or with webauthn and PRF -- see https://github.com/w3c/webauthn/wiki/Explainer:-PRF-extension), then using that material to encrypt.

image

@2byrds
Copy link
Collaborator

2byrds commented Dec 22, 2024

@HunnySajid what is the status here?

@HunnySajid
Copy link
Collaborator

@HunnySajid what is the status here?

No further development has been made on this. I would look into this and we can discuss about the possibilities.

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

3 participants