Improve Token Security

[type1fool]

At the Denver Elixir meetup, one of the attendees (@RGENT) raised a concern about token security (video link).

In short, the token saved in sessionStorage may be accessed by 3rd party JS dependencies. Suggested mitigations include cookie storage and/or adding content security policy (CSP).

Because these component interact exclusively via WebSockets, cookies may not be an option here. CSP is likely the better solution, though other alternatives may exist.

Resources

• Google Search "sessionstorage security"
• Okta Blog: Secure Browser Storage: The Facts
  • See section on Web Workers
• CredentialsContainer.store() (MDN) 🤩
• CredentialsContainer.preventSilentAccess() (MDN)

[richard-giraud]

Upon reflection:

I don't think that CSP would do much to solve the issue. It's capable of stopping XSS reflection attacks but generally little else. It's also a pain to work with and often not used. In this use case, it falls short of the Secure and HttpOnly cookies in terms of practical security.

Is it possible to teardown and rebuild Websocket connections transparent to the user? If this is the case, then it might be possible to use session cookies via AJAX.

[type1fool]

@RGENT Interesting. I read through the Okta blog article about browser storage methods, and it seems like Web Workers would be the solution for this LiveView implementation. Have you dealt with Web Workers for this type of problem?

[type1fool]

From #47:

Instead of setting the token in JS SessionStorage, add a session controller which saves the token in a cookie.

This may eliminate the need for connected?(socket) checks.

Update the demo app to test & document usage.