Add brute force protection to conversation passwords

[nickvergessen]

No description provided.

[vitormattos]

I think will be good to implement behat tests to check if it is working fine.

[nickvergessen]

I think will be good to implement behat tests to check if it is working fine.

It is intentionally disables even for the login and stuff:
https://github.com/nextcloud/spreed/blob/master/tests/integration/run.sh#L69-L70
So not sure that is possible.
Similarly we can't really test the password policy feature in #7473 as the used passwords violate the rules.

[nickvergessen]

/backport to stable24

[nickvergessen]

/backport to stable23

[nickvergessen]

/backport to stable22

[danxuliu]

The delay in HPB requests needs to be reset.

[danxuliu]

If I am not mistaken there are some other endpoints that need to be protected:

• getRoomByFileId and getRoomByShareToken in FilesIntegrationController, to protect the file id or share token of a public share
• getSettings in SignalingController, to protect the conversation token
• getSingleRoom in RoomController, to protect the conversation token
• createGuestByDialIn in RoomController, to protect the SIP secret
• createGuestByDialIn and getParticipantByDialInPin in RoomController, to protect the conversation token (due to using @RequireRoom if the token is wrong 404 is returned, but if the token is right and the SIP bridge request is not valid then 401 is returned)

[nickvergessen]

getRoomByFileId

Not sure what to throttle there. First thing that is done is checking if you have access to the fileId. That is outside of the scope of Talk and only gives you tokens which you can access.

Other things are fixed

[danxuliu]

getRoomByFileId

Not sure what to throttle there. First thing that is done is checking if you have access to the fileId. That is outside of the scope of Talk and only gives you tokens which you can access.

I thought that public shared files were seen as being accessible by the user when checked with the file id, but the code says that they are not. I think that I mixed up the tests for the shared token and the file id, sorry for the noise.

[danxuliu]

Tested and (mostly, see comments) works 👍

What about resetting the delay for the signaling server IP when the secret is changed? In my experience it is not uncommon to set a wrong secret, and if it is not reset and no hint is given about the throttling I would expect some puzzled admins :-)

Besides that, similarly to getParticipantByDialInPin and createGuestByDialIn, getSingleRoom needs to be protected for the SIP bridge secret and the talk room token. However, getParticipantByDialInPin and createGuestByDialIn have an explicit annotation for talkSipBridgeSecret and an implicit protection for talkRoomToken due to using @RequireRoom, but getSingleRoom only has an explicit annotation for talkRoomToken.

It would be more correct if both actions have an explicit handling, for example by calling sleepDelay and registerAttempt instead of throttle when the SIP bridge secret can not be validated. Right now it probably makes no difference in practice, as those actions are never reset, but it could have unexpected behaviours if at some point they are. As it is just a "future-proofness" thing it might be enough to add a comment mentioning it.

[backportbot-nextcloud]

The backport to stable22 failed. Please do this backport manually.

[nickvergessen]

22 in #7537