You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Initial implementation of configuration polling uses auth tokens. Since client application does not implement regular user authentication frontend, there is no reasonable way to implement token expiration and updates. Because of this, those tokens are issued indefinitely which is not ideal. The tokens would also have to be reissued if they ever get lost.
To mitigate those issues it should be possible to implement an authentication mechanism based on wireguard keys. Basic idea, to be researched and implemented if no significant flaws are found:
client stores wg private key
core stores corresponding wg public key
client uses private key to sign a (timestamp, nonce) tuple
client includes signed tuple in polling request
core uses public key to verify the signature
core verifies timestamp is within acceptable range (5 minutes?)
core stores the nonce to db as "consumed"
core removes from db nonces older than acceptable range
Initial implementation of configuration polling uses auth tokens. Since client application does not implement regular user authentication frontend, there is no reasonable way to implement token expiration and updates. Because of this, those tokens are issued indefinitely which is not ideal. The tokens would also have to be reissued if they ever get lost.
To mitigate those issues it should be possible to implement an authentication mechanism based on wireguard keys. Basic idea, to be researched and implemented if no significant flaws are found:
Potential solution: https://signal.org/docs/specifications/xeddsa/
The text was updated successfully, but these errors were encountered: