Saving encrypted passcode locally?

[nkongsuwan]

If I understand correctly, the signify browser extension does not store Signify passcodes and requires the users to reenter their passcodes every time they opens new browser instances. My impression is that it is going to provide a bad user experience. Could the extension perhaps encrypt the passcode using a human-memorable password and store it locally in a similar manner to, e.g., Metamask?

This seems to be a security-convenience tradeoff. I am interested in learning how to significantly improve UX with minimal sacrifice to security.

[rodolfomiranda]

The passcode needs to be reenter not only in new browser extension but also after a timeout period of inactivity.

A different approach to avoid the "responsibility" of storing passwords is to use password managers

[nkongsuwan]

I think most people do not have password managers. I imagine that if the browser extension gets substantial adoption, most users will store their Signify passcodes on their note-taking applications such as Notes on iOS which is synched with iCloud. These note-taking applications may be protected by weak passwords and potentially introduce an attack surface.

Could it be that shifting the responsibility to the users may cause the ecosystem to be less secure? I am interested in hearing your thoughts on this.

[edeykholt]

I was talking with Daniel Lenksjö today about this same issue.

Here’s a design I’ve thought about off and on for a year now since learning about how Webauthn works at IIW. The idea is to use Webauthn with either a platform or roaming authenticator (e.g. a FIDO2 Hardware Key) and its pseudo random function capability.

See the picture below.

1. The browser extension creates a WebAuthn credential and register it on authenticator.
2. The user creates their random password. The extension uses a hash of this password and the Credential to request the authenticator to generate a pseudo-random result. 2.1 That result would be truncated to 21 characters and uses as the cleartext passcode. 2.1.1 The passcode would be hashed and stored (or could be stored encrypted with a hash of the password).

Later, when a new unlock session is initiated, the user might be again prompted for their password, and would regardless be asked to re-authenticate with their authenticator. The generated passcode is compared with what is stored. If it matches, then the local authentication was successful, and a signifyClient can be instantiated and interact with KERIA.

There are still some UX and design issues to be made. One decision to be made is whether the user should ever be able to see the actual cleartext passcode. That’s usually important to get backed up if they ever lose their authenticator (hardware key) or browser storage. Using browser synchronized storage is an interesting optional feature, which would allow the user to use their roaming hardware authenticator on multiple devices without re-registering it (assuming the authenticator credential data could be the same, based on what is in sync’ed storage).

References:

• https://webauthn.io/
• Quoting from an article (https://wiki.geant.org/display/GWP5/Whitepaper+updates): Emerging use of passkeys for end-to-end encryption with the PRF WebAuthn extension (https://github.com/w3c/webauthn/wiki/Explainer:-PRF-extension, https://w3c.github.io/webauthn/#prf-extension) which is used to provide access to an encryption key from a passkey for particular site, which can then be used to reliably encrypt and decrypt data. One of uses for this is to provide the client with vault data ( https://bitwarden.com/blog/log-into-bitwarden-with-a-passkey/).
• https://blog.millerti.me/2023/01/22/encrypting-data-in-the-browser-using-webauthn/
• https://issues.chromium.org/issues/41378082
• diagram is at https://docs.google.com/drawings/d/1BrH-7KpT2iCA5r_HB08azVi4I5-PgIZe_i3vb2wc_7k/edit