Looking for ejabberd docs?

To access the most up-to-date ejabberd documentation, please visit docs.ejabberd.im »

ejabberd odbc auth module

Submitted by jra on Sun, 2012-03-18 22:00

ejabberd Development

It seems that the ejabberd_auth_odbc file has been removed from HEAD^ in the git repository.
Has the code been moved elsewhere?

The reason I am asking is because I want to add hashed passwords in my ejabberd mysql database.
But I can't get it to work, and now I suspect that the server isn't even using the module in question.

I am using ejabberd 2.1.10 at the moment, and I am hoping that maybe someone could give me a heads up on how to solve this little problem of mine? :-)

The "*_odbc" modules had been

Submitted by mikekaganski on Sun, 2012-03-18 22:39.

The "*_odbc" modules had been made obsolete by changes in 3.x that moved backend storage to an abstraction layer (see Release Notes for 3.0). Thus, for a module, it does not matter which storage is used.
However, this is for 3.x only, it should not matter for 2.1.10.

mikekaganski wrote: The

Submitted by jra on Sun, 2012-03-18 23:35.

mikekaganski wrote:

oh alright, well ... maybe someone could just help me out here then.
I have this slightly modified version of ejabberd_auth_odbc.erl that I have compiled and put in my ebin folder (replacing the old and only other one on the system).

http://pastebin.com/CLR430KG

Original (of the modified version I used) is here: https://raw.github.com/gist/975172/3b9f3a05fe95a81b1581ea0c72fe047ae2e61...
I just simply used hexdigest512 instead of hexdigest256 that the original author of that modified version did.

The thing is that it doesn't seem to make a difference if I use this module.
The passwords remain in plain text in the database, because I haven't hashed them yet obviously, but the auth still works like normal, which I feel is strange since the auth module should hash the password before checking it with the database?

Is there anyone who has tried this before and maybe could help me out?
I'm rather new to erlang as well so :-)

Thanks in advance

Disclaimer: I have no

Submitted by mikekaganski on Mon, 2012-03-19 01:27.

Disclaimer: I have no expertise in ejabberd auth code. Just first impression from looking into the code

The code is not consistent. The original modifier (supposedly Henrik P. Hessel) seemed to only care about plain auth, while the code covers digest auth, too. And if the digest auth is used, the code will continue working as before (presuming that DB stores passwords as before), until users will try to set their password. As all the "password set" codepaths (I mean "set password for existing user" and "create new user") are patched so that they store sha-hashed passwords, this will break the digest auth, and user will be unable to login, unless he will provide hash instead of password (see remark at the bottom of http://nullable.de/using-salted-hashed-password-in-your-ejabberd, that seem to proove me right).

hmm yeah, but if you look at

Submitted by jra on Mon, 2012-03-19 07:12.

hmm yeah, but if you look at the two "check_password" functions, wouldn't it be those that are used for authentication?
So wouldn't at least authentication work with hashes, as they are patched?

Ok, let's look at them. Both

Submitted by mikekaganski on Mon, 2012-03-19 08:20.

Ok, let's look at them.
Both are expected to return true on successful password check, false otherwize.

check_password(User, Server, Password)
This function first makes the hash of the password. Then it makes ODBC query to get the password stored in the DB for this user.
Then, if the returned object contains three items: atom 'selected', string "password" and string equal to our compiled hash, then it returns result of checking if Password is not empty string (i.e., it returns true for non-empty password).
In all other cases, it returns false.
While I might say that the logic is a bit suboptimal (I would first check for empty pass, then do the query, then make hash and check password), this function is "fully patched".
check_password(User, Server, Password, Digest, DigestGen)
This function takes two more arguments: Digest seems to be the string and DigestGen is a function.
After building hash and querying DB (just like #1), it first checks if Digest isn't empty, and compares it to the result of applying DigestGen to password stored in DB. On success, it returns true, otherwize it checks if the ODBC result is our hash.
So, this function only uses our hash if Digest auth is not used, and if Digest is used, the unhashed passwords in DB will be OK.

I think that if you will try to use hashes, you will possibly succeed unless you use Digest auth.