-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Date and reason for banned accounts not stored when using SCRAM #4201
Comments
I've added I've tested this and works with mnesia and mysql, plaintext and SCRAM passwords. How to use: Lets ban an account. It detects if the account is already banned:
Lets get ban information of an account
And finally, lets revert the banning. It detects if the account is not banned:
The old command implementation is still available, in case somebody still wants to use it:
It would be great if you can test the feature and report your results. There are binary installers and the container image. |
Thanks a lot for addressing this issue. I played around with your changes a bit and believe there is a major flaw in the current implementation: Users with knowledge about the implementation can make themselves "unbannable". That's because the implementation uses a user accessible storage to store the ban details. So a regular user can simply write something to the
If an admin wants to ban the user later on, he'll get the message that the user is already banned, while the user is still able to log in, as his password had never been replaced with a randomly generated one:
I assume the current implementation of replacing a users password with a random one when banning is intentional to be able to confine the ban logic to One downside of the implementation utilizing a users private XML storage is also that users will loose data they have stored in the |
More than that, a design goal right now for that feature is to not require fields in other tables (which would involve updating their schemas in mnesia, and all SQL), nor require a brand new table (which would involve writting code for mnesia and SQL backends). As long as this feature is rarely used, let's try to get it working without requiring specific database changes.
Wow, right! I've now added a hash value to the banned element, without that one the element is not taken into account. A valid hash can only be generated by ejaberd or somebody that knows the erlang's cookie (like a server administrator), regular users don't know it.
And the error returned could be Ok, I've implemented it. It requires minor changes in the xmpp library (that could be useful in other cases in the future).
Aha, right. Looking for a solution, I noticed a paragraph in XEP-0049: Private XML Storage that says:
This means that the clients are not expected to use reserved namespaces. ejabberd does not enforce that restriction, but anyway a client cannot expect such reserved namespaces to persist. Consequently, I think acceptable to use a reserved namespace for ejabberd, for example I've implemented all those changes in my fork, so we can test it without messing in the public repository. Once we are happy with the changes, they can get merged in the public repository. There are binary installers and container image in case you cannot compile ejabberd yourself. |
Sounds good and I didn't notice any problems in my tests.
That's much appreciated.
I must've missed that paragraph. Using a reserved namespace sounds like good solution to me too. One minor problem I noticed is that trying to ban an account while
Maybe it'd make sense to just print a message when the new ban commands get invoked while |
The commands documentation already mentions that |
I've no further comments. From my point of view it's ready to get merged now. 👍 |
As mentioned in: Certain namespaces are reserved in Jabber (namespaces beginning with 'jabber:' or 'http://jabber.org/', as well as 'vcard-temp'). If a user attempts to get or set jabber:iq:private data in a reserved namespace, historically some server implementations have chosen to return an error (commonly "Not Acceptable") to the sender. https://xmpp.org/extensions/xep-0049.html#example-5
The functionality to ban users implemented in
mod_admin_extra
works by changing their password to one starting withBANNED_ACCOUNT
and which includes the date and reason of the ban, as well as a random string:ejabberd/src/mod_admin_extra.erl
Lines 1000 to 1005 in 051bf29
However, when using
auth_password_format: scram
, this password gets hashed, which makes it impossible to figure out if an account is banned, when it got banned and what the reason was it got banned. It'd be great to also have that information available when using SCRAM asauth_password_format
.Instead of overwriting the password of an account when banning it, storing the information in other fields would be great as well, as that'd allow reverting bans.
The text was updated successfully, but these errors were encountered: