-
Notifications
You must be signed in to change notification settings - Fork 7
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
Comments
Thx @edeykholt . @HunnySajid let's prioritize this tomorrow. |
@edeykholt thank you for pointing this out. |
@edeykholt the above mentioned changes have been added here |
Much improved, thank you, but the "unlocked for a specific time" implementation isn't what I'd expect. Scenario: |
I understand that now. Thank you for the clarification. 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 |
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. |
@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. |
Repro:
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.
The text was updated successfully, but these errors were encountered: