staltz/ssb-room-broker-auth-spec

Draft spec

• Content

ssb-room-broker-auth-spec's Issues

Protect tokens against spoofing by the room server

Suppose the room server is malicious and once a remote peer tries to use a tokenized alias URL, the server just responds false to the brokerAuth.request() (pretending that the alias owner is offline) and then proceeds to abuse that token to introduce another evil buddy to consume that token and force the alias owner to follow the evil buddy. Boom. 💥

We could try to sign or encrypt the token somehow, but in general, the room server MUST NOT know what the plaintext token is. On the other hand, how are we going to do that? The first step is the remote peer visiting the tokenized alias URL in a browser and the web browser replying with an SSB URI, which will then open the SSB app and make the muxrpc calls.

Multi-use tokens

Allow the possibility that a token can be used by many remote peers.

`brokerAuth.request()` also sends tiny proof of ownership

Problem: avoid spam from attackers trying to use the room alias. If anyone with a new app can input my alias, then that could cause a popup on my app asking for approval. The popups can get too intrusive if it's about an attacker and I have to reject them every time.

Idea: When the new app sends brokerAuth.request() it can also send a partial proof that it owns the same SSB ID, sort of like a "password". It could be the 1st word in the 24 words phrase. The "proofword".

This would create a lot more friction to brute force attacks because the room can detect that an attacker is calling too many brokerAuth.request()s and ban the attacker based on SSB ID or IP. And even in the worst case where the attacker guesses the correct 1st word (out of 2048 words), the effect is not a breach, it's simply that the old app would show the popup asking for permission.