Store and load credentials from secure storage

[alanshaw]

No description provided.

[alanshaw]

Currently these are stored in localStorage.

[travis]

Do we have any ideas about what secure storage solution we could use for this?

I've bumped into this particular issue many times in the past and as far as I know the only solutions that aren't vulnerable to XSS attacks (eg, from a compromised tracking script on the page) involve storing secrets in a server-side session associated with an httpOnly cookie (https://dev.to/rdegges/please-stop-using-local-storage-1i04 has a decent rundown of the issues here).

FWIW, the Solid folks had the same problem building their client - this thread has some good links and analysis of the underlying issue, but the TLDR is that the only really "secure" place to store secure credentials in the browser is in a closure in JavaScript accessible by the library code that uses it. In practice this means the web client needs to go from identifier (ie, email address) to credential on every page load or refresh. In Solid this means redirecting the user to their identity provider, which usually just verifies they are logged in/authorized and then redirects them right back - this happens pretty fast so in practice the user experience isn't too bad, and we might need to implement a similar pattern here.

Nota bene - this is only an issue for client-side-only apps - any application with a server-side component that can securely store credentials in a session identified by an httpOnly cookie doesn't need to worry about this as much - XSS attackers could definitely abuse APIs the browser code has access to, but since the core credentials are never sent to the browser they can't access them.

[travis]

Worth mentioning that it's at least possible to make the argument that storing tokens in localStorage is fine as long as you are diligent about avoiding XSS vulnerabilities - this is a slightly awkward thing for us to do as a library author, as we'd need to convince all consumers of this library that they should just focus on avoiding XSS attacks, but it's at least part of The Discourse around this:

https://pragmaticwebsecurity.com/articles/oauthoidc/localstorage-xss.html

[jchris]

I think we want to use non extractable keypairs eg navigator.credentials -- this is what forces us to lean so heavily on cross device delegation workflows

[travis]

ok sweet - I think that's a much better approach, tho one I have less familiarity with, will do some reading!

[gobengo]

https://mobile.twitter.com/OR13b/status/1579174267920744448
https://gist.github.com/saulshanabrook/b74984677bccd08b028b30d9968623f5

[travis]

Thanks @gobengo! For posterity - I was partly wrong - IndexedDB has provided a mechanism (as demonstrated by the gist from saulshanabrook) to store private keys specifically in a non-extractable format for a while now - this is great!

It sounds like the roadmap here is to use the new RSA signer support in ucanto to generate and store a private key in IndexedDB rather than storing a string in localstorage for now, and figure out how to integrate Webauthn (ie, navigator.credentials) into that flow soon.

[gobengo]

and figure out how to integrate Webauthn (ie, navigator.credentials) into that flow soon.

WebCrypto (with .extractable = false) + IndexedDB can probably take us very far. We'll only need WebAuthn when we need to integrate with external authenticators, e.g. touchid/faceid, yubikey, etc.

[travis]

Yep agreed - the one Passkey-specific thing that might be pretty convenient for us is that afaik Passkey implementations from Apple, Microsoft and Google all sync private key material for a particular user between devices. Even without a standalone keyring website I think this could make it easier for us to add new "agent" keypairs to a user's "account."

That said, I think in the short and medium term we'll need to provide a first-class experience for users who don't have Passkeys, so it's probably worth building and polishing all of that before getting too far into external authenticator support.