Authentication via websocket message

[tommoor]

It seems that currently authentication is via query parameters? (ref)

This means that user access tokens will be naturally exposed in server logs, if we were to use short lived access tokens to mitigate this then that introduces an extra hop to the API to get a new token before the connection to hocuspocus can be made.

I have implemented a similar system on YJS recently and used the first message over the websocket to authenticate before any yjs protocol messages are sent. I think hocuspocus should strongly consider moving to a similar system.

[hanspagel]

I’m with you, see #109

As it’s not part of the official protocol and no one seemed to be interested in it, I declared it as out of scope for the beta release, but it’s definitely on my list as I consider it as best practice too.

[meatflavourdev]

Security is a grey area for Yjs and, currently, standing in the way of my adoption of Yjs over alternative data flow architectures. The promise of commutativity, idempotency, and eventual consistency is an attractive offering and has a unique benefit to consider when building data pipelines... but Yjs isn't an out-of-the-box solution that I can use to confidently communicate sensitive information until security is addressed by design.

That said, Yjs, and it's implementation of CRDTs has potential applications for all kinds of high performance distributed systems. To enable those innovations as an OOB CRDT framework, the basics need to be addressed. I'm excited 😁

[edit] I suppose by "the basics", I mean:

• DOS: I believe this is addressed with the Throttle package.
• Authentication Control: Cookies, JWT or HTTP (Basic/Digest) authentication. No access to functionality without authentication.
• Authorization and Authorization Control: Prevent privilege escalation and user data access without authorization. I assume this would be document level(?)
• User Input Risks: Input sanitization, standard risk profile.
• Sniffing: wss should be enforced or at least there should be a loud complaint when not using secure connection.
• Cross-Site Websocket Hijacking (CSWH): This is CSRF with WebSockets
  • The origin header should be verified
  • Individual session-unique random CRSF tokens should be used on the handshake and included in the GET request for server verification I realized that you can sniff the handshake query parameters... "An approach that is normally effective is to transmit the token to the client within a hidden field of an HTML form that is submitted using the POST method. The token will then be included as a request parameter when the form is submitted"

Like I said-- I think us developers need to reframe our approach to security and make it a primary concern-- SDD! haha 😅 Perhaps a page in the docs could address security? Common attack vectors and preventative remediation sort of thing.

Referring to Maslow's Hierarchy of needs, basic needs enable functionality at the base and reliability and safety as an adjacent concern. These are both considered basic needs. I think you can apply this to the design of software. 😅