ejabberd - Comments for "ejabberd odbc auth module"

Ok, let's look at them. Both

mikekaganski — Mon, 19 Mar 2012 08:20:24 +0000

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.

hmm yeah, but if you look at

jra — Mon, 19 Mar 2012 07:12:59 +0000

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?

Disclaimer: I have no

mikekaganski — Mon, 19 Mar 2012 01:27:26 +0000

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).

mikekaganski wrote: The

jra — Sun, 18 Mar 2012 23:35:23 +0000

mikekaganski wrote:

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.

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

The "*_odbc" modules had been

mikekaganski — Sun, 18 Mar 2012 22:39:59 +0000